I lost confidence in Haskell's ability to let me write something one way and safely refactor it later, when I found out that you can't use a ton of the algorithmic functions in the standard library because they do things all wrong.
A big one is lazy I/O[1]. It is really easy to mess up the order that operations happen in when using IO operations from Haskell's standard library. The non-standard library alternatives like conduits or pipes are more complex, but much harder to mess up.
I agree lazy file I/O can be dangerous and needs to vanish, but I'm not sure this counts as an "algorithmic" complaint, which is what I was really curious about.
I also don't think you need Conduit or Pipes or any other performance destroying free Monad libraries to deal with it. My hot take: Conduit is in fact awful and radically overused and multiple superior options exist.
I totally agree the prelude is full of cruft and needs to be scraped and redone fully. But the data structures libraries are all really good and if we could just pull in the succinct and unordered stuff, it's gone some of the best data structures a standard library can ask for.
I'm not the commenter you're replying to, but I've often found the Haskell numeric classes (Num, Fractional, Integral etc) prickly. The almost, but don't quite, map to (mathematical) algebraic structures.
Having use Haskell for math programming, I agree with this sentiment. Haskell's standard classes are in an uncanny valley of matching the mathametical structures.
If you want to do that sort of thing with Haskell, I would suggest switching to the numeric prelude [0]
That sounds like the classic category of "I hate Haskell because in any other language* I know it's impossible to write a correct program so I don't care about being wrong, but Haskell tempts me into thinking it's possible to get it right."
Not counting obscure special-purpose langs like Coq.
