3 ms·

Like, I see ‘common event loop’ here and don’t OSs (and hardware) past a certain size generally provide interrupt handling, threading, memory management and so

Like, I see ‘common event loop’ here and don’t OSs (and hardware) past a certain size generally provide interrupt handling, threading, memory management and so forth? These are all highly general mechanisms that have evolved to meet concurrent execution models… because of the generality, a lot of relevant things remain at a lower level of abstraction than languages often expose. What I wonder about is what happens when we lift runtime policy decisions into the type system, in a way that allows something more performant - I think I have a sense of what this pans out like and I just am skeptical than for every case (for many, many cases, it seems like a great idea!) that this approach leads to the best implementation. It reframes a lot of the inherent difficulties, I’m not sure it helps abstract over them.

slver 5y ago
Basically we need hardware that works a lot more closely with the OS, and an OS that works a lot more closely with modern language semantics. The problem with the general abstractions you call out (correctly) as inefficient, is that they're stuck in the 80s, and they gotta work with code that looks pretty much like compiled C binaries from the 80s. Green threads at the language level and so on is a stop-gap in the long-term. Everything has to align together, and then native thread switching will be just as (or almost as) light as green threads. To be a tad more specific, basically we need hardware+OS to provide us with a model that's pretty close to what the Erlang VM emulates.