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