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.
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?
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.
[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.
> 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 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.
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.
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).
Would love to hear everyone's thoughts on stablecoins vs fiat money movement! I've spent a few years in payments engineering, but would also love to hear other peoples perspectives
Hey everyone, I'm Svapnil, the creator of iso20022.js.
iso20022.js allows any developer to programatically move bank transfers with a business bank account by making ISO20022, the underlying messaging standard for money movement easier to use.
It's amazing how any developer can now move payments instantly using bank rails. I'd love for you all to take a look and let me know what you think.
Hey HN! A few months ago I built an app that allows you to trade memecoins on Discord. I'm recently open-sourcing it and releasing it to the public so everyone can see how to build Solana apps!
ISO20022 has a huge namespace and can do all kinds of things. My current focus on making transaction banking namespaces more accessible (think pain.001 002 and 008) aswell as CAMT files
Great effort, thanks! I just recently had to implement camt054 for our client and others will follow, because it's becoming the new standard soon. There's definitely a whole lot more in that namespace, yes.
I accidently also stumbled across the different einvoicing types that exist. What a space to explore :)
Source: former Erlang engineer