Writing Your Own Beam
Postedabout 2 months agoActiveabout 2 months ago
martin.janiczek.czTechstoryHigh profile
calmpositive
Debate
20/100
BeamErlangVirtual Machine
Key topics
Beam
Erlang
Virtual Machine
The article discusses writing a minimal BEAM (Erlang Virtual Machine) implementation, sparking interest and discussion among HN users about the BEAM's design, portability, and potential applications.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
1d
Peak period
11
30-36h
Avg / period
5.7
Comment distribution34 data points
Loading chart...
Based on 34 loaded comments
Key moments
- 01Story posted
Nov 9, 2025 at 1:29 PM EST
about 2 months ago
Step 01 - 02First comment
Nov 10, 2025 at 4:30 PM EST
1d after posting
Step 02 - 03Peak activity
11 comments in 30-36h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 12, 2025 at 7:43 PM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45867828Type: storyLast synced: 11/20/2025, 4:23:22 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.)
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.
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 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...
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.
https://www.cachix.org/ simplifies running a custom cache. Well worth the money, IMO.
That said, learning nix and setting up a nix cache is still a lot of work. Docker buildx might offer you some more knobs to cache portions of your build in a finer-grained manner without having to take the nix plunge.
As long as the specific version of Erlang you’re using is present in either your Nix store or the global cache for your OS and arch (at cache.nixos.org), you should not need to compile anything.
And if you rely on custom builds, you can just setup your own binary cache. This is similar to remote caching in Bazel.
Some more details on Nix caching here: https://zero-to-nix.com/concepts/caching/
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".
In any case 'nix-shell -p erlang|elixir' does not seem too complicated to me.
> 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...
So I think it is perfectly appropriate to suggest a sharp tool.
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/
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...
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
Limbo is incomplete, forget what exactly but a few people on the 9fans discord recently ran into issues. Always remember, Inferno was forced onto the Labs people by Lucent in an attempt to compete with Sun's Java and built in a year. Bell Labs did not do marketing and Lucent fumbled the whole thing.
Plan 9 in a box is only useful if you MUST use a foreign host like Linux. Otherwise I would much prefer the machine actually run Plan 9.
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/
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
52 more comments available on Hacker News