The problem with all the other solutions is that they end up being language-specific. That article you've linked to lists the various languages that chose that route: Go, Lua, Ruby. Now try invoking a Lua coroutine from Go, and have it interop properly with goroutines while running.

The nice thing about async/await is that it's just a wrapper around futures, which are themselves a composable wrapper around callbacks (semantically; the implementation can be more efficient, of course). So any language that can express function callbacks as first-class values can represent a future, and any language that can represent a future can interop with the async/await world. Which is why you can have JS code doing await on C# code doing await on C++ code in a Win10 UWP application, and it all works. And you can take existing libraries and frameworks that use explicit callbacks (often written in C), and wrap that into futures such that it's all usable with await.

That is a good post and a valid criticism.

I'd say the more important concern with c# is to be careful you're not accidentally calling a "really blocking" function from an async method, or you will lose scalability. The lesser issue is the mundane task of changing all your function signatures in the chain to async.

I too would use Go if it didn't regress in every single area for me, other than concurrency, and make me sad.

> In C# if you're not careful your codebase gets littered with tasks everywhere, even in code that has nothing to do with concurrency originally.

This is a spot-on. The only language I know that did this all right is Haskell, where most of your code doesn't need any thinking of async operations (either runtime gets you covered, or function takes a callback as a parameter, instead of any await magic), and when you need them -- you have `async` library that gets all you need.