> Can you maybe elaborate why this model is better than async/await?
Others have given actual explanations, but I'll chime in with a bit of a tongue-in-cheek one: it's better than async/await because it doesn't have async/await (yet has all the benefits provided by them).
I wish I understood this better. If you're writing code in the same style whether it's async or not, how can you manage return values and reason about flow?
The flow is sequential, as laid out in the code, the same as for any old-fashioned code. It has the same semantics as the non-async code. The only difference is that OS thread can be released to do some other work while you wait for IO operation to finish.
Others have given actual explanations, but I'll chime in with a bit of a tongue-in-cheek one: it's better than async/await because it doesn't have async/await (yet has all the benefits provided by them).