For me the real selling point of Haskell is that it's vastly more powerful and ergonomic for solving certain kinds of problems, in ways other functional languages don't necessarily share. First-class currying, typeclasses, HKTs, do-notation and other features in that vein give Haskell code a level of effortless composability whose equal I haven't seen anywhere else, and the way pattern matching is built into every part of the language makes other languages' versions of it feel clumsy and primitive.

Back when I was fluent in it, I wouldn't reach for Haskell for functional purity or lazy evaluation---I'd reach for it because I wanted the richness and flexibility of its type system and pattern matching for building and manipulating a tricky data model, or because I was doing something involving tree-like linked structures and/or that lent itself well to recursion. Parsers are the obvious example, but they are a very narrow view of what Haskell excels at.

(In short, I'd reach for it for reasons that are basically impossible to explain to somebody who doesn't already know what I'm talking about.)

I can't be so effusive about Rust. It's a really great language with a thoughtful and restrained design, powerful and practical and flexible, but I would actually say the opposite re: filling gaps: Rust feels like more of an iterative improvement in the space occupied by C/C++/Go/etc., while Haskell is transcendently good for those classes of problem where it excels.

---

Today I'm more or less fluent in Rust after a few hours' warm-up, but it would take me days or weeks to warm up my Haskell. Why? Mostly because I've largely stopped programming for fun, and I use nothing like Haskell at work. Throw in the quality of Rust's tooling and the largely effortless reproducibility of its builds (great for warming up a 6+ month old project), and it's just a far more practical choice for the little hobby programming I do. Hence my earlier comment. But I still contend that Haskell has vast untapped potential, locked away behind an intractable adoption barrier. It's less that it has nothing new or useful to offer us, and more that we are unwilling to pay the price of admission.

> Being purely functional seems like a massive win until you realize most of the real world benefit of that expresses itself as testability/correctness which can be obtained by other means.

Is the end result reached by other means the same? Can you give an example of a competing approach in a non-pure language that gives one Haskell's advantages?

I don't think the result is the same but it is comparable. I would say using any language with a reasonable type system, say Kotlin w/property based testing gets you a result that while not as good as Haskell w/quickcheck is "good enough" for practical use in production software.

There is maybe some niches where that wouldn't be the case like very high assurance software where instead of Haskell you might choose say ADA instead but I'm not really familiar with those domains.

I actually think the construction method of and composition that aids code re-use very applicable to regular-degular workaday programming.

Kotlin plus property testing gets you very far and the industry defaulting to that would be a huge improvement.

I'll have to rewrite one of my Haskell projects in Kotlin and see if I feel anything is missing.

That would be a pretty interesting experiment!