Is this something you have experience with, or are you just theorizing? I know there are pitfalls to Haskell development, but to assert that "the common case" has uncompetitive performance seems wrong to me.
My problem with this kind of assertions is that often -- not saying it's your case, that's why I'm asking -- they come from people who imagine how it must be (or read it in a blog), often coming from a place of never really having tried to solve something with the language, and this sadly percolates into popular wisdom ("Haskell is not good for this or that"). Something similar happened to Java's allegedly "poor" performance, way past the point Java software sometimes outperformed C in many areas.
Haskell can do some pretty tricks with specific code if you tickle it right, but if you just write general, normal code, it's faster than Python (a low bar, Python qua Python is nearly the slowest language in anything like common use) but not a generally "fast" language. "Someday" is here; if it's not "generally C-fast" today, I see no particular reason to believe it will be in the future either, especially since GHC seems to have spent a great deal of its design budget.
It would be interesting to see someone's take on Haskell, but where they write the language from the very beginning to be a high-performance language. There's probably multiple points in this design space that would be possible. Arguably Rust is nearly one of them, and getting even closer in the next few years.
It’s still under development but intended to be a high performance functional language.
The author has substantial experience in JITs and compilers.
Optimizing Haskell code is a huge downer. The experience of having to throw away beautiful code and rewrite it in C++ or non-idiomatic Haskell purely for performance reasons is extremely disheartening. I don’t recommend it.
I don't dispute this. My problem is that people will use this as a reason dismiss Haskell, and then use Python.
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.
And idiomatic Haskell's performance is plenty acceptable for a variety of common use-cases (so not "nearly always is")
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.)
But I honestly don't think performance is the reason majority of the developers shy away from Haskell. Most often you achieve relatively good performance without giving it any thought. At least compared to its peers, I mean other high level languages you'd use to solve the same problem.
Haskell programming ethos is opposed to that, the language wants people to focus on the semantics of computation not the method. Yet we must be able to specify computation method if we want our programs to operate efficiently.
The truth is that the Haskell compiler will never be able to automatically translate idiomatic Haskell code into something that’s competitive with C in the common case. once you start finagling your haskell code to compete with C you’ve negated the point of using Haskell to begin with.