I feel like I have some intuative understanding of how go achieves colorless concurrency using "go routines" that can park sync/blocking io on a thread "as needed" built into the runtime from the very begining.
I don't understand how Ruby added this after the fact, globally to ALL potential cpu/io blocking libraries/functions without somehow expressing `value = await coro`
Python is currently going through an "coloring" as the stdlib and 3rd-party libraries adapt to the explicit async/await syntax and it's honestly kind of PITA. Curious if there's any more info on how Ruby achived this.
> I don't understand how Ruby added this after the fact, globally to ALL potential cpu/io blocking libraries/functions without somehow expressing `value = await coro`
In Python gevent can monkeypatch the standard library to do that transparently (mostly). I assume it works the same way except better: have the runtime keep track of the current execution (mostly the stack and ip), when reaching a blocking point register a completion event agains the OS then tell the fiber scheduler to switch off, the fiber scheduler puts away all the running state (stack and instruction pointer) then restores an other one (hopefully one that's ready for execution) and resumes that.
Java has shown that a sufficiently strong runtime can take the burden onto itself long after the facts have been established.
Python in contrast has a runtime ultimately held back by its deep integration with the C-ecosystem which creates more black-boxes inside the runtime than you can find inside a swiss cheese.
Similar with C# and Rust. No strong runtime, no colorless functions for you.
I don't understand how Ruby added this after the fact, globally to ALL potential cpu/io blocking libraries/functions without somehow expressing `value = await coro`
Python is currently going through an "coloring" as the stdlib and 3rd-party libraries adapt to the explicit async/await syntax and it's honestly kind of PITA. Curious if there's any more info on how Ruby achived this.