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.

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.

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.

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.

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.

[dead]