i wonder how Erlang on a microcontroller would feel like

[whitequark@social.treehouse.systems]

you get the same kind of real-time and correctness benefits as Rust (with a lot of hand-waving involved in the use of "same kind" here) but the language is way simpler

[lisyarus@mastodon.gamedev.place]

@whitequark ...am I having a stroke or did you post exactly that some time ago?..

[whitequark@social.treehouse.systems]

@lisyarus dissociative amnesia

[castanea_jo@ni.hil.ist]

@whitequark Guessing you've already run into it but https://nerves-project.org/ is a thing, and pretty nice to work with by all accounts

[whitequark@social.treehouse.systems]

@castanea_jo first time i've seen it but also if it runs Linux it's in the same class as PCs in my book

[lisyarus@mastodon.gamedev.place]

@whitequark Must be it

[artemist@social.mildlyfunctional.gay]

@lisyarus @whitequark don't worry, whitequark posts are idempotent.

[ratsnakegames@mastodon.social]

@whitequark probably uncomfortable because the microcontroller's pins would poke his butt

[whitequark@social.treehouse.systems]

@artemist @lisyarus unironically

[lisyarus@mastodon.gamedev.place]

@whitequark @artemist Would be funny if they were involutions

[castanea_jo@ni.hil.ist]

@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

[castanea_jo@ni.hil.ist]

@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

[cararemixed@mastodon.social]

@whitequark there is AtomVM. I haven't tried it but it fits in moderately sized mcus it seems. https://atomvm.org

[whitequark@social.treehouse.systems]

@cararemixed oh nice

[eqe@aleph.land]

@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/

[david_chisnall@infosec.exchange]

@whitequark

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.

[whitequark@social.treehouse.systems]

@david_chisnall only with unbounded queues

[david_chisnall@infosec.exchange]

@whitequark

Erlang queues are unbounded.

[whitequark@social.treehouse.systems]

@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@infosec.exchange]

@whitequark

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.