[dynamite-ready]

I mean, Elixir is definitely not a replacement for Rust. I imagine it as being closer to Node, Python, or possibly Java. And even then, it's a wild comparison, because of the way Actor Model concurrency is weaved into BEAM languages, in a way that no other language does.

For perf optimisations, you have Ports or NIFs (irc), where Ports are just knowingly volatile processes, and NIFs are FFIs, which is an almost universal feature across all languages.

But I suppose your experience is based on use case. And I would agree that commercial BEAM language experience is generally thin on the ground, if you're role is to build an engineering team (though I can't imagine Rust expertise being that much more abundant either).

One thing I would add, is Erlang/Elixir's emphasis on multi machine concurrency is somewhat at odds with the serverless future we're moving towards. But ignoring that (especially with vendor lock in issues), I often wonder why Elixir hadn't put a larger dent in the popularity of Kubernetes. Because BEAM's approach to managing multiple services across machines seems both much more powerful, and dev friendly.

[josevalim]

> One thing I would add, is Erlang/Elixir's emphasis on multi machine concurrency is somewhat at odds with the serverless future we're moving towards

IMO, that's a misconception. They work at different levels and I wrote a more in-depth explanation here: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...

Although I agree the sentiment plays a role on adoption, because many ask "why Elixir when I have k8s", while in practice, if you like k8s, you should enjoy Erlang/Elixir. They apply similar principles at different scales.

So I don't think we could have made a dent on k8s, but rather, we should have positioned ourselves earlier within k8s strengths. :)

[iterateoften]

The issue I found myself in is that I agree with you, that Elixirs Actor paradigm is completely different and not comparable to other languages, but at the end of the day, very very very few applications and apps that startups work on need that. Most apps now are trending towards serverless. And most of the world gets by without the “operating system in an operating system” approach of BEAM.

Rust can be massively concurrent without Actors and GenServers.

So while the Actor model / let it fail approach changed the way I think, at the end of the day I found the traditional paradigms to actually be faster and cleaner to the real world applications that made me money.