When I looked at it, the favourite quicksort example was so elegant, I wanted to learn the language. Then after I started looking at the run time (after wasting a lot of time going through learning Haskell), I realized that it was all a lie, ant that sort wasn't quick at all.
I don't see the same overpromising problems with Rust: you usually get the performance that you think you will get when you're writing the code.
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.
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).
(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.
,,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.
Rust is still a very low level language, but if you like Haskell, you won't go into anything else when writing some low level program.