conduit

There are companies like IOHK or Mercury that hired large swathes (50?) of Haskell programmers in relatively short time, so I don't think bus factor of the programmer market is an issue. Of course it's still an issue if a company hires 1 or 2 Haskell devs only, and those depart. > from the past three years [..] the latest I’ve seen were Opus-4.6 and GPT-5.5 struggle a lot with standard GHC Haskell If your experience is from years ago, I totally get that. For my standards, LLMs were pretty bad before 2026. I haven't tried any serious LLM Haskell before 2026-02, because it was just not a timesaver. I had good experiences with Opus-4.6 already on Haskell, such as it having detail knowledge on async exceptions, allowing it to immediately pinpoint difficult bugs that me and other experts missed, e.g. https://github.com/snoyberg/conduit/pull/53

> >> is an old name for > I once had a hard to track down bug in some code making use of conduit[0], which is introduced using examples like `main = runConduit $ (yield 1 >> yield 2) .| mapM_C print`. Dutifully replacing every occurrence of (>>) with (>), because it was more modern, suddenly changed the semantics somewhere, due to the fact that (>>) is defined with fixity `infixl 1 >>` and (>) as `infixl 4 >` - i.e. both are left-associated operators, but (*>) binds tighter than (>>) and some of the myriad of other operators you may encounter. -- [0] - https://github.com/snoyberg/conduit

Working through Learn You A Haskell is a good start. After that, I honestly think you'll get the best bang-for-buck by reading library-specific tutorials. If you play with enough of the libraries the rest of the language more or less falls into place. Conduit is a pretty ok streaming library, and has good documentation: https://github.com/snoyberg/conduit#readme Lens gives you a lot of useful features that more or less correspond to stuff like Getters and Setters in something like Java, and the tutorials for it get into some helpful details about writing Haskell code: https://hackage.haskell.org/package/lens Otherwise it's basically a lot of "just build shit, and don't be afraid to feel confused" and it'll fall into place.

> makes me think that there aren't any conduits that have more data than can fit in memory on a single machine Just because you can dedup a conduit doesn't mean you have to. We use conduits for streaming gigabytes-large files while staying within megabytes of memory use – ensuring that is one of the main selling points of libraries like conduit: https://github.com/snoyberg/conduit#readme

OP is somewhat conflating two different things: non-strict function evaluation and lazy IO. With lazy IO, you can get, for example, a String from a file. That string is actually a lazily-constructed chain of Cons cells, so if you're into following linked lists and processing files one char at a time, then it's fun to use. The dangerous bit comes in when you close the file after evaluating its contents as a string: fd <- open "/some/path" s <- readContentsLazy fd close fd pure $ processString s Now, processString is getting a string with the file's contents, right? Nope, you have a cons cell that probably contains the first character of the file, and maybe even a few more up to the first page that got read from disk, but eventually as you're processing that string, you'll hit a point where your pure string processing actua

Reminds me of a stream-processing library that Michael Snoyman recently started working on: https://github.com/snoyberg/zerem For background, he authored Conduit, one of the most popular Haskell stream-processing libraries: https://github.com/snoyberg/conduit

I immediately thought of https://github.com/snoyberg/conduit

Working with streams of data often makes pointfree syntax beneficial, since you can start to see the omitted arguments "flow" through your chain of composed functions. If you write f # g = \x -> g (f x) then you could implement functions like this: f :: Stream Int -> Stream Int f = drop 3 -- drop the first three elements # skipEvery 3 -- skip every third element # sumEvery 2 -- sum every consecutive pair of elements # map (* 2) -- double everything This would turn 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ... into 2 * (4 + 5), 2 * (7 + 8), 2 * (10 + 11), ... You can find many non-pointfree versions of similar streaming code here: https://github.com/snoyberg/conduit/