> Blocking an OS thread as a mean to be compatible is not exactly what we're trying to do here. It's what Go does whenever you call into a C function or make a

> Blocking an OS thread as a mean to be compatible is not exactly what we're trying to do here. It's what Go does whenever you call into a C function or make a system-call. As long as those blocking functions are not the bottleneck then it works fine. My problem with the "colored function" analogy is that it implies that the problem is somehow due to the surface syntax, when in reality the problem still exists in all languages that support procedural IO: some of those languages like to just pretend that the problem doesn't exist. The only language I'm aware of which truly solves that is Haskell, since all IO happens via a monad. > Yes, that's not the absolute performance possible. But why care about that? This point was not about performance. It's about the pitfalls of writing all of your code on top of a complex and buggy runtime. Programming is a lot simpler, and development is a lot faster, when I don't have to worry about that. There are also several things that are a lot more complicated when you bake a complex runtime into the language like Go does. Thread-local storage is completely broken for one. If you do any kind of GUI programming, you may need to use `runtime.LockOSThread` as most GUIs expect function calls from a single thread. etc. etc.