> The whole point of async/await is to allow for not blocking the caller though until it's ready for an explicit synchronization point.

That is an end not a mean.

Again in my experience the vast majority of devs could not give less of a shit about “not blocking the caller” by default. What most devs want is a reasonably cheap way to get a high amount of concurrency.

If anything not blocking the caller by default is generally an error, because somebody forgot an await.

> If you are blocking the caller you have not "solved" the colored function "problem".

Of course you have: you have solved the actual problem that needs solving without using function colouring. That’s how e.g. Go works. Go has problems up the ass but it doesn’t have that one at least.

Java is also moving back to Userland threads rather than towards async/await.

And it looks pretty much exactly like using threads, which is why they are working so hard on structured concurrency.

Go has NOT solved the problem in a fungible way, as evidence by all the dual APIs; methods that return a channel, and those that don't.

CSP is great at modeling data flow, but IMHO it's lesser than async/await imperative programing for modeling more standard business logic flows.

You can build promises with fibers too if you just want to use the value you'd "await" on later on in execution, it's trivial.