The only place I really ran into that was on a project that inherited a framework written by consultants and that was really due to problems with the framework and not the language. Though I do still cargo cult some practices from those days that may be helping me to avoid some pitfalls today without realizing it -- eg. almost every field of almost every run of the mill business-domain data structure I create is strict (eg `!Int` instead of just `Int`).

I imagine you're going to hear more of the horror stories on the internet than the successes, but that sort of thing can be legitimately frustrating when coming to Haskell from other languages just because a lot of what you know goes out the window and you have to learn new concepts from scratch while getting up to speed on a new language with a new tool chain, etc. At some point you make it over the hump and it largely becomes a non-issue.

I saw someone complaining about a memory leak the other day on reddit, and it boiled down to someone using annotations to control inlining and insisting that it ought to work. If you’re not flying close to the sun, you’re unlikely to have serious trouble.

I wrote a really nice system with Servant recently which does stream processing and serving of large files using the ‘streaming’ library (https://hackage.haskell.org/package/streaming). In its initial versions, my app wasn’t very snappy with large files, but I didn’t think much of it - it seemed acceptable. But while I was cleaning up the code I made a small change that improved its performance by an order of magnitude. I’d have to go check what it was now, but the gist of it was using these really high level abstractions in a suboptimal way. I don’t think that’s an issue with Haskell itself, so much as the tradeoffs involved in using powerful abstractions you don’t fully understand. I was super pleased with the end result though.