
Show HN: HaxlSharp – Concurrent data fetching and request deduplication in C# - ppcsf
https://github.com/joashc/HaxlSharp
======
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.

------
bbcbasic
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.

------
NKCSS
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!

~~~
ppcsf
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".

