AtomVM, the Erlang virtual machine for IoT devices
62 comments
·May 28, 2025mrbluecoat
Really incredible to see the proliferation of micro-VM tools lately. Here's one from just yesterday: https://news.ycombinator.com/item?id=44135977
lawik
This one has been around for a good chunk of years. Recent bonus activity as it is seeing more exploration by the Elixir community right now as a wasm target.
cyberpunk
Does this target smaller devices than nerves? Or just an alternative?
nesarkvechnep
Smaller devices.
cyberpunk
There's also https://www.grisp.org which looks quite similar if a bit more mature
lawik
GRiSP serms to typically hit inbetween Nerves and AtomVM. Grisp have explored some really constrained hardware compared to the typical Nerves device.
AtomVM is to my knowledge a lot of steps further down since they run a much lighter VM than the BEAM. It is also much less proven though.
Nerves, Grisp and AtomVM all do some of the same things. They make some different trade-offs. Heck, Kry10 (proprietary but targets critical infra) even sort of approaches the same thing. Running Erlang/Elixir for resilient embedded systems.
I am on the Nerves team so you can guess my preference. But all are cool. And we all talk to each other. AtomVM is the most obvious complement to Nerves since they target different device classes.
thruflo
This is the VM behind Popcorn https://github.com/software-mansion/popcorn, a project aiming to run OTP and Elixir in WASM:
> Popcorn is a library that allows you to run client-side Elixir in browsers, with Javascript interoperability
Recent ElixirConf keynote introducing it: https://youtu.be/ep--rQO1FRI
amelius
Considering that Erlang originated in the telecom world, I find it a bit odd that mobile development options are lacking. Anything to be expected in that space?
AlphaWeaver
Erlang's use in the telecom sphere has primarily been focused on switching, routing, and real time voice processing on the backend. Beyond just handling cellular traffic, many internet switches are written in Erlang too. It's only recently that Erlang has been used for more of the type of code that could run on the frontend. (The niceness of writing Elixir is a big part of that too.)
The primary blocker to running Erlang on mobile has been the lack of portability of the BEAM VM itself, which is why this project is so exciting!
ramchip
The massive concurrency and fault isolation properties are very nice for telephony switches (and web servers etc.) but not usually super relevant for phone apps.
patmorgan23
Why would a programing language built around accepting and dealing with millions of connections, and used in base stations, routing, and switching be useful for a mobile device?
hinkley
Buzz Aldrin would have killed the Apollo 11 crew if Margaret Hamilton had been a worse developer. He pulled up an optional display during the landing that was overloading the computer due to a bug, and the scheduler kept killing optional tasks to keep the control and guidance systems all running.
There’s the same sort of realtime system in the BEAM. When you run nice to have and mission critical software together life is much less exciting if you have something handling such things.
throwawaymaths
because it was designed as a general purpose programming language that has robust affordances for weird shit like connections dropping due to a backhoe severing your copper into a PBX.
luckily, mobile devices never encounter problems like a backhoe cutting it off from the network.
vendiddy
The programming model of message passing between processes lends itself well to certain types of apps even if you don't need to handle millions of connections.
For example Elixir/Erlang are currently used in certain IoT applications.
hinkley
At the end of the day many IOT devices are just providing or receiving messages.
Lights, fridges, washing machines.
johnnyjeans
The compiler and the binaries it produces run fine on Android and Linux phones.
signa11
> … bit odd that mobile development options are lacking
what do you mean by that? can you please elaborate ? thanks !
amelius
I mean tools to run Erlang apps on iOS and Android, for example.
lawik
It has been done.
https://github.com/elixir-desktop/desktop
And a different variant driven by the server typically:
https://github.com/liveview-native/live_view_native
Not to say it is particularly ideal. But it exists.
signa11
i see ok. well, erlang is more suited to program gateway nodes in the core of 3g/4g networks.
these nodes handle tasks such as handling mobility (managing handovers as cell phones moves from one location to another etc), data transfer f.e providing ip addresses to your phones etc etc.
as you can imagine, this sort of gear lives deep within service providers network, and each entity handles hundreds of thousands of sessions f.e serving an entire state etc etc.
and these nodes cannot go down taking services/sessions with them.
dlahoda
gui is single(immediate mode) or two(graph based) threaded. with some async going to backend or some app defined compute bounded.
there is no need for actors nor green threads. no need for erlang nor go. languages were not designed for gui(unlike js or csharp), will need a lot of boilerplate for trivial patterns.
cess11
Erlang (and Elixir and so on) run fine under Termux. Just slap on Phoenix or something and have your GUI in the phone browser if that's your thing.
People that have succumbed to Apple tell me they have facilities at least as good as Termux so you can probably do something similar there.
svapnil
What's a usecase for this that actually makes sense? Why does Erlang need to run on IoT devices? The main usecases of Erlang I know of are suitable for beefy machines.
Source: former Erlang engineer
kwillets
There's a why page in their docs, but basically it's cheaper than a multitasking OS for doing the same thing. The valueprop of Erlang is lightweight threads and message-passing.
My knowledge of microcontrollers is dated, but the frameworks for Arduino etc. seemed limited on their ability to do event or message-based programming; most example apps at least were a polling loop. The classic architecture of setting up interrupt/event handlers and going to sleep was not there.
johnnyjeans
Why not? Erlang encourages the same kind of really flexible actor-driven architecture that Smalltalk did. It's a nice programming paradigm that's more general than you think, and the hornclause syntax is really, really nice. Very pleasant to use like this.
sph
Smalltalk had nothing to do with actors. It was largely a single core system.
ninetyninenine
I don’t know about small talk but a single core system is orthogonal to a highly concurrent system which actors represent.
throwawaymaths
before they went under IIRC bowery farms was using BEAM for a fleet of vertical farm in their automated farming robotics, i imagine the no-nonsense networking and clustering was an advantage (i don't know for sure)
imagine youre automating your home, with an rpi here and a gpu node here etc. wouldn't it be nice to immediately have dev access to any node in your home just by connecting to any node?
cess11
The renowned AXD301 ran on 68k and UltraSPARC II processors. An ESP32 isn't that far off with its 240-ish MHz.
Initially Erlang was developed on VAX, at what, 3 MHz or so? Since then decades of optimisations have gone into the BEAM.
simoncion
A lot of optimization has happened to that VM, yeah. However, it has likely gotten a lot more complex. One source of complexity that comes to mind is SMP support.
(Do I have any idea how the VM would run on a 200 MHz machine? Hell no. I'm just mentioning that the thing has also gotten more complex as time has gone by.)
cess11
Multi-core support and clustering was early requirements, hence the OS-like structures organised around the process implementation where the VM starts a scheduler as part of it booting.
Could you be more explicit about what you think has become more complex?
hinkley
It was originally built for phone switching hardware.
lsllc
This is really incredible, the esp32 examples are really straightforward compared to the C versions of the same. The Erlang actor model makes this much easier!
... if they can nail the OTA updates and hot-loading of code!
winford
We have most of the groundwork done for OTA updates. We should have some APIs together in the near future. Hot-loading will be more work, but that should be possible after OTA is ready.
throwaway81523
Any chance of a port to the Raspberry Pi Pico 2? It has 520K of ram iirc. The original Pico had half that.
revskill
Why did people reinvent the wheel with JVM while there's already Erlang VM ? Java did poisionate so much generations of people.
jerf
Performance is certainly one reason. BEAM is middle-of-the-road at best.
You also have to buy in to BEAM's data model pretty hard, which would be a big ask even today, let alone twenty years ago.
Also they were roughly contemporaneous anyhow. Asking "why not Lisp?" makes some chronological sense, "why not BEAM?" doesn't.
tombert
I love Erlang but the performance of BEAM has become a bit of a bottleneck for me lately. I thought I could get away with some fairly advanced audio reencoding stuff in pure Erlang, and at least my naive implementation (which admittedly is not nearly as optimized as it could be) is going like 50-100x slower than a roughly equivalent C version.
No doubt that if I went through the code and rewrote large chunks of it, I could almost certainly eliminate a few copies and avoid a few unnecessary computations, but I figured at that point I might as well write it in Rust and use a NIF or port where even a naive implementation is likely to be fast enough. At some point I might see if I can create good NIFs around existing GMP and DCT libraries so that they can be easily used by other people more generally, but not today.
I am pretty sure that if I had written similar code in Java (or even Clojure), it would have been fast enough out of the box, probably around 2-5x slower than the C version, which would have been in my tolerance.
toast0
You might try and see what happens if you get everything into a single compilation unit and enable aggressive inlining.
Depending on what you're doing / where it gets slow, it's possible you could get a significant speedup if the stars align. If your whole processing chain gets inlined into a single function, there's likely to be code that can be eliminated: maybe things calculated and returned but not used or redundant type tests or ???
But, you'll probably be better served with a NIF.
toast0
Erlang was proprietary and under the radar until 1998. The Erlang VM has a different focus than JVM.
uasi
JVM predates BEAM.
pjmlp
Bytecode based runtimes and compiler toolchains predate both, and Erlang came to life in 1986, a couple of years until Oak.
cess11
Java is ten years younger than Erlang. When Java was marketed into the new hot thing in 1996-1997 Erlang was widely used within Ericsson, and in 1997-1998 someone in Ericsson had swallowed the Sun bait and forced the start of a transition to Java. Joe Armstrong and others went to management and convinced them that since Erlang was now useless it should be released as free software, and it surprisingly was.
Which meant that some of them promptly resigned from their jobs and started a company doing freedom Erlang. It took until 2005 or so for Ericsson to confess that they had made a mistake in trying to Java all the things and got around to using Erlang again.
lioeters
> it took until 2005 or so for Ericsson to confess that they had made a mistake
Impressive that someone was able to make that call and accept the situation, after investing half a decade moving to Java. Also says something about the staying power of Erlang and its paradigm, that the company was able to re-adopt it again.
curtisszmania
[dead]
AtomVM is super fun to prototype MCU projects with. It’s what I tend to reach for over micropython etc.
For beefier machines that have SoCs it’s Nerves usually.
And recently a project called Popcorn uses the AtomVM to run BEAM VM code in the browser! Super neat seeing more places to deploy Elixir and Erlang :)