[jerf]

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

[mustermannBB]

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.

[loxs]

> a message bus is kinda integrated in the BEAM runtime or Erlang

You have that on a single node. If you need to run more than one node, you will end up inventing your own on top of mnesia and usually the results are not spectacular or/and you will end up paying happihacking to do it for you. Or one of the other Erlang oldtimers who you can count on the fingers of your hands.

This is really suboptimal compared to what you can achieve by using any normal language + any message bus. You are actually much better using a proper message bus even if you use Erlang.

[giraffe_lady]

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.

[jerf]

"I understand how you could see it that way."

It is less that "I see it that way" then that "I encounter plenty of people who speak that way.", and that the Erlang community still definitely indoctrinates people to think that way.

See my other post on the topic: https://news.ycombinator.com/item?id=44181668 Which echos some of your points.

[prophesi]

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.

[cianuro_]

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?

[jerf]

BEAM is basically the combination of a clustering system, a message bus for communicating among its nodes with a defined protocol, and a shared data model that can be thought of as basically "JSON, and only JSON, is the data model"; not JSON mapped into data structures or classes, but just JSON.

The biggest thing you need to have to have BEAM-like reliability is a message bus. Build a message-bus based system and use it properly and you're already 80% of the way there. In 1998, who knew what a "message bus" was? Today, it's a field so stuffed with options I won't even try to summarize them here. The one thing I will point out is that BEAM is 0-or-1 and 1-or-n seems to have won the race; this is one of the things I don't like about BEAM's message bus.

BEAM is based on a JSON-like data scheme because it wasn't clear how to have what you'd consider "classes" and such on a cluster with multiple versions of things any other way. Since then, there are now multiple technologies to solve this problem, like gRPC, Cap'n Proto, and again, what was "who's heard of that?" in 1998 is now an entire field of options I can barely summarize. It is no longer necessary to sacrifice everything we get with "methods" and "user data types" to have cross-cluster compatibility.

Bringing up clusters is now just Tuesday for a devops team. Kubernetes, Docker Cloud, all the cloud-specific orchestrations like CloudFormation, bringing up clusters of things now has many technologies you can deploy. Moreover, these technologies do not impose the requirement that your nodes be essentially homogeneous, all running BEAM. You can bring up any tech stack you like doing any specialized tech stuff you need, all communicating over shared message busses.

Reliability options vary widely, from running internal services in OS processes to capture and restart things, to things like lambda functions that are their own solution to that sort of reliability, to isolated micro-VMs, to threading-based solutions... while there is a certain appeal to "just crash and take the thread down" it's not the only option anymore. Now that every language community that can is building huge servers with millions of threads in them, many solutions to this problem have developed, with different cost/benefit tradeoffs for each. The "crash out the whole thread" is not the only option, merely one interesting one.

As to how they compare to BEAM, that does slant the question a little bit, as if BEAM is the golden standard that everyone else is still desperately aspiring to. How they compare to BEAM is that there is now a zoo of options of every sort, with a huge variety of tradeoffs in performance and cost and ease-of-use and ease-of-deployment, and BEAM is merely a particular point in the huge field now, which I wouldn't even characterize as particularly standing out on any front. For every thing it does like "have a nice crashing story" there's a tradeoff where it did things like "give up user-defined data types because they couldn't figure out how do to them in a cluster in the late 1990s". BEAM's feature set, on a feature-by-feature basis, isn't particularly special any more. There's faster options, there's easier options, there's "works with my current language" options, there's more reliable options, there's cheaper options, there's all kinds of things... but not all of these at once necessarily.

So, what is BEAM's unique value proposition in 2025? It is the integration of the solutions, and picking a set of solutions that IMHO may not be "the best" on any particular front any more but has proved to be "adequate to many tasks" for decades now. You can assemble all those technologies I mentioned in an incredible number of combinations, but you have to do the assembly yourself, and burn time asking yourself, which message bus? Which clustering? Which orchestration? It's overwhelming, and made even harder by the fact that even with all these choices there's still a lot of developers who don't even know these things exist, let alone how to evaluate them and start integrating them into a system successfully. BEAM offers a one-stop shop, with prepared and opinionated answers with a proved track record, and a community that knows how to use them, libraries that integrate with the opinionated answers. I.e. who can write a library that "works with Kafka, Amazon SQS, NATS, Redis streams, Postgres events, and a dozen other messaging libraries" without having to work with a lowest common denominator that is almost useless? But someone can definitely provide "an Erlang library" that meaningfully integrates with all of the BEAM infrastructure without an issue. I don't think BEAM is best-of-breed on any particular front but it is arguably best-of-breed in providing them an answer to you for all these problems under a single roof, and then being able to build on the advantage that picking a set of solutions brings you.

