But with go's green threads, does it really matter if something blocks or not? Given, I'm not too familiar with Go, but in the case of Java's upcoming Loom which will do something similar, you would just create a virtual thread and if you have to do something with the output of a previous call, you just write plain easy "blocking" code. The JVM will switch to another virtual thread during the "blocking" part automagically and you are done. Whether something is async or not doesn't add anything to the idea you want to implement (in managed languages that is -- rust do need the async keyword because it is a low-level language).
There is a fine balance here, I believe. Java plans on introducing something called structured concurrency to tackle this problem, but even without it I don’t believe that this is a unidirectional tradeoff. Async programming even with syntactic sugar can be overwhelming easily as well.
