10 ms·

Are there any other VM's like the BEAM? I never heard of any (admittedly I know little of this subject), and I wondered, is it because there is no need for ano

Are there any other VM's like the BEAM? I never heard of any (admittedly I know little of this subject), and I wondered, is it because there is no need for another one because the BEAM is just so good, or is it because the amount of work and skill required to get another BEAM-like runtime with comparable quality is too demanding?

oldpersonintx2 1y ago
[dead]
lawik 1y ago
There is a separate implementation for really constrained device use, called AtomVM. There are many dead efforts to implement something like the BEAM or OTP within other ecosystems. Usually not as a VM.
- reddit_clone 1y ago
  I have seen attempts at actor systems like erlang/beam's. Scala/Akka seems to have been a success? Share nothing, green-thread/coroutines also seem popular now a days.
  - lvass 1y ago
    C++ Actor framework is also considerably popular, and Scylladb has their own framework which I believe does something similar.
    - lamuswawir 1y ago
      Foundationdb also has it's own C++ actor framework.
jerf 1y ago
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 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.
- prophesi 1y ago
  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.
- giraffe_lady 1y ago
  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 1y ago
    "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 https://news.ycombinator.com/item?id=44181668 Which echos some of your points.
- cianuro_ 1y ago
  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 1y ago
    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.
url00 1y ago
The reality is modern Kubernetes infrastructure looks a lot like BEAM, at least in the capabilities it offers. That's the far more common way of deploying highly scalable, self-healing systems in the current year. Plus, with k8s you're not constricted to a single language (there are a few more than Erlang/Elixir, but nothing popular) with limited developer resources and interest.
- MarceColl 1y ago
  So now you need several servers, an orchestrator, tons of YAML, arcane and terrible error messages and a devops team to kind of match the BEAM? That's... not a good look
  - tough 1y ago
    is that a fair comparison? i dont love k8s but you can deploy anything to it, not just erlang or elixir
    - giraffe_lady 1y ago
      It's snarky but I think it is a fair comparison. You do have extra capabilities over what BEAM offers, in exchange for having to manually handle a lot of things BEAM either handles invisibly or at least comes with usable defaults for.
    - toast0 1y ago
      You can use a BEAM system to orchestrate other code, too. As ports, port drivers, nifs, c-nodes, just other OS processes spawned and using IPC/sockets. Lots of options. Using Erlang to supervise an OS process doing work perhaps enhances the isolation principles of BEAM.
      - tough 1y ago
        oh interesting wasnt really aware so you could use beam to orchestrate go or rust services communicating over IPC? Nice
rkangel 1y ago
I think the closest in wide use is probably Go. The BEAM is set up for "Erlang like languages" (or maybe it's the other way around). Writing Elixir, still feels a lot like Erlang because of the underlying semantics of how it operates. Even Gleam is closer to Erlang than anything else once you get past the types. Go also has goroutines/green threads/Erlang-like processes as a core primitive for its parallelism. it doesn't have the same "opinion" about how to structure a concurrent application that you get from OTP though.
johnnyjeans 1y ago
Dis is probably the closest, followed by the smalltalk VMs. It depends on what you mean by "like the BEAM". The VM itself isn't that special, it's really the whole OTP on top of BEAM that makes Erlang good at what it does.

oldpersonintx2 1y ago

[dead]

lawik 1y ago

There is a separate implementation for really constrained device use, called AtomVM. There are many dead efforts to implement something like the BEAM or OTP within other ecosystems. Usually not as a VM.

reddit_clone 1y ago
I have seen attempts at actor systems like erlang/beam's. Scala/Akka seems to have been a success? Share nothing, green-thread/coroutines also seem popular now a days.
- lvass 1y ago
  C++ Actor framework is also considerably popular, and Scylladb has their own framework which I believe does something similar.
  - lamuswawir 1y ago
    Foundationdb also has it's own C++ actor framework.

jerf 1y ago

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

prophesi 1y ago
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.
giraffe_lady 1y ago
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 1y ago
  "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 https://news.ycombinator.com/item?id=44181668 Which echos some of your points.
cianuro_ 1y ago
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 1y ago
  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.

url00 1y ago

The reality is modern Kubernetes infrastructure looks a lot like BEAM, at least in the capabilities it offers. That's the far more common way of deploying highly scalable, self-healing systems in the current year. Plus, with k8s you're not constricted to a single language (there are a few more than Erlang/Elixir, but nothing popular) with limited developer resources and interest.

MarceColl 1y ago
So now you need several servers, an orchestrator, tons of YAML, arcane and terrible error messages and a devops team to kind of match the BEAM? That's... not a good look
- tough 1y ago
  is that a fair comparison? i dont love k8s but you can deploy anything to it, not just erlang or elixir
  - giraffe_lady 1y ago
    It's snarky but I think it is a fair comparison. You do have extra capabilities over what BEAM offers, in exchange for having to manually handle a lot of things BEAM either handles invisibly or at least comes with usable defaults for.
  - toast0 1y ago
    You can use a BEAM system to orchestrate other code, too. As ports, port drivers, nifs, c-nodes, just other OS processes spawned and using IPC/sockets. Lots of options. Using Erlang to supervise an OS process doing work perhaps enhances the isolation principles of BEAM.
    - tough 1y ago
      oh interesting wasnt really aware so you could use beam to orchestrate go or rust services communicating over IPC? Nice

rkangel 1y ago

I think the closest in wide use is probably Go. The BEAM is set up for "Erlang like languages" (or maybe it's the other way around). Writing Elixir, still feels a lot like Erlang because of the underlying semantics of how it operates. Even Gleam is closer to Erlang than anything else once you get past the types. Go also has goroutines/green threads/Erlang-like processes as a core primitive for its parallelism. it doesn't have the same "opinion" about how to structure a concurrent application that you get from OTP though.

johnnyjeans 1y ago

Dis is probably the closest, followed by the smalltalk VMs. It depends on what you mean by "like the BEAM". The VM itself isn't that special, it's really the whole OTP on top of BEAM that makes Erlang good at what it does.