[zzzcpan]

> Writing asynchronous code is error-prone; Asynchronous code obscures the meaning of what we're trying to achieve; Programmers are bad at reasoning about asynchronous code

This is simply incorrect. There is a lot of FUD about this, but it doesn't make a smallest difference for a code with essential complexity of a typical CRUD app. But once you need to deal even with slightly more essential complexity, like managing a pool of connections, cancelling them, reconnecting, asynchronous code comes to the rescue, with all the callbacks and higher-order functions. Synchronous looking code cannot help with asynchronous problems, no matter how hard you try. It can only introduce additional accidental complexity. It's better to have and get used to a solid asynchronous foundation to begin with.

[ppcsf]

I'm not sure that "the areas of the complexity spectrum where the problems are too simple for async/await" overlaps with "the areas of the complexity spectrum that async/await can't handle", but I agree that there's an issue there. Async/ await is definitely an incomplete solution, and Haxl attempts to address one area where the abstraction fails. Of course, there are always places where you can do better dealing with the asynchronous/ concurrent primitives, but just like there's a place for both manual memory management and garbage collection, I think there are use cases where these abstractions can provide real value.