[whateveracct]

Haskell actually does a great job when you do need to drop to C (or lower-level Haskell) for performance. It has a great FFI, a bunch of modules around low-level programming (raw ptrs w/arithmetic even), and things like the ST trick and (soon) LinearTypes to help you build interfaces that guarantee your impurity doesn't leak when called by pure code.

Haskell code tends to be pretty fast as-is, and tbh I don't see the problem with having to think about performance when you're writing performance sensitive code. When you do need to hand-optimize, Haskell does not get in your way or make it impossible.

Also, many extremely complex Haskell abstractions can be optimized away completely by GHC! Generics, lenses, and the state monad come to mind.

[coolplants]

IMO I’d rather just write idiomatic C++ then non-idiomatic ghc-specific Haskell code if performance is important, and it nearly always is.

[whateveracct]

The thing is, like 20% of your program ends up being non-idiomatic, ghc-specific Haskell. I suppose for certain applications it could end up being the whole thing, but in general I'm thinking optimized Haskell is in that ballpark tops.

And idiomatic Haskell's performance is plenty acceptable for a variety of common use-cases (so not "nearly always is")

[coolplants]

In my experience that has not been the case. Either unacceptably slow computation or High memory usage.

[whateveracct]

I mean, what use-case was this?

I've deployed plenty of web services & data processing jobs in Haskell and the RTS has never been a bottleneck or issue. So I'm guessing you weren't doing an IO-bound activity (where Haskell is quite good.)