I used Erlang before Elixir and it was awesome, albeit with a syntax that required getting used too. I've often looked at bridging the gap between Ruby and Erlang, and closely watched and tested solutions like Reia [0], Erlectricity [1] and Ernie [2].
I was delighted when Jose started getting involved in the space and released Elixir. Thanks Jose!
Ernie was my first foray into Erlang (run many production elixir apps now). It's still humming along in one of our legacy services. Never had an issue or downtime event
Elixir is more than syntax. Or rather, it is not even about the syntax :) This is a common question, so I even gave a talk about it some time ago: https://www.youtube.com/watch?v=V5fMQcSy3y8
Elixir features meta-programming, structs and protocols, first-class documentation, strong focus on the tooling, some abstractions that make concurrency more accessible (such as tasks and streams), etc.
However, Erlang and Elixir share a lot! They have the same data-types (with the same names and even the same syntax for almost all of them), the runtime is the same, and the same foundation about processes, fault-tolerance and distribution.
My suggestion is to go with whatever "touches your heart" because, even if Elixir has its own features, they are more alike than they are different and most concepts you learn for one will also apply to the other.
> They have the same data-types (with the same names and even the same syntax for almost all of them),
As someone who mostly has just used Erlang, but has looked at Elixir some, I think one of the things I appreciate about Elixir is some of the Erlang warts that you've managed to work around, like having strings be Erlang binaries.
Can we please have one BEAM thread where this isnt brought up? Its such a minor thing. I went from erlang to elixir and whilst at first I really missed atoms that start with a colon, you get used to it. Its 90% the same ideas, and Elixirs pipe operator is worth any small syntax niceties erlang has. No language is completely without its quirks even erlang (unless you LIKE endless repituons of the same variable into var_1, var_2, etc - and no, this doesnt reduce bugs http://blog.plataformatec.com.br/2016/01/comparing-elixir-an... )
Erlang macros are basically text substitution. It's similar to C pre-processor directives.
Elixir macros are a completely different beast, they can manipulate the AST Lisp-style. A very elegant example is Elixir's unicode module, which reads unicode data tables and turns them into function definitions at compile time [1].
Compare this to the equivalent module in plain old Erlang, which has to be generated by a separate script, in a pre-compilation step in the Makefile, that literally prints blocks of code [2].
Elixir's syntax may look more aesthetically pleasing than Erlan's, but Erlang's is way more consistent and simpler once you get used to it/understand the rules.
What makes it interesting is that the syntaxes have (most likely) been designed with different goals. I can say that Elixir was designed with extensibility and meta-programming in mind. So there are some cases where I prefer the Erlang syntax (for example, I still find defining multiple function clauses each with a single expression more elegant and concise in Erlang) while there are other cases I prefer Elixir's syntax exactly because we were able to extend the language (such as the `with` special form for handling nested case expressions).
The funny thing is, if you try to add those features to the other language, they are usually refused. Erlang wants to avoid new syntactical expressions to keep it simple while Elixir's extensibility is bound to a set of limited AST rules (and we don't want to add new ones).
I'm grateful that Elixir is putting Erlang under the spotlights. That it is doing a lot to conveying all the Erlang/OTP concepts and practices. But each time I use it - and I know I may be the odd duck based on slack, blog posts, etc - I feel like the syntax is so complex, with 4 different manners to write the same thing. And I'm not talking about "ways to do things", but literally syntactic ways to do the same thing.
Oh, that's a very good question! It doesn't because the list linked above is about syntactical equivalence and the shorthand `&` has its own AST. But now you made me wonder if we should add it to the list anyway (with a caveat) as it would make the list more complete.
I think those more complicated things are there to make things easy for developers. The standard library is not that big, and the extra syntax is there for a reason - for example `with` is pretty fantastic for reducing `case` clutter (a real thing with erlang), and pipes are also great.
I don't love that there are two ways to make lambdas but it's nit the worst thing in the world.