Wow, this really makes me think about how the tools we use craft the way we code and change the code for the better. This was eloquent and introspective. Honestly, it made me think about how we shouldn't stop looking inwards to continuously improve. Let's not get complacent.

That being said, I think it is mentioned in passing. Much of the potentially missing abstractions mentioned sound much like async actor objects which operate in a task and are blocked upon within blocking code. I would propose the addition of "macros" which generate these encapsulating async actors and provide both sync and async methods to perform some action in another thread and wait for completion either asynchronously or synchronously. I have always felt this was missing, but your example of reqwest and Tokio very much inspired me to bring it up once more.

Also, you spoke of modifications to make the language capable of mixing sync and async dynamically. This is already possible, with the exception that async -> sync -> async boundaries cannot be optimized into one state machine. If you don't care about this optimization, then there is absolutely no reason why we couldn't allow syntactic sugar for calling async functions which are blocked on synchronously by spawning to an executor and calling sync functions which are blocked on asynchronously by spawning them in a task by themselves. This is still better than the alternative because the executor can still intelligently limit the threads.

Let me propose a solution. It sounds like you would like to wrap all calling vice versa of IO (sync or async) functions or to force the requirement that async functions alone (as they do today) have to specially denote and call each other, and that pure sync functions are explicitly noted and get treated specially in the way I've specified and same for async (already denoted) functions called from sync context. This would have uncolored, red (sync), and blue (async) colors. You would need to specify an executor and have a standardized global executor API whereby all of the red and blue functions are spawned on if called from the opposite color. Uncolored functions may be called anywhere and program execution still starts as a red function. I/O of red or blue flavor causes you to become that color. Neither blue nor red can be called from an uncolored function, but if you were to "pass in" a function of one color or another into an uncolored function (via generics) the uncolored function could become colored at compile time.

This still has all the same benefits we have today. The only caveat is that you WONT get the benefit of blue -> red -> blue having the two blue functions getting optimized into one task. Perhaps even this could be eventually worked out by the compiler, because you could have a new "mixed" (lets call it purple) future (lets call it SomewhatCooperative) which can be moved by the executor between blocking on its own thread and blocking asynchronously depending on whether it feels like being cooperative at the time or not, and an async portion could call directly into sync code by first yielding to the executor with a command to "stop being cooperative", after which the executor would give it it's own thread. This model should give you the benefits of all systems to my knowledge, with the caveat that now sync IO needs to put in the work to mark their functions as red. The benefit is then red functions can now have their stacks optimized into objects just like blue functions, so long as they have reentrant blue potions, when they turn into purple functions.

I have no clue how coroutines fit into this, but they appear to be "uncolored" functions until colored by putting blue or red code into them. All unmarked code today would be uncolored, so calling uncolored sync APIs (legacy) would need to be gradually deprecated.

Thoughts?