alt Hacker NewsAt the time that BEAM was invented in the late 1990s, and in the early 2000s, it was a fairly unique proposition.
Nowadays there isn't anywhere near as much stuff that it does uniquely. That's probably why there isn't another one. All of the compiled languages off-the-shelf can solve the same problems that BEAM does now, and often with other advantages to boot.
There's something about the Erlang community that convinces people in it that if it isn't solve the exact same way that BEAM does, then it must ipso facto not be as good as BEAM, but that's not true. If you ask the question can I solve the same problems, even if it's in a different way?, you've got a zoo of options in 2025, whereas your options in 2000 were much much weaker.
And yes, being BEAM-compatible is harder than meets the eye. There are projects like https://github.com/ergo-services/ergo that can do it, and I believe there are some in other languages. It's a pretty niche need in my opinion, though. If you don't need to hook up to some existing BEAM infrastructure, I don't consider it a very good solution for a greenfield project. You're better off with more modern tooling and solutions that are more native to your chosen dev environment.
Replies
I agree with what I think is your overall point, that there are other solutions that adequately solve the problems BEAM does but in different ways.
I really strongly disagree with the idea that there's no modern use for BEAM because of these other solutions. It's not simply that we've convinced ourselves that "if it isn't solve the exact same way that BEAM does, then it must ipso facto not be as good as BEAM" though I understand how you could see it that way.
Frankly what it is is that BEAM has an exceptionally well chosen position among the possible tradeoffs of solving these problems, which you are otherwise on your own to figure out and which are in themselves some of the most difficult practical considerations of systems design.
So again it's not that only BEAM can possibly do it right, but it's that BEAM does do it right. Having seen so many other attempts to do it better fail, at tremendous expense, it's an easy choice for me for systems that are expected to encounter these problems.
I'm not sure if it's about the implementation rather than the vast reduction of complexity/boilerplate to attain fault-tolerant distributed systems compared to other solutions.
Can you map the BEAM features against the zoo of options you mentioned so readers understand what exactly are these other options and how they compare to BEAM?
Correct me if I'm wrong but a big part of the value proposition these days for Erlang/Elixir would be that it comes build in with a lot of the tools that other runtimes would require. For example a message bus is kinda integrated in the BEAM runtime or Erlang, while most other runtimes would have to use something like Kafka or AWS SQS etc. Or caching and some other things. Of course I'm not sure how good all the inbuilt solutions are compared to dedicated tools, overall or usually IMHO I prefer dedicated tools as opposed to all in one as the dedicated tools/services usually are more flexible. On the other hand of course it is also much overhead.