Live data from Hacker News

Elixir 1.5 released

github.com

151–160 of 167 posts

Re: Elixir 1.5 released

#151
post #70

Earlier quoted context omitted.

This seems to be the dominant use case for Elixir; migrate legacy Rails code to Elixir. When deciding between Go and Elixir for our startup I looked at both ecosystems. Go was significantly ahead in all categories: traction, articles on the web, packages on git, git activity, editor support ... I don't regret choosing Go but I always keep an eye out on Elixir. Pattern matching, pipe operator, immutability, supervisor…

I LOVE the pattern-matching/deconstruction/guards stuff. It eliminates SO much boilerplate logic. Just the function head of an Elixir function eliminates a dozen input validation and assignment lines in most other languages. It wouldn't be nearly as spectacular if it didn't pervade the entire language, though (for example, I'm sure you could get partway there in many other languages using a DSL) Same thing with immut…

> I LOVE the pattern-matching/deconstruction/guards stuff. It eliminates SO much boilerplate logic.

I recently ported some simple plaintext operational transform code to Go and Swift to compare the languages, and this is so true. A lack of parameterised enums and a decent match block resulted in the Go code being about 50% larger than the swift equivalent. And the extra size bought me nothing! I find the Go code to be less readable and it had more bugs out of the gate.

IDE screenshots:

https://twitter.com/josephgentle/status/876639761166770176

Its a shame too, because I adore Go's concurrency features and APIs. Server side swift seems barbaric, and I lust over Go's scheduler and networking APIs.

Maybe its time to give Elixir a try. It sounds like it might be at a nice sweet spot of modern language features, concurrency and a mature ecosystem.

(NB: I'm new at both languages. A more experienced Go programmer might write that code differently. I don't find myself wondering that with Swift because its much more idiomatic.)

Re: Elixir 1.5 released

#153
post #71

There's quite a few nifty little things in this one. I'm not sure I like the child_spec change, personally I like the supervision mode to be explicit when calling children. I do like the developer tools, the breakpoint support, the UTF8 for atoms (which I'm realizing we may want in our DSL since we're converting user input strings to atoms), and the @impl that allows to explicitly declare which functions are there fo…

> which I'm realizing we may want in our DSL since we're converting user input strings to atoms careful there. Theres a hard limit on the number of atoms that can be created in an environment, and serializing user input to atoms can get dangerous

[deleted]

Re: Elixir 1.5 released

#154
post #70

Earlier quoted context omitted.

This seems to be the dominant use case for Elixir; migrate legacy Rails code to Elixir. When deciding between Go and Elixir for our startup I looked at both ecosystems. Go was significantly ahead in all categories: traction, articles on the web, packages on git, git activity, editor support ... I don't regret choosing Go but I always keep an eye out on Elixir. Pattern matching, pipe operator, immutability, supervisor…

I LOVE the pattern-matching/deconstruction/guards stuff. It eliminates SO much boilerplate logic. Just the function head of an Elixir function eliminates a dozen input validation and assignment lines in most other languages. It wouldn't be nearly as spectacular if it didn't pervade the entire language, though (for example, I'm sure you could get partway there in many other languages using a DSL) Same thing with immut…

>About the only wart I've seen so far in Elixir is the pin operator[6], but that was necessary to preserve the name-rebinding ability in a pattern-matching context, and it stops seeming like a wart fairly quickly, once you realize why it's necessary.

I'm interested in hearing more on this, because I find elixir's pattern matching phenomenal. Fully embracing it feels like such a paradigm shift, and along with the rest of elixir it feels like I'm learning programming all over again (and I've been doing this for over a decade). I love it.

Back to the pin operator - the syntax is very light, and it's conceptually simple. As you said it's a natural consequence of pattern-matching. I'm not trying to start bikeshedding here, just wondering if there are some other problems or perspectives with the pin operator I'm not aware of. Thanks.

Re: Elixir 1.5 released

#155

I highly recommend playing with Elixir or another purely functional language. I've only gone through the Programming Elixir book[1], but it has fundamentally challenged how I think about solving problems in other languages. [1]( https://pragprog.com/book/elixir13/programming-elixir-1-3 )

This book is for 1.3, and Elixir 1.5 just came out. Just a heads up, the author is currently working on "Programming Elixir 1.4". Believe it's coming out in November.

https://pragprog.com/book/elixir14/programming-elixir-1-4

Anyone have any other suggestions on up to date Elixir books?

Re: Elixir 1.5 released

#156

Earlier quoted context omitted.

If empty list isn't "falsey", it's not Lisp. It's a "Lisp-like" at best. Sussman and Steele had the good sense not to call Scheme " Lisp", because they knew that it would "ring falsey".

could you produce an exhaustive list of properties of a proper Lisp so that i don't mistakenly call something that isn't a Lisp, a Lisp?

Yes, I could. Though I would avoid using proper; the aim isn't to deem something "good" or "bad", just whether a name applies to it. An "improper" Lisp is very good and proper something else, and perhaps very Lisp-like language with a lot of conceptual compatibility with Lisp.

In a Lisp:

* expressions evaluate their sub-expressions strictly, usually in a left-to-right order unless otherwise noted (in the case of control constructs which repeat or omit the evaluation of some parts, and such).

* evaluation of all expressions either always produces a value, or in he case of multiple value support, always produces a tuple of zero or more values. In any case, when an expression appears in a spot where its value is required, its first value is taken, and if it returns no values, its result is taken to be nil.

* Tokens consisting of nothing but the 26 upper and lower case letters denote interned symbols. Two symbols nil and t are special in that when the are used as expressions, they evaluate to themselves and may not be used as variable names. Symbol names may be case-insensitive/folding so that NIL and nil denote the same object.

* A type exists called a cons cell (or just "cons") representing a pair of values bound together. It is produced by a two-place function called cons which creates a cons and initializes its two fields from those two arguments. The left argument initializes a field called car, and the right argument initializes a field called cdr.

* A pair of unary functions car and cdr take a cons cell argument, and retrieve the car and cdr field, respectively. car and cdr may also be applied to nil, and return nil.

* Cons cells are mutable, except possibly cons cells derived from literals expressed in program source code (for the sake of being able to put compiled program images in read-only memory, and condense their representation by collapsing identical conses). The functions rplaca and rplacd mutate the car and cdr of a cons.

* The printed notation for a cons cell is (a . d) where a recursively denotes the printed notation for whatever object constitutes the car, and likewise d is the printed notation of the cell's cdr. In the special case when d is the object nil, the (a . nil) notation condenses to just (a) which is understood to be equivalent.

* Lists are represented by cdr-recursive chains of cons cells: a list is zero or more conses, referentially linked via cdr fields, with the car fields used for the containment of the list elements. The symbol nil appearing in the cdr of a cell indicates the end of the list. A cons cell appearing in the cdr of a cons cell indicates that the list continues. A value other than nil or a cons cell also terminates the list, but "improperly": the list as a whole is called an "improper list".

* The symbol nil by itself represents the empty list. There is no "improper empty list": a non-empty list begins with a cons cell. (In some situations, there is an "emergent phenomenon" in which a non-nil atom behaves as an empty improper list; e.g. (append '(1) 3) -> (1 . 3).

* The symbol nil also denotes the (one and only) Boolean false value. A form which returns a Boolean indication returns nil to indicate "false", and any other value to indicate "true". The symbol t is a canonicalized representation of truth.

* Every object which is not a cons cell is an "atom". The consp function returns t (true) when its argument is a cons cell, otherwise nil. Its logical opposite is the atom function which returns t for an atom, and nil for a cons cell.

* A Lisp supports the functions and operators: null, and, or, cond, eq, equal, apply, eval, quote, cons, car, cdr, rplaca, rplacd, list, append, lambda and let.

Re: Elixir 1.5 released

#157
post #25

Earlier quoted context omitted.

Agreed, it's just an absolute pleasure to use. I built a side-project powered by Elixir & Phoenix 1.2, I found it so surprisingly quick and easy to accomplish even complex functionality. Every time I implemented a new feature server-side it honestly felt like "Is that it? Really?"

I believe the popular quote with Erlang is that Erlang makes hard things easy & easy things hard. Elixir was built around the idea of keeping the easy things easy. It does so by improving syntax, tooling, documentation & community in my opinion. I believe I first read this idea in the book, Elixir in Action.

Personally, I'm a fan of the Perl philosophy: make the easy things easy and the hard things possible.

Re: Elixir 1.5 released

#158

Earlier quoted context omitted.

Beware, because it can make you hate your current day-job language

Not for me. I've gone back and forth between projects that required functional languages, and projects that didn't across different companies. Bad code is bad code no matter what language it's written in. What makes me love my day job is whether I have the ability to make it better, and if those that work with me are aligned in wanting to do so. I think practitioners of functional languages get a little preachy when…

What are functional languages, as a group, "absolutely awful" at?

Re: Elixir 1.5 released

#159

Earlier quoted context omitted.

could you produce an exhaustive list of properties of a proper Lisp so that i don't mistakenly call something that isn't a Lisp, a Lisp?

Yes, I could. Though I would avoid using proper ; the aim isn't to deem something "good" or "bad", just whether a name applies to it. An "improper" Lisp is very good and proper something else, and perhaps very Lisp-like language with a lot of conceptual compatibility with Lisp. In a Lisp: * expressions evaluate their sub-expressions strictly, usually in a left-to-right order unless otherwise noted (in the case of con…

strikes me as a detailed description of a very particular implementation that you specifically like. considering lisp is a family of languages - which of these rules do you accept deviations from and by how much?

Re: Elixir 1.5 released

#160

Earlier quoted context omitted.

Yes, I could. Though I would avoid using proper ; the aim isn't to deem something "good" or "bad", just whether a name applies to it. An "improper" Lisp is very good and proper something else, and perhaps very Lisp-like language with a lot of conceptual compatibility with Lisp. In a Lisp: * expressions evaluate their sub-expressions strictly, usually in a left-to-right order unless otherwise noted (in the case of con…

strikes me as a detailed description of a very particular implementation that you specifically like. considering lisp is a family of languages - which of these rules do you accept deviations from and by how much?

> detailed description

Hardly at all; even the 1960 Lisp 1 manual ran for some 160 pages; this is just a few bullet points. It leaves a lot of room for family inclusion.

But not every Tom, Dick or Harry that walks in off the street is your family member, or even a friend.

> very particular implementation

Nope; just the original thing and many of its derivatives that can legitimately be called some kind of Lisp.

"Lisp" is in fact the name for a particular set of implementation features.

You may have a very nice implementation of some sort of list processing with all the equivalent expressivity and power, or whatever measure of pedigree we choose; it's just not Lisp: pick another word.

> which of these rules do you accept deviations from and by how much?

None. These are the things someone shouldn't mess with, if they want people to refer to their programming language as a Lisp dialect.

And, in fact, at least if we look at major works in the mainstream, most of those who do change those things understand this and don't use that term in naming their language. So, a fairly good approximation to the predicate "is not Lisp" is "does not have 'Lisp' in its name".

Post reply on HN