Yeah, Haskell won't give you Rust-like performance. Very few languages will and, except for C, you won't even see them here on the comments.

Haskell can have a reasonable high performance, but if it's you main concern, or if predictability is important, you need a low level language.

Right now I'm using Julia for high performance math heavy modelling with lots of experimentation, and it's great for this purpose. I can get most of C++'s advantages without giving up on flexibility. My code base wouldn't scale to team work / production software though as well as C++.

So let me get this straight: You don't like Haskell because someone used it to write an inefficient quicksort example online?

Not somebody, it was on the home page as a use case of how much better Haskell is than other languages.

The default libraries are extremely inefficient.

Generally if I use Python/Ruby I can get a 50x slow down that is accepted, but with Haskell it can be more, as it's very hard to think about what the compiler does (memory usage can blow up easily).

To be fair, that code is to illustrate the beauty of the language rather than efficiency.

(Also the fibonacci sequence using 'zip'. Blew my mind.)

Haskell folks are fairly upfront about possible performance issues. Lazy evaluation comes with its own set of tradeoffs.

You can write very inefficient code in C++ if your algorithm isn't efficient.

I still don’t see any tradeoffs explained, quite the opposite is on the home page:

,,The purity of Haskell code makes it easy to fuse chains of functions together, allowing for performance benefits.’’

Having something ,,beautiful’’ and inefficient is the problem I’m writing about. The language itself is guiding people to inefficiency.

I haven’t felt this with C++, so I’m not sure what you are talking about: usually simple / pretty code runs fast there, and more complex code runs slower.