The only other language that has any commercial acceptance is Elixir, so really it boils down to those two.

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.

As a former lisper, I was secretly hoping that everyone would tell me that LFE is a fantastic and totally viable language.

Well perfect, do give LFE a try. I know of a few commercial users of it. You might be able to transfer some of the ideas and skills from lisp but also learn about processes and mailbox and such, without seeing a completely new syntax.

There are commercial users? That's fantastic news!

Heh, sorry.

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.

A list of every BEAM language I could find, including a Scheme and a couple of MLs:

https://gist.github.com/macintux/6349828#alternative-languag...

You can't escape Erlang when working in Elixir, and Elixir doesn't try exist without Erlang. Elixir tries to offer stuff that Erlang doesn't offer, and doesn't want to offer, including: anonymous functions, more flexible macros, variable reassignment (a=a+1), better string handling, polymorphism (via protocols), etc.

Erlang is simpler, there are less syntactic constructs to learn, has more information and learning resources available probably due to its age (30+ years),maybe more tools and libraries, that also means more example to look at. It is also the default language the VM is written for. So you can track and follow the latest changes as they are released.

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.

>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.

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.

I don’t think you can realistically use Phoenix without doing at least some Elixir, because it uses macros quite heavily, and you can’t call those from Erlang.

Phoenix without Elixir sounds interesting! Do you have a blog post or some other documentation at hand?

I don't know of any specifically, sorry. But you can use elixir modules by just prefixing them with `Elixir.` in erlang. So to call the phoenix module in erlang you'd just do a regular function call to 'Elixir.Phoenix':xxx

To this point, Elixir is just an OTP Application that gets started by the BEAM.

"Over one of the other" practically means "over Elixir".

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.

Not a serious Erlang dev, but:

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.

It's like how you kinda need to know js to do anything with coffeescript. The fastest way to learn Elixir is to learn Erlang first.

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.

My problem is not that which ErlangVM language to learn but more like how to work with OTP. Most of my Erlang projects are not OTP which is a heretic move according to Erlang devs.

Though rather old now, Erlang and OTP in Action is probably still a good intro to the basics of using OTP.

https://www.manning.com/books/erlang-and-otp-in-action

Erlang's syntax is a bit more obscure than other languages that are on BEAM. That being said, there's little reason to learn Erlang directly. It's better to learn OTP and Elixir and Erlang as you need it (e.g. libraries not available in Elixir).

To piggyback on this question: regardless of the merits of each language, do people think that in terms of enterprise adoption and job opportunity Elixir is more interesting than Erlang at this point?

Per the other comments, if you learn Elixir for professional reasons, you're very likely to at least get to the point you can read Erlang, even if you don't write it fluently. And if someone is hired on who knows Erlang but doesn't know Elixir, I doubt that's going to prove a huge impediment, especially if they have any other scripting language experience. I'd consider the question of Elixir/Erlang to be more a "both-and" sort of thing than an "either-or".

"Enterprise adoption" is still years off, "job opportunity" is just starting to come into its own. But the real reason I'd call Elixir a better place to be right now is the community. The Erlang community is not growing. Elixir's community is.

I've been seeing enough interest in Elixir to justify learning it. It's still in the "Nice to have" section of the job listings, but it's popping up more.

FWIW, I'm enjoying my Elixir experience. I was productive pretty quickly, and I've got some fault-tolerance and concurrency pretty cheap.

When I think "enterprise" I think large companies, and in that regard I think the answer is less clear.

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.

We are definitely "entreprise" (1k5 employees, FTSE 250) and all new devs are in Elixir. Coming from mainly php.

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

Out of curiosity sake, Do you mind sharing what UK company you're with?

Ascential plc

I haven't used Erlang since 16 (maybe 17), but the two features that attracted me to Elixir were support for UTF-8 strings and macros. Erlang may have both now—I'm not sure—but doing localization in Elixir was a lot easier than it was in Erlang back in the day.

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.

Erlang has define style macros (since forever?).

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)

Starting with OTP-20, the string module handles unicode, both for binaries and lists (and iolists, which mixes all styles) without a problem.

If you're the type that looks into sources of libraries when you have questions/problems, learning erlang will be helpful -- most of OTP (basically the standard library) is written in erlang itself, so it's useful to know that. (There's some amount of C code in OTP, but not too much.