Traditionally, "coroutine" has been used to refer to a userspace concurrency unit that is not multiplexed and which requires explicit yielding. Mostly I'm grumpy about broadening a previously precise definition.

> So while one must restrict ourselves with the co-routine scheduler provided by the Go runtime and to the yield points managed by it, with generalized async/await it is possible to have control how the scheduling actually takes place among co-routines. Granted Go's model is easier to understand and might be enough for many people, but it isn't a solution for all types of concurrency problems.

Not having to control your own scheduling is the selling point of Go's concurrency model. Besides, Go does offer (at least some) control over scheduling via the runtime library. I've never had to use this in practice, and I can't imagine a scenario that would require nuanced control. I don't think async/await are the worst things, but I still prefer Go's runtime at least for the problems I have to solve.