[josevalim]

> the erlang vm was groundbreaking but in 1996 not post 2015. even now you can see people talking about how elixir makes parallel programming trivial when it's more or less trivial in all languages now

I have to strongly disagree with this argument. :)

It borders on “all languages are Turing complete, therefore they are equivalent”, but the truth is that the idioms a language highlights make a huge impact on the software we write.

For example, take immutability and concurrency. Making concurrency first class (not an extension), makes you think about concurrency first and you are usually better positioned to deal with Amdahl’s law (i.e. you can use all cores more efficiently).

When it comes to distribution, the same abstraction is used by both concurrency and distribution, which is more accessible, easier to test, etc. You get a unified model that is more than bytes over a socket, it includes dispatching to Erlang processes, entity monitoring and naming, etc.

Thats not even mentioning other features that come from Erlang processes, such as fault tolerance, preemptive scheduling, and instrumentation.

The only confusion - and perhaps what I would have done differently - is that many people equated Erlang distribution to RPC, and that’s something we should have made clearer from day one. Still, I would prefer any language that makes concurrency first class (such as Erlang, Clojure, Go), than one that doesn’t, and there are very few languages that make both concurrency and distribution first class. Personally, if a language doesn’t allow one to transparently multiplex on both IO and CPU, such as Node, then it does not have a good concurrency story.

[querulous]

i don't disagree with you that writing concurrent and parallel programs in erlang/elixir is nicer than in nodejs or go or java. erlang picked a nice set of primitives and elixir extended that with some very good apis. i don't even disagree that language idioms influence software architecture and that elixir and erlang are particularly strong here -- particularly considering otp. however, i just don't think elixir/erlang's concurrency/parallelism story is as important now as it was when erlang was first getting attention for it

at that time the concurrency story in most languages was terrible. non blocking i/o was rare. truly parallel programming was esoteric. that's not the case today though. i am not a huge fan of go but it's undeniable that it has a strong concurrency story AND a strong parallelism story. java has nio and better libraries for concurrent and parallel than it did 10 years ago. even nodejs (which was always the equal of erlang when it came to non blocking i/o) has a very straightforward and fairly efficient worker api for doing parallel computation. languages like rust and swift and julia were born with compelling concurrency and parallelism features

elixir still beats out ruby and python (although python is getting close) but people using ruby and python today largely don't care about these things. they know the limitations and they accept them. if they didn't they have a wealth of languages to pick from

elixir/erlang no longer occupy a unique niche. the other languages have caught up and offer "good enough" libraries and apis. they also bring much to the table that erlang/elixir don't. elixir may lead in concurrent programming but users choose languages that lead in community, ecosystem, compatibility, commercial appeal, etc. for elixir to compete with go, node, java, python it needs (or needed) to offer more

(i say all this as someone who really wishes erlang had 'won'. it's by far my favorite language when you consider solely the syntax and semantics of the code itself. pattern matching should be ubiquitous in modern languages. data should be immutable, full stop. i'd rather write a foldl than a for loop. it didn't win though and the erlang vm is roughly identical today to the erlang vm i was using in 2012 (this isn't to say it hasn't seen improvement but the improvement has been incremental and modest). the ecosystem moves at a glacial pace compared to that of node or go or even a relatively unpopular language like rust or julia)

[josevalim]

Agreed that the concurrency gap has narrowed in certain cases or either people don’t care, but I have always seen concurrency/distribution as “enablers”.

You can have the best concurrency story in the world, but if you don’t have good tooling or you don’t focus on the DX, then people will just leave (or perhaps not even start).

Concurrency/distribution is what allows Phoenix to be a real-time, productive, and scalable web framework on its own.

Nerves rely on fault tolerance to bring sanity to embedded systems.

And so on.

In turn those are led by teams who saw the language features and noticed they addressed many issues they were struggling with in other platforms.

But at the end of the day, for languages like Elixir, the frameworks and tools are much better equipped to attract developers than “raw” language features.

PS: disagree on the Erlang VM bit. JIT, dirty NIFs, and maps immediately come to the top of my head as big and important changes in the last 10 years. There have been many usability focused changes in the last 2 years too, in error messages, the shell (upcoming), etc.