AtomVM, the Erlang virtual machine for IoT devices
atomvm.org
atomvm.org
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 :)
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.
> 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
what do you mean by that? can you please elaborate ? thanks !
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.
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.
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.
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.
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!
For a large company with lots of developers? Makes less sense. Better use the best tools for the tasks.
Web apps are JavaScript. Android apps run on a JVM. iOS apps are whatever can compile to native code and use Apple's APIs. When you avoid the runtime of the language that you're expected to build for on a platform, you'll inevitably spent most of your time working just to get a handful of features that you need from the runtime into the language you're choosing to use.
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.
Is this a reason to use a different language? Or sometimes an effect if doing so?
You can't actually build a mobile app entirely in JavaScript, but if your used React Native the parts that actually deal with materially interfacing between the client and the server aren't in JavaScript. At best you can share some typescript definitions.
Java on the server is extremely different from Java on client, and the same can be said for Swift. What do you get to share? Maybe the code that serializes and deserializes messages? But even then that's thanks to a library, not the language (and if you're using a feature of the stdlib, it's almost certainly just as easy to use in any other reasonable language).
Pyodide and PyScrpt exist and you could certainly build a full stack web app with them. Why doesn't anyone, then? It's because doing so doesn't solve any serious problems or make anything much better.
luckily, mobile devices never encounter problems like a backhoe cutting it off from the network.
For example Elixir/Erlang are currently used in certain IoT applications.
Lights, fridges, washing machines.
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.
Source: former Erlang engineer
Initially Erlang was developed on VAX, at what, 3 MHz or so? Since then decades of optimisations have gone into the BEAM.
(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.)
Could you be more explicit about what you think has become more complex?
Erlang's first release was in 1986. Experimental SMP support was added to the Erlang VM in OTP R11B in mid 2006[0]. That's twenty years.
If you were to go back to the time of R11B's release and asked the folks who were aware of it "Has SMP support been added early in the life of the Erlang project?", I expect you would be hard-pressed to find anyone who would answer that question with a "yes". Twenty years after a software project's first release is a pretty damn long time.
If we want to be maximally charitable to you, then we can knock that date back to when the master's thesis work was started (and abandoned) in 1998. That's still more than a decade after the initial release.
It is my understanding that SMP support was a substantial change to the VM, and has gotten more complex as it has been made to perform better and better on larger systems and workloads.
> ...clustering was early requirements...
You are apparently unaware that the way operators who used Erlang handled multi-processor machines was to run multiple independent instances of the Erlang VM and -if desired- use local-machine clustering for intra-instance communications. SMP support is not the same as UP support with local-machine clustering of otherwise-independent program instances.
> Could you be more explicit about what you think has become more complex?
A great many things. The ones that immediately come to mind are SMP, HiPE [1], BeamAsm, dirty schedulers, multi time warp, and Unicode support. You may argue that surely some of the additional complications that have been added since 1986 are not much complication. I would counter that surely some of the optimizations that have been made since 1986 have not been much optimization.
[0] <https://erlang.org/euc/08/euc_smp.pdf>
[1] Unless I'm confused about HiPE... and the native code it produces was already a thing that the Erlang VM could consume. If that's the case, than the obvious complexity of HiPE is all outside Erlang. But the caveats on section 4.1 and 4.2 and acknowledgements in section 6 of [2] make me fairly confident that HiPE was not using already-existing functionality in the Erlang VM.
2006 is the year multicore CPU:s were broadly introduced, it's the year of Core Duo and Athlon 64 X2. Before then clustering of cores looked different. Releasing support for such CPU:s pretty much as soon as they were available rather than a few years later probably says something about the required effort.
One might make a comparison with OCaml.
Edit: A friend of mine mentioned that Björn Gustafsson recently did a talk on optimising the move-instruction at a Code BEAM event. With a bit of luck it was recorded and will be published sometime soon, should be some interesting information in there.
I doubt it. You should read the PDF in footnote zero from my previous comment. I'll copy the link here for your convenience. <https://erlang.org/euc/08/euc_smp.pdf>
"The SMP work was restarted at 2005"
"The first release of a stable runtime system with support for SMP came in OTP R11B in May 2006."
The Duo launched in July the same year. Pentium D was released in May 2005, as was Athlon 64 X2.
Multi-socket machines predate these processors by at least ten years. Windows NT 4.0 (first released in 1996) had multiprocessor support, as did Linux 2.0 (also released in 1996).
If you don't want to bother verifying this information, gut-check it. Ask yourself: "Why on earth would the Masters work on adding SMP to Erlang have started in 1997 if there weren't already working computers that could have benefited from SMP? And would it have made any sense to do this work if those sorts of computers hadn't already been around for a while?"
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?
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.
... if they can nail the OTA updates and hot-loading of code!
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.
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.
They kept using Java for some things, of course.
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.
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.
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.
Or I just do it in Rust, where even a shitty version I hack up in a day or two will almost certainly be more than fast enough.
This isn't to shit on Erlang at all. Erlang is great, and for the most part it is generally pretty fast for most stuff I want to do (generally more network-heavy stuff), and I'm not really going to complain about it not being able to do something it wasn't designed to do.
Though upon typing this, I am wondering if I could get NIFs working with GraalVM so I could do it in Clojure....