4 ms·

I keep hearing this term "requires a runtime" when async execution is thrown around. And on first glance it makes sense. On deeper look, technically all languag

by slver 5y ago

I keep hearing this term "requires a runtime" when async execution is thrown around. And on first glance it makes sense. On deeper look, technically all languages have SOME runtime behavior. And I don't know why we're so objected to it. Presumably it can get weird when you call into a library and just blocks you. Thus informing us of the need of a common event loop. OS level. Which GUIs had from the get go, but apparently it's not just about GUI.

xh-dude 5y ago
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.

by slver 5y ago

xh-dude 5y ago

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.