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
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.
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.)
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?
> Multi-core support... was early requirements...
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.
Right, I should have been more clear, perhaps.
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.
> 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.
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 history of support for SMP (Symmetrical Multi Processor) in Erlang started around 1997-1998"
"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.
> 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?"
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.
Smalltalk had nothing to do with actors. It was largely a single core system.
Number of cores on a system has nothing to do with it. If you sat down and wrote a few thousand lines of code in both of these languages, the natural architecture presents itself the same way. Erlang has "nothing to do with" actors either. But this language is de facto the standard way to refer to this kind of message-centric architecture. The largest influencers of the actor model are simula and smalltalk. Denying the relationship is beyond absurdity.
I don’t know about small talk but a single core system is orthogonal to a highly concurrent system which actors represent.
Doesn’t change the fact that Smalltalk wasn’t actor-based nor highly concurrent, which is what we are talking about here.
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.
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?
The actor and supervisor system is really, really nice when you want reliability even with only one core (at least in theory, nothing against Atom but I would probably want a more battle-tested VM for shipping a production device).