[Phil_Latio]

No i meant cooperative green threads, not the stackless async/await model. My model would basically mean: No "function coloring", all functions can be called as usual. IO related functions will automatically yield, no problem. All CPU-bound work either need manual yield points (not good, I agree) or should be offloaded to a coroutine on a different thread and then awaited (yes with await keyword) cooperatively. If you want to invoke a click handler for an UI, you can launch a coroutine on the same thread (cooperative).

Go must do all sorts of trickery with the preemption. Like inserting yield points or even depend on signals so it can preempt a goroutine which didn't hit a yield point. It basically replicates what the OS does with threads.

[nromiun]

So basically like gevent. I agree that is a very good concurrency model. Much better than the current asyncio mess we have.

But if you already have a runtime I don't know why it would be big deal to make them N:M threads as well. Makes managing CPU bound tasks easy as well as IO bound tasks.

[Phil_Latio]

Well I see 2 cases for automatic preemption:

- You are lazy and just don't care, let the runtime do it - Or you failed to realize that what you do could block

The first case is what annoys me. I think the developer should handle obvious cases manually. While the second case would be considered a bug in my model and the language should help you with that as explained earlier. If that works out, I mean to rule out mistakes for the second case, then this model is superior and more performant I think.

[gpderetta]

You could make the same argument for GC, yet, outside of system languages, it is generally considered a net positive. The reality is that in a large application it not easy to find all the right preemption points.

[Phil_Latio]

I guess you are right. Maybe I see it too much from a system programming language perspective. After all, Go is of a different kind.