> 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.
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.
This style of programming reminds me of SQL where you specify intent and let a query optimiser work out the execution plan. I like it. Not sure this is production ready but it'd be fun to try at work.
When reading, I thought: do I really need a framework for this? I've written simular batching before in c# but for the more elaborate cases, it makes sense and the de-duplication and only retrieving once to ensure all instances are the same looks nice; well done!
Yeah, it's certainly preferable to use Task.WhenAll or Promise.all in simple cases.
For more complex cases, I like to make the analogy with asynchronous code. There's a few problems with complex async code that only uses a minimal abstraction, like callbacks:
* Writing asynchronous code is error-prone
* Asynchronous code obscures our intent
* Programmers are bad at reasoning about asynchronous code
So we developed abstractions like async/await and promises, allowing us to write async code in a sequential-looking way. Unfortunately, introducing concurrency into the mix breaks this sequential abstraction, which means certain familiar problems emerge:
* Writing concurrent code is error-prone
* Concurrent code obscures our intent
* Programmers are bad at reasoning about concurrent code
Haxl attempts to reclaim this sequential abstraction, allowing us to write code that looks sequential, but is actually concurrent "behind the scenes".
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.