Our observation is that Erlang's "soft-realtime" is already getting much harder once Linux stays out of the way. We have a master thesis worth of research on having multiple sets of schedulers in one Erlang VM that run on different hard real-time priorities plus research on a network of message passing and garbage collecting Erlang processes can be doing Earlies Deadline First scheduling.
However that stayed prototypical because we found relativeness of vanilla Erlang on RTEMS was good enough for all practical customer problems we solved.
For very high performance hard real-time we drop down to C and we are currently working on a little language that can be programmed from the Erlang level that avoids that.
--
thanks !
[1] https://www.st.com/resource/en/datasheet/stm32u5f7vj.pdf
That requires certain choices for CPU, RAM.
We also have a lot of energy management hardware on the board: All PMODs can completely switched off. There is a separate wakeup logic that triggers when the capacitor that gets charged by the harvester has reached a certain charge level and many more.
The challenge with using Erlang for systems like that is that it has a boot phase which it needs to get through until we can manage energy from the Erlang level. So we either need to have enough charge to get through the whole boot or we need to manage the boot process to and do it in chunks then sleep again.
That's what we want to find out with this hardware but first we needed to squeeze in Erlang VM, RTEMS, TCP Stack and all of the Erlang objects to be useful (first goal was reach the shell). That's where we are right now.
I love people who can stay excited and optimistic about stuff; it's so easy to be cynical, it's refreshing to meet someone who hasn't had the life sucked out of them.
I need to pick up a GRiSP Nano one of these days. I have the GRiSP 1 and even managed to get Lisp Flavoured Erlang working on there [1], but I haven't played with it much since then. I should fix that.
[1] https://medium.com/@tombert/working-with-lisp-flavoured-erla...
How true that is
Makes me curious at what pace and why the size has grown from 1986-2025 and how long ago the line was crossed that made 16 MB seem like a that is now a small runtime?
I want to believe we'd someday see erlang/elixir all over the place, especially in flight software, due to their use of "lightweight processes" and high fault tolerance, but I don't see it happening any time soon, and I certainly don't see people hiring for it. I think it could solve some legitimate industry issues but it's too big of a change for too subtle of benefits
