streamly VS haxl

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

For some reason everyone wants to talk about Monads, but really the other types here are just as interesting. For example, Applicatives are less dynamic than Monads in that you can't `flatMap`/`bind` to decide on the "next" thing to evaluate based on the previous value, but in exchange you get a "static" tree (or graph) of Applicatives that lends itself much better to static analysis, optimization, parallelism, and so on.

For example, Haxl (https://github.com/facebook/Haxl) uses this to optimize and parallelise remote data fetching, which is hard to do with Monads since those are inherently sequential due to the nature of `flatMap`/`bind`. My own Mill build tool (https://mill-build.org/) uses an applicative structure for your build so we can materialize the entire build graph up front and choose how to parallelize it, query it, or otherwise manipulate it before we actually start evaluating the individual steps

Monads seem to have this strange aura around them that attracts certain kinds of personalities, but really they're just one abstraction in a whole toolkit of useful abstractions, and there are many cases where Applicative or some other construct are much more suited

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