[lgas]

Not the person that you're responding to, but I write web applications in Haskell. Previously with Servant and these days mostly with scotty. Happy to try to answer any questions you have here, but there are great communities of helpful people on Reddit (r/haskell and r/haskellquestions) and the FP Slack as well. There's no need to go at it alone.

And you're right, Haskell is definitely worth it.

[_huayra_]

Not PP, but how often do you find yourself tracking down lazy-evaluation / GC-related performance issues?

I've heard some horror stories and I honestly don't have the mental model yet to track these things down. Even learning Rust, it still has the same "stack + heap + eager eval" sort of thing as C++.

I'm not sure how much of this is done in practice, or if the folks who've had it happen to them are just prolific at internet complaints.

[lgas]

Honestly, pretty much never, but the stuff I work on these days does not have significant performance or scalability requirements so usually I just write the most straightforward code possible and it's fast enough and doesn't leak.

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.

[antonvs]

I’ve done quite a few small to medium sized projects in Haskell, both personal and commercial, and worked on one larger system at an investment bank. It’s really easy to avoid those issues with modern Haskell, just following some rules of thumb (e.g. annotate all your datatype members with ! to make them strict) and avoiding some well known pitfalls.

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.