This is interesting and makes sense. It's worth mentioning that the original use of structured concurrency (by Sustrik) was really about dealing with the proble

This is interesting and makes sense. It's worth mentioning that the original use of structured concurrency (by Sustrik) was really about dealing with the problem of cancellation-friendly virtual threads: https://250bpm.com/blog:71/ https://250bpm.com/blog:71/ > I don't think yielding needs to be visible to the user in any meaningful way; why does it need to be? It's an interesting question. Users definitely want coroutines they can yield themselves - this is was iteration is all about, for example, and there are other similar patterns (the entry API is ultimately a kind of coroutine). At the same time, the highest performance low level interfaces for asynchronous IO are ultimately just asynchronous iterators & asynchronous sinks over shared memory ring buffers, io-uring is the most famous example but there are others like AF_XDP. I think you're right that a kind of cancellable virtual thread ultimately would have analogous affordances to a future. But a future is just a specific class of coroutine (that yields a unit type), so if you will have the coroutine mechanism for the rest of the system, why would you not extend it to include IO instead of adding a separate mechanism to erase the fact that IO is happening? What you also get from this is that if a function yields the bottom type you know it doesn't perform IO.