[HN Gopher] AtomVM, the Erlang virtual machine for IoT devices
___________________________________________________________________
AtomVM, the Erlang virtual machine for IoT devices
Author : ahamez
Score : 158 points
Date : 2025-05-28 13:35 UTC (3 days ago)
(HTM) web link (www.atomvm.net)
(TXT) w3m dump (www.atomvm.net)
| amelius wrote:
| 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?
| signa11 wrote:
| > ... bit odd that mobile development options are lacking
|
| what do you mean by that? can you please elaborate ? thanks !
| amelius wrote:
| I mean tools to run Erlang apps on iOS and Android, for
| example.
| dlahoda wrote:
| 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.
| haskman wrote:
| On the contrary, GUIs are basically event driven systems
| that benefit a lot from concurrency
| toast0 wrote:
| X11 is a distributed systems protocol that outputs GUI as
| a side effect :P
| signa11 wrote:
| 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.
| lawik wrote:
| 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.
| cess11 wrote:
| 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.
| ramchip wrote:
| 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.
| AlphaWeaver wrote:
| 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!
| patmorgan23 wrote:
| 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?
| amelius wrote:
| Uniformity of language between back and front-end, and
| communication layers?
| bastawhiz wrote:
| Because the apps on my phone need to be written in the same
| language as the network devices my carrier runs? What?
| amelius wrote:
| That's taking it to its extreme (unnecessary as your
| carrier is a different company), but consider building an
| application like Telegram or WhatsApp, then it would
| certainly be nice to use one language for everything,
| from front-end, back-end to distributed computing stuff.
| victorbjorklund wrote:
| Why? For a small one person team? Sure it would be nice
| to write everything in one language in one repo.
|
| For a large company with lots of developers? Makes less
| sense. Better use the best tools for the tasks.
| toast0 wrote:
| > then it would certainly be nice to use one language for
| everything, from front-end, back-end to distributed
| computing stuff.
|
| People say this, but it's not that helpful, IMHO. Front
| end and backend have different concerns, usually
| different teams, and using anything other than the
| preferred language for a client platform tends towards
| clunky UX.
|
| You can do some sort of core networking library that's
| shared between clients, and I guess there's reasons you
| might want that to be Erlang, but integration feels like
| a lot of work when you can just deal with it in another
| language. Client side concurrency is so much less than
| server side concurrency, it'll be fine.
| normie3000 wrote:
| > usually different teams
|
| Is this a reason to use a different language? Or
| sometimes an effect if doing so?
| throwawaymaths wrote:
| 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 wrote:
| 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 wrote:
| At the end of the day many IOT devices are just providing
| or receiving messages.
|
| Lights, fridges, washing machines.
| hinkley wrote:
| 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.
| johnnyjeans wrote:
| The compiler and the binaries it produces run fine on Android
| and Linux phones.
| mrbluecoat wrote:
| 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 wrote:
| 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 wrote:
| Does this target smaller devices than nerves? Or just an
| alternative?
| nesarkvechnep wrote:
| Smaller devices.
| cyberpunk wrote:
| There's also https://www.grisp.org which looks quite similar
| if a bit more mature
| lawik wrote:
| 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.
| lsllc wrote:
| 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 wrote:
| 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.
| revskill wrote:
| Why did people reinvent the wheel with JVM while there's already
| Erlang VM ? Java did poisionate so much generations of people.
| uasi wrote:
| JVM predates BEAM.
| pjmlp wrote:
| Bytecode based runtimes and compiler toolchains predate both,
| and Erlang came to life in 1986, a couple of years until Oak.
| cess11 wrote:
| 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 wrote:
| > 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.
| cess11 wrote:
| Well, the IT bubble had burst and Sun was basically two
| thirds down the sewer at the time. Re-adopting something
| you had built and proven in the early days of cell phones
| probably looked like very reasonable risk management.
|
| They kept using Java for some things, of course.
| jerf wrote:
| 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.
| toast0 wrote:
| Erlang was proprietary and under the radar until 1998. The
| Erlang VM has a different focus than JVM.
| doawoo wrote:
| 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 :)
| svapnil wrote:
| 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
| johnnyjeans wrote:
| 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 wrote:
| Smalltalk had nothing to do with actors. It was largely a
| single core system.
| hinkley wrote:
| It was originally built for phone switching hardware.
| cess11 wrote:
| 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.
| throwawaymaths wrote:
| 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?
| thruflo wrote:
| 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
___________________________________________________________________
(page generated 2025-05-31 23:00 UTC)