i wonder how Erlang on a microcontroller would feel like
-
@whitequark yeah I'm unsure how much the OTP binary it generates needs the linux bits, in theory it should be portable since its compiling the beam runtime into the binary but i dunno
@whitequark portable in the sense of being able to compile for other platforms, not in the sense of having the binary be droppable into other systems
-
i wonder how Erlang on a microcontroller would feel like
@whitequark there is AtomVM. I haven't tried it but it fits in moderately sized mcus it seems. https://atomvm.org
-
@whitequark there is AtomVM. I haven't tried it but it fits in moderately sized mcus it seems. https://atomvm.org
@cararemixed oh nice
-
i wonder how Erlang on a microcontroller would feel like
@whitequark implementing BEAM on a stm32h7 class micro seems pretty feasible!
I wish more projects would take the approach of high level runtime for app code on microcontrollers, like sifteo https://scanlime.org/2012/12/how-we-built-a-super-nintendo-out-of-a-wireless-keyboard/
-
i wonder how Erlang on a microcontroller would feel like
I imagine: great, right up until it suddenly isn't. Erlang has asynchronous message passing, which means that it must have message buffering. And that means that memory can easily accidentally balloon at unexpected times.
-
I imagine: great, right up until it suddenly isn't. Erlang has asynchronous message passing, which means that it must have message buffering. And that means that memory can easily accidentally balloon at unexpected times.
@david_chisnall only with unbounded queues
-
@david_chisnall only with unbounded queues
Erlang queues are unbounded.
-
R relay@relay.infosec.exchange shared this topic
-
Erlang queues are unbounded.
@david_chisnall right, but if you were working on an MCU dialect (and it would almost certainly have to be a dialect) you could change that
-
@david_chisnall right, but if you were working on an MCU dialect (and it would almost certainly have to be a dialect) you could change that
Doing so would fundamentally change the Erlang abstract machine in ways that would impact the rest of the system. In particular, Erlang has a notion of selective receive as a core part of the language (which is necessary for things like two-phase locking, which can't be expressed natively in the actor model without it).
Selective receive means that waking up an actor that has a full message queue will not automatically result in its message queue shrinking in size.
-
Doing so would fundamentally change the Erlang abstract machine in ways that would impact the rest of the system. In particular, Erlang has a notion of selective receive as a core part of the language (which is necessary for things like two-phase locking, which can't be expressed natively in the actor model without it).
Selective receive means that waking up an actor that has a full message queue will not automatically result in its message queue shrinking in size.
@david_chisnall @whitequark that makes sense. At that point, when some core quality is lost, changing how the system works and can be used, a subtle line is crossed between Erlang variants and Erlang-inspired languages.
I think in a way that encourages us to ask useful questions like what properties of Erlang are you interested in? what are your other inspirations? what requirements do you have? what are the implications of combining those things in this way?
(though obviously you don't have to have answers or be interested in them. I just think it gives useful structure to the inquiry)
-
Doing so would fundamentally change the Erlang abstract machine in ways that would impact the rest of the system. In particular, Erlang has a notion of selective receive as a core part of the language (which is necessary for things like two-phase locking, which can't be expressed natively in the actor model without it).
Selective receive means that waking up an actor that has a full message queue will not automatically result in its message queue shrinking in size.
Some background:
In Verona, we have a generalisation of the actor model, which makes things like two-phase commit easy but makes this problem worse: the equivalent of a message is 'sent' to multiple concurrent owners (generalised actors), so working out who to wake to reduce the total number of messages in the system is hard.
We looked at what a version for embedded devices would look like, but even the actor-model subset is basically impossible. Even simple actor model has things with fan-out, so waking up an actor because its queue is full may cause two more messages to be sent. And these may be in cycles.
And actor model (and BoC) don't provide good tools for reasoning about the worst-case numbers.
