A question for any Erlang devs out there. For Erlang neophytes, what are the arguments for learning vanilla Erlang over one of the other ErlangVM languages?
Elixir has more syntax to learn than Erlang. You could learn just about everything there is to know about Erlang syntax in a half hour, with the exception of a few advanced features like list comprehensions.
Elixir's syntax is much more familiar to most developers. Most consider this a good thing; I'm biased because Erlang's unusual syntax helps me think differently. If I write something that looks like Ruby, I tend to think like Ruby.
Knowing Erlang can only help with Elixir, but it's not necessary. There are probably more jobs with Elixir these days, which is a good thing. I guess I'm not really helping, so I'll shut up.
I've dabbled in it a couple of times, because I'd also like to do some work with it, but haven't gotten very far. By all means give it a shot if it'll scratch your itch.
https://gist.github.com/macintux/6349828#alternative-languag...
However if you come from Rails or want to do mostly web development, then Phoenix is a nice framework, so maybe a good place to start. Also Elixir has a very friendlier community for newcomers perhaps, kudos to Jose and team there, they went above and beyond to make that happen.
All in all, there is a huge overlap. Some of the harder or more interesting concepts - functional programming aspect, using light-weight processes with isolated heaps for concurrency, performance evaluation and debugging will be the same. It is not like if you pick Erlang or Elixir you'll be wasting time and going in a separate direction, they share a lot of common concepts, and could transition easier if you need to between them in the future.
One of the best parts about Elixir/Erlang/other BEAM languages is that you can use something like the Phoenix framework in your erlang project just fine. You do not need to learn Elixir if you want to use any of the neat stuff developed in it.
Erlang as a language is very simple, without any magic that Elixir has with its marcos. And there's the tooling aspect: you're not detached from the VM and its mechanisms, so if anything breaks (and something will break sooner or later), you have a chance to know where to hit with a hammer.
The underlying libraries you'll use - gen_server, supervision trees etc are all obviously written in Erlang. It may aid in understanding of them. In practice though something like Elixir provides a superset of the functionality of Erlang. If you learn Elixir, learning to read Erlang is not very difficult.
You will be dealing with Erlang data structures (sans syntax sugar), the Erlang stdlib (Elixir doesn't wrap everything) and Erlang libraries to accomplish anything substantial. Sooner or later you'll have to grok Erlang.
For smaller, more agile shops I'm sure there's more Elixir adoption as people look for alternatives to Ruby.
I've never seen any job statistics, nor do I have any useful anecdata.
But it is also following a strategic turn and an organisational change.
Toyota, Comcast, Sky, Adobe,Square Enix are the first "entreprise" names that come to my mind for elixir
FWIW, I'm enjoying my Elixir experience. I was productive pretty quickly, and I've got some fault-tolerance and concurrency pretty cheap.
I would recommend learning both Erlang and Elixir. They're both amazing languages, I think, and your Erlang skills transfer nicely into Elixir, since you can call any Erlang function from within Elixir code.
R16 works with utf-8 binaries just fine. <<"Foo"/utf8>> you might need to put a preprocessor flag to set the default encoding for source files (the default changed in 17 or 18, I think); also settings may be needed for console output (but that probably applies to elixir too). Erlang strings are lists of Unicode code points, if you're putting a list of utf8 bytes in there, that's not ideal (but you probably want binaries instead of lists, most of the time anyway)