6 days ago
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 :)
7 days ago
Really incredible to see the proliferation of micro-VM tools lately. Here's one from just yesterday: https://news.ycombinator.com/item?id=44135977
7 days ago
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.
7 days ago
Does this target smaller devices than nerves? Or just an alternative?
7 days ago
Smaller devices.
7 days ago
There's also https://www.grisp.org which looks quite similar if a bit more mature
7 days ago
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.
6 days ago
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
7 days ago
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?
7 days ago
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!
7 days ago
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.
7 days ago
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?
6 days ago
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.
7 days ago
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.
7 days ago
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.
6 days ago
At the end of the day many IOT devices are just providing or receiving messages.
Lights, fridges, washing machines.
7 days ago
Uniformity of language between back and front-end, and communication layers?
7 days ago
Because the apps on my phone need to be written in the same language as the network devices my carrier runs? What?
7 days ago
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.
6 days ago
> 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.
6 days ago
> usually different teams
Is this a reason to use a different language? Or sometimes an effect if doing so?
6 days ago
It's not a reason to use a different language, but if you let each team choose an effective language for their work, they may well choose different languages.
6 days ago
That's simply not true. The best language for a front end is the language that's preferred by the platform. Firefox famously rewrote their UI with Java on Firefox because the XUL version was miserable. You don't build iOS apps with Java. You don't build Android apps with Go.
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.
6 days ago
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.
6 days ago
Why though? Why would you want your UI code in Python, as an example? Python has nothing in its standard library to help make websites. Tools like PyScript might give you the DOM, but suddenly you'll be using shims for all the other stuff you need, like resize handlers or fetch() or Intl.NumberFormat or anything else you care about.
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.
6 days ago
The compiler and the binaries it produces run fine on Android and Linux phones.
7 days ago
> … bit odd that mobile development options are lacking
what do you mean by that? can you please elaborate ? thanks !
7 days ago
I mean tools to run Erlang apps on iOS and Android, for example.
7 days ago
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.
7 days ago
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.
6 days ago
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.
7 days ago
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.
6 days ago
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
6 days ago
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.
6 days ago
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.)
6 days ago
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?
5 days ago
> 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.
4 days ago
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.
4 days ago
> 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>
4 days ago
"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.
3 hours ago
> 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?"
6 days ago
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.
6 days ago
Smalltalk had nothing to do with actors. It was largely a single core system.
2 days ago
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.
6 days ago
I don’t know about small talk but a single core system is orthogonal to a highly concurrent system which actors represent.
6 days ago
Doesn’t change the fact that Smalltalk wasn’t actor-based nor highly concurrent, which is what we are talking about here.
5 days ago
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.
6 days ago
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?
5 days ago
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).
6 days ago
It was originally built for phone switching hardware.
7 days ago
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!
6 days ago
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.
6 days ago
Any chance of a port to the Raspberry Pi Pico 2? It has 520K of ram iirc. The original Pico had half that.
7 days ago
Why did people reinvent the wheel with JVM while there's already Erlang VM ? Java did poisionate so much generations of people.
7 days ago
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.
6 days ago
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.
6 days ago
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.
6 days ago
Yeah, I considered a lot of that, and I haven't completely ruled it out, but I'm kind of setting a few artificial deadlines for this just to make sure I actually make a little progress. I am nearly 100% sure that if I hacked at this long enough (e.g. increased inlining, get rid of an extra loops, maybe abuse concurrency a bit more), it could go considerably faster, and maybe it would be fast enough to do what I need.
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....
5 days ago
Unless you are encoding very, very small snippets of audio, you are almost certainly better off writing your encoding in a best-of-breed language and shelling out to that program. NIFs aren't for "things that Erlang is slow at", it's for "things that Erlang is slow at that you need in the same process". You don't need your audio encoding to be in the same process, and you really don't want to try to write audio encoding to the restrictions of NIFs.
4 days ago
I ended up having some trouble getting the NIF stuff working so I ended up using ports with Rust. The amount of overhead for something like that is basically nothing, and you are right, I do not need this to be in-process.
6 days ago
Erlang was proprietary and under the radar until 1998. The Erlang VM has a different focus than JVM.
7 days ago
JVM predates BEAM.
6 days ago
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.
6 days ago
> 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.
6 days ago
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.
6 days ago
Bytecode based runtimes and compiler toolchains predate both, and Erlang came to life in 1986, a couple of years until Oak.
6 days ago
[dead]