haxl VS streamly

Sounds a bit like Haxl. From this page:

+1. The JS event loop auto-monad-izing Promises into Haxl [1]-esqe trees of implicitly-batched loads has been a big win for us building on JavaScript/TypeScript.

If I had to move to another language, I'd really want to find a "powered by the event loop / dataloader" framework, i.e. Vert.x for Java.

Also, per dataloader, a shameless plug for our ORM that has dataloader de-N+1-ing built natively into all object graph traversals:

https://joist-orm.io/docs/goals/avoiding-n-plus-1s

[1]: https://github.com/facebook/Haxl

and Haxl

Haxl, a framework for efficient and concise data fetching.

You mean, Haxl? [1] But AFAIK only a few devs are involved for the development.

[1] https://github.com/facebook/Haxl

Probably, the most googled and well-known example of Haskell application in major companies is the Facebook Meta spam filters. Messages containing spam, links to potential malware and phishing attacks are filtered by Sigma, the system that was rewritten in Haskell in 2015. The choice of language was based, among other things, on performance requirements, the need for pure functions and static typing, as well as the possibility of interactive development. The Haxl framework is used under the bonnet, which the company has open-sourced. You can find more details about the development process and technical aspects in the company’s blog post.

Their GitHub still seems pretty active https://github.com/facebook/Haxl

Since you mention Any real-world application uses a database or seventeen in the backend, it's probably worth checking out https://github.com/facebook/Haxl as its goal is to allow you to write high-level queries in Haskell and have the library call out to different datasources as efficiently as possible.

https://github.com/composewell/streamly/issues/1307 seems related, but it was a long time ago. We weren't heavy users anyway, so our streaming philosophy is now "conduit if it's simple and plugging into a conduit-using library, streaming if you're doing complicated things".

Interesting! Which of the streamly modules is implementing that part? Is it one of the workLoop implementations in Streamly.Internal.Data.Stream.Async?

I want to like streamly, but the API is so huge, yet I feel like I'm doing things on a too low level of abstraction. (And as long as it needs a ghc plugin I doubt it'll become the de facto standard.) Though maybe I just haven't used it enough. It does have great docs at https://streamly.composewell.com/ and they seem to be taking both performance, dependency weight and API design quite seriously.

You missed streamly in your list of alternatives: https://github.com/composewell/streamly/blob/master/docs/streamly-vs-async.md