I wish the BEAM/Erlang/Elixir community would lean more into this as their pitch, and stop running around and acting like they've got the only solution to the problems and as if they are the gold standard. The advantage of BEAM is not that they have the only reliability solution, the only message bus, the only clustering solution, the only etc. etc. anymore... the advantage is in the integration. The individual components of the solutions are not where the awesomeness lies; in 2025 most of them have been handily exceeded on many fronts now, but that integration and the subsequent things like libraries built on that integration is a unique proposition, even today. The very explosion of choice in the solutions to the problems BEAM addresses and the resulting diaspora in all the code bases in the world make it difficult to build very much on top of these things because there's so many differences in so many places.

[garbthetill]

I’m actually kind of a fan, I’ve read your past comments on BEAM and Elixir while digging through HN to get a sense of how people view it. I appreciate your takes, but I’m honestly confused by this one and wanted to push back a bit, I'm not as knowledgeable as you on this topic, but bear with me

I get your point that BEAM’s individual components might not be the best in 2025 and you get the point of uniformity. so whats the point of saying there's a better BEAM like system, but then fail to point out one? Elixir/BEAM community promoting themselves as the only solution to said problems isn't a bad thing imo, because what other system can give me the guarantee without forcing me to learn a bunch of new DSLs or scripting languages, and deal with the idiosyncrasies of a bunch of different systems? With Elixir or Erlang, I can stick to one coherent environment and get all that.

Again you state all this in your post, yet say elixir/beam isn't the gold standard, then what is? As i am having a blast working with phoenix, liveview and nerves and the BEAMS guarantee of a ms soft real time fault tolerant system hasn't failed me yet and there doesnt seem to be anything like it in the market. The only thing I hate about elixir is types and would switch to rust/go if there was a similar offering

[jerf]

"but then fail to point out one?"

I didn't point out one, I pointed out thousands. All the combinations of message busses and serializations and schedulers and monitors you can imagine. Systemd monitoring a selection of processes that read and write from kafka queues in a cluster of VMs. Lambda functions that read and write Amazon SQS/SNS queues written in Go. Azure Functions using JSON to communicate over Azure Service Bus with Terraform configuring redundancy. A microservices architecture orchestrated with etcd based on gRPC services communicating with each other on a NATS message bus. Arbitrary mixes and matches of all of these things, probably the most common architecture of all at a corporate level.

Many of these beat BEAM on some metric or other that may be important at some point. For instance it's not hard to beat BEAM on performance (though it is also not hard to lose to it on performance; it's a very middle-of-the-road system on that front, which I mean completely literally). Another thing that you get very naturally is heterogeneity; if you want everything on a BEAM system you really have to stick to BEAM's languages, which is a pretty big issue in most cases.

The reason I say BEAM is not the gold standard is that there's still people running around who speak as if BEAM is the only way to write reliable software, that it is still the only way to have lots of independent services that communicate by passing messages, that if you don't implement every single one of gen_server's features and work exactly like OTP's supervision trees and if you don't handle errors by crashing processes, then you're not operating at Erlang's Golden Standard.

And that's not true anymore. There's plenty of alternatives, many better than BEAM on many fronts. BEAM is not the natural obvious leader standing above the rest of the crowd, secure in the knowledge that nothing is as good as it is and never will be. It's now down in the scrum, and as long as it is metaphorically running around claiming it's somehow unique I'm going to grumble about it. It's not even good for BEAM itself, which really ought to be pitching integration rather than "Look! We solve the reliability problem uniquely!"

To the extent that people are reading my post and basically backpedaling and insisting "Oh, no, it's the integration all along that we've been pitching"... well, I don't particularly enjoy the rewriting of history, but other than that... yes! Good! Do that! Pitch the integration! It's a legitimate advantage! But it's not 2005 anymore. Every major compiled language can handle tens or hundreds of thousands of connections on a reasonably sized server. Every language has solutions for running this robustly and with decoupled architecture. Every language has solutions to the problems now. BEAM's in a crowd now, whether it likes it or not.

There is no gold standard for these technologies any more. One might as well ask "well, what's the best computer?" There's no answer to that question. Narrow it down to "what's the best gaming computer" and you can still ask "what sort of games" and it'll be a crowded field. There's more options that anyone can even analyze anymore.

[lvass]

Do note that many things mentioned just happen to be incentivized or default in the BEAM, but are not required at all. Your processes don't have to crash if you don't want to let them crash, exception handling is there. Messages don't have to be 0-or-1, Manifold exists. You are absolutely not forced to use some language, you have NIFs, dirty NIFs, ports, rustler, zigler, pythonx, etc, many offering impeccable ergonomics. Some things may not be as optimized as alternatives are? Sure, but the BEAM works for Whatsapp and Discord and of all things they just use raw ETS for their most important data structure. You almost surely don't need something "better".