Wikipedia says "Originally BEAM was short for Bogdan's Erlang Abstract Machine, named after Bogumil "Bogdan" Hausman, who wrote the original version, but the name may also be referred to as Björn's Erlang Abstract Machine, after Björn Gustavsson, who wrote and maintains the current version."
Whether the B is for Bogdan or Bjorn, there's something really fun and Space Quest-y about it.
The BEAM is fascinating for many reasons, including being register-based.
I really just wish the BEAM was portable in the way the JVM is. The BEAM hooks into so many system libraries, you must compile it on every flavor of linux instead of just unpacking a tarball.
This means you either must use your distro package manager's version, or compile from scratch. If you want to control the exact version that's being used across your team (via `asdf` or similar), this practically means you'll end up compiling the BEAM over and over...
Burrito works very well in my experience. I've used it for distributing an implementation of breakout in Elixir with OpenGL and Metal rendering backends as a binary. Pretty neat!
> The BEAM is fascinating for many reasons, including being register-based.
> I really just wish the BEAM was portable in the way the JVM is.
Inferno is both register based and highly portable using the same tool chain as Plan 9 which runs seamlessly across multiple architectures. This eventually evolved into the Go tooling as Rob Pike came up with the Plan 9 design and worked on it with Ken Thompson. https://seh.dev/go-legacy/
Unfortunately Inferno was never fully completed and bit-rotted a bit but it still builds on systems with 32 bit support. There are various forks and even an attempted 64 bit version. To me its a great design as it not only runs on bare metal but also has a hosted option so it runs under Plan 9, Windows, MacOS/Unix/BSD/Linux. Talk about a portable OS...
To be clear, Inferno is the operating system. The virtual machine is Dis. There exist a few examples[1] of 64-bit Dis, but usually the problem people run into is making the Limbo[2] compiler spit out 64-bit code.
It's rather unfortunate, Inferno is a really nice system with a lot of interesting reference stuff implemented like a typed shell[3]. It's also Plan 9 in a box with all the accoutrements, and knowers will have jumped out of their seat at the implication. I can't understate how cool the Inferno system is.
Correct me if I'm wrong, but you'd still have to compile it from source on nix, no?
On my relatively powerful workstation, Erlang/BEAM takes about 7 minutes to compile.
We're working around this currently by having a fat devcontainer image, pre-built with Erlang inside (from source) by our CI. It chews through CI minutes unavoidably due to how docker layer caching works.
It would be awesome to just download and unpack a tarball, regardless of which distro you're using.
Nix is enormously complicated, kind of unstable and not well documented.
I get that if you've gone through the pain of learning it you get a system with some very nice properties. But casually suggesting "maybe try nix" is a bit like telling someone who wants to listen to Mozart "maybe try playing a piano".
Nice. Have to spend some time reading it but i really like the minimalistic and clean design of your site content. No unnecessary colors/asides/verbiage/etc. nonsense but THE content and only the content presented directly.
A suggestion: Please add a "Overview" section in the beginning to provide the big-picture architecture since without that it would be hard to understand your code.
Did not know about it much before but apparently was doing something similar (in spirit) when experimenting with simple task execution queues in go. This is quite interesting and given that hot code reloading is a thing in beam it might be something to explore further.
The next best thing : Implementing a Functional Language for Highly Parallel Real Time Applications by J.L.Armstrong et al. (pdf) - https://www.cs.tufts.edu/~nr/cs257/archive/joe-armstrong/erl... Seems like this is the design behind the original JAM VM. The "References" section cites more early work.
See also The Erlang BEAM Virtual Machine Specification by the OG Bogumil Hausman himself ! Note: This document describes BEAM as it was in 1997. BEAM has grown and changed significantly between then and the time this note was added (2012). This information is mainly for historical interest.
- https://www.cs-lab.org/historical_beam_instruction_set.html
Together, they should provide a lot of insights into ERTS/BEAM.
Joe used to have all that code in his world-readable NFS-mounted home directory. He would just create a new directory for every idea or project. Take it with him from one computer to the next.
I hope that's preserved and one day published as e.g. the old MIT AI lab file system snapshots were.
(Robert Virding or Bjärne Däcker might well have a copy of the Prolog code to share if asked nicely.)
When can we be done with these cheap comments? It has really become tiring to have a comment tree on every HN post for people who don't know what the article is about. As the author often didn't submit their own article it is just a complaint with no possible resolution. Instead of taking a few seconds to find out what the article is about and maybe even clarifying it for your fellow readers, you are taking that time to write a comment that only detracts from a possible conversation.
If you can't bring yourself to search for 5 seconds and find out what an article is about, maybe you just close it and move on.
The tone in which people like the parent comment is disgraceful. I’m sorry this is hacker news and hackers know that BEAM is the Erlang VM, no introduction or explanation needed. It is respected and admired as a great piece of engineering to be studied by all hackers.
I still remember 14 years ago or so, when applied science posted his diy electron microscope build and a handful of top comments were low effort nerd snipes and criticisms.
Nothing to do about it, I don't think. Its the warty culture here.
> I was always fascinated with BEAM (Bogdan Erlang Abstract Machine, a VM for languages like Erlang and Gleam) and how it allowed easy spawning of processes that didn’t share state, allowed for sending and selectively receiving messages, and linking to each other thus enabling creation of supervision trees.
That's all it takes. When you're writing about a niche topic (and nearly everything and anything interesting is a niche topic) then explain your jargon. It's considerate, reminds people who are familiar but might have forgotten, and introduces people unfamiliar with it to what your topic is.
Sometimes people want to understand what they're reading about and not have to play a little "guess what this is about" game. Clarity is a quality of good writing.
I think its written for people who already know what the BEAM is. The BEAM is the VM for Erlang or Elixir, similar to how Java has the JVM and C# has .NET essentially.
I feel like this is just an opportunity to either learn what it is or move on. That’s essentially what hn and “hacking” is, isn’t it? This post caught my eye because I was learning about BEAM just last week for the first time.
I have learnt to love and embrace the BEAM.
Wikipedia says "Originally BEAM was short for Bogdan's Erlang Abstract Machine, named after Bogumil "Bogdan" Hausman, who wrote the original version, but the name may also be referred to as Björn's Erlang Abstract Machine, after Björn Gustavsson, who wrote and maintains the current version."
Whether the B is for Bogdan or Bjorn, there's something really fun and Space Quest-y about it.
I like to think the B stands for BEAM.
It obviously stands for "Benoit B Mandelbrot"
Very cliché.
4 replies →
Same here! I also don't want "the facts to come in the way of a good story", and want to believe B is BEAM.
1 reply →
The BEAM is fascinating for many reasons, including being register-based.
I really just wish the BEAM was portable in the way the JVM is. The BEAM hooks into so many system libraries, you must compile it on every flavor of linux instead of just unpacking a tarball.
This means you either must use your distro package manager's version, or compile from scratch. If you want to control the exact version that's being used across your team (via `asdf` or similar), this practically means you'll end up compiling the BEAM over and over...
You want https://github.com/burrito-elixir/burrito
This is very neat, thanks for the link!
Digging into it, you can get "universal" BEAM tarballs from here[1]. It links against muslibc and appears to bring it's own openssl. Very cool.
[1] https://beammachine.cloud/
Burrito works very well in my experience. I've used it for distributing an implementation of breakout in Elixir with OpenGL and Metal rendering backends as a binary. Pretty neat!
> The BEAM is fascinating for many reasons, including being register-based. > I really just wish the BEAM was portable in the way the JVM is.
Inferno is both register based and highly portable using the same tool chain as Plan 9 which runs seamlessly across multiple architectures. This eventually evolved into the Go tooling as Rob Pike came up with the Plan 9 design and worked on it with Ken Thompson. https://seh.dev/go-legacy/
Unfortunately Inferno was never fully completed and bit-rotted a bit but it still builds on systems with 32 bit support. There are various forks and even an attempted 64 bit version. To me its a great design as it not only runs on bare metal but also has a hosted option so it runs under Plan 9, Windows, MacOS/Unix/BSD/Linux. Talk about a portable OS...
To be clear, Inferno is the operating system. The virtual machine is Dis. There exist a few examples[1] of 64-bit Dis, but usually the problem people run into is making the Limbo[2] compiler spit out 64-bit code.
It's rather unfortunate, Inferno is a really nice system with a lot of interesting reference stuff implemented like a typed shell[3]. It's also Plan 9 in a box with all the accoutrements, and knowers will have jumped out of their seat at the implication. I can't understate how cool the Inferno system is.
[1] - https://github.com/Plan9-Archive/9ferno
[2] - https://en.wikipedia.org/wiki/Limbo_(programming_language)
[3] - https://inferno-os.org/inferno/man/2/alphabet-intro.html
1 reply →
> The BEAM hooks into so many system libraries, you must compile it on every flavor of linux instead of just unpacking a tarball.
This isn't true, one can statically compile the BEAM for Linux exactly the same as the JVM. Here's an example: https://github.com/yoshi-monster/static_erlang/
Perhaps you should give Nix a try :)
Correct me if I'm wrong, but you'd still have to compile it from source on nix, no?
On my relatively powerful workstation, Erlang/BEAM takes about 7 minutes to compile.
We're working around this currently by having a fat devcontainer image, pre-built with Erlang inside (from source) by our CI. It chews through CI minutes unavoidably due to how docker layer caching works.
It would be awesome to just download and unpack a tarball, regardless of which distro you're using.
2 replies →
Nix is enormously complicated, kind of unstable and not well documented.
I get that if you've gone through the pain of learning it you get a system with some very nice properties. But casually suggesting "maybe try nix" is a bit like telling someone who wants to listen to Mozart "maybe try playing a piano".
4 replies →
Nice. Have to spend some time reading it but i really like the minimalistic and clean design of your site content. No unnecessary colors/asides/verbiage/etc. nonsense but THE content and only the content presented directly.
A suggestion: Please add a "Overview" section in the beginning to provide the big-picture architecture since without that it would be hard to understand your code.
PS: In case you didn't see it, my comment here mentions some documents that you might find useful for your implementation - https://news.ycombinator.com/item?id=45883694
Did not know about it much before but apparently was doing something similar (in spirit) when experimenting with simple task execution queues in go. This is quite interesting and given that hot code reloading is a thing in beam it might be something to explore further.
Now I'm curious whether Joe Armstrong's original Prolog implementation of the VM is available anywhere, but I doubt it.
The next best thing : Implementing a Functional Language for Highly Parallel Real Time Applications by J.L.Armstrong et al. (pdf) - https://www.cs.tufts.edu/~nr/cs257/archive/joe-armstrong/erl... Seems like this is the design behind the original JAM VM. The "References" section cites more early work.
See also The Erlang BEAM Virtual Machine Specification by the OG Bogumil Hausman himself ! Note: This document describes BEAM as it was in 1997. BEAM has grown and changed significantly between then and the time this note was added (2012). This information is mainly for historical interest. - https://www.cs-lab.org/historical_beam_instruction_set.html
Together, they should provide a lot of insights into ERTS/BEAM.
Joe used to have all that code in his world-readable NFS-mounted home directory. He would just create a new directory for every idea or project. Take it with him from one computer to the next.
I hope that's preserved and one day published as e.g. the old MIT AI lab file system snapshots were.
(Robert Virding or Bjärne Däcker might well have a copy of the Prolog code to share if asked nicely.)
Clicked on the link because I don’t know what a “BEAM” is, was not disappointed
[flagged]
When can we be done with these cheap comments? It has really become tiring to have a comment tree on every HN post for people who don't know what the article is about. As the author often didn't submit their own article it is just a complaint with no possible resolution. Instead of taking a few seconds to find out what the article is about and maybe even clarifying it for your fellow readers, you are taking that time to write a comment that only detracts from a possible conversation.
If you can't bring yourself to search for 5 seconds and find out what an article is about, maybe you just close it and move on.
Agreed.
The tone in which people like the parent comment is disgraceful. I’m sorry this is hacker news and hackers know that BEAM is the Erlang VM, no introduction or explanation needed. It is respected and admired as a great piece of engineering to be studied by all hackers.
19 replies →
Hn has for the most part always been like this.
I still remember 14 years ago or so, when applied science posted his diy electron microscope build and a handful of top comments were low effort nerd snipes and criticisms.
Nothing to do about it, I don't think. Its the warty culture here.
> I was always fascinated with BEAM (Bogdan Erlang Abstract Machine, a VM for languages like Erlang and Gleam) and how it allowed easy spawning of processes that didn’t share state, allowed for sending and selectively receiving messages, and linking to each other thus enabling creation of supervision trees.
That's all it takes. When you're writing about a niche topic (and nearly everything and anything interesting is a niche topic) then explain your jargon. It's considerate, reminds people who are familiar but might have forgotten, and introduces people unfamiliar with it to what your topic is.
Sometimes people want to understand what they're reading about and not have to play a little "guess what this is about" game. Clarity is a quality of good writing.
3 replies →
> It has really become tiring to have a comment tree on every HN post
Has it actually? Why is this "tiring?"
> When can we be done with these cheap comments?
Do what most other people did. Write a cheap reply.
> you are taking that time to write a comment that only detracts from a possible conversation.
Just click the little [-].
> maybe you just close it and move on.
Ironic.
1 reply →
[dead]
I think its written for people who already know what the BEAM is. The BEAM is the VM for Erlang or Elixir, similar to how Java has the JVM and C# has .NET essentially.
> similar to how Java has the JVM and C# has .NET essentially.
I'm pretty sure that in this analogy, C# has the CLR.
1 reply →
[flagged]
18 replies →
> This is my Code BEAM Europe 2025 talk, converted to a blogpost.
The blog is a text version of the talk, not an invitation to watch the talk.
I feel like this is just an opportunity to either learn what it is or move on. That’s essentially what hn and “hacking” is, isn’t it? This post caught my eye because I was learning about BEAM just last week for the first time.
The VM used for Erlang and Elixir.
...and Gleam.
2 replies →
https://en.wikipedia.org/wiki/BEAM_(Erlang_virtual_machine)
Beautiful! :clap: