>Why Elixir + Erlang are not more popular for high concurrency projects is a mystery to me.

I work at an Erlang shop.

For Erlang to be useful you need to have massive scale, millions of DAU. Yes Elixir might run your website serving thousands of DAU but Erlang and the BEAM was not invented for you. Few companies have the scale that makes Erlang a reasonable choice.

More pressing these days I believe is that the Erlang ecosystem is all or nothing, the BEAM is like its own little operating system and has extremely (IMHO) complicated setup and configuration with many moving parts: ERTS, epmd, Rebar,... You don't need or shouldn't use container tech and k8s with Erlang because it's already doing that stuff in its own Erlang way - but it's the Erlang way it's extremely unique and unfamiliar to most.

When you have the right use case for Erlang and you see it in action it is truly like black magic, it's been a highlight of my career to work with it.

I believe it's purely marketing

Other languages (Java, C#, Go) are supported by massive corporate backers, who have vested interest in seeing them succeed. Erlang's own corporate owner tried to strangle it in the crib, and even since then they've been standoffishness towards anything apart from technical resources.

We didn't really see much marketing like material arise until things like Elixir came about, and even that is more following the ruby model, which is very dev oriented. And the world to which Elixir emerged in 2014 is very different than the world rails sprung into in 2004.

Devs can usually be convinced about how good BEAMlangs are, but without the glossy, you have a harder time convincing the MBA set

Investment gap is what I'd say too. While Rust, Go, Python, etc... have had massive backers that have managed to invest a ton more into things like static analysis, type checking, and developer ergonomics, the Erlang ecosystem hasn't necessarily had the same love, and instead the major users have typically chosen to pivot, or build something outside of the BEAM.

Because it's a single stack that leaks too many things in my opinion, it's not just code but it's also handling infra, process restart, cache, queue, db ect ... And it only works with Erlang, so it's an all or nothing setup which imo is very restrictive.

Kubernetes does a lot of things that Beam does but better and completely language neutral. Then you have builtin queues and db in Erlang but they are inferior to industry standard and again only work with Erlang.

We swapped our Squarespace website out for a Phoenix application yesterday and it was such a delightful experience.

And now with Gleam moving past version 1.0 last year, the BEAM also boasts a decent amount of "flavors" of functional programming. You can go with Erlang/OTP (the alien tech that has been battle tested for almost 30 years), Elixir for it's great webdev ecosystem, Gleam if you like an ML-like programming language on the BEAM. LFE is also another great option if need a BEAM-native LISP.

At the same time, the least secret "secret sauce" out there. BBC moved to Elixir (quite recent news), so I guess traction is there.

everyone is trying to hire the best, but caters to the lowest common denominator.

"But what if we hire an engineer to stupid to learn a new language in a few weeks???" and on and on and on

> Why Elixir + Erlang are not more popular for high concurrency projects is a mystery to me.

1) Because the amount of "high concurrency" you can handle with a single machine with "standard" languages keeps moving up every year.

2) Because you had a single, nigh undocumented, very impenetrable to port implementation of BEAM for the longest time.

3) Because "Erlang" isn't the magic. OTP is the magic. And that requires that you shift your mindset dramatically. And you can do the OTP abstractions in other languages!

4) I think Scala sucked up a lot of Erlang's oxygen for a long time. Erlang is helping with that.