How about OCaml? It's not as theoretically advanced as Haskell, but it gets work done, is easy to read, fast, easy to reason about the complexity of, has decent libraries, and is generally quite pleasant.

I would be interesting in learning more about the "easy to reason about the complexity" part of OCaml. The problem I'm having with Haskell isn't that it's too slow, but that it's so high-level and gets so aggressively optimized at compile-time, that the performance of the resulting binary has performance characteristics that are unpredictable and non-deterministic. Performance can regress between GHC releases, for instance. This just seems to be a problem of high-level programming languages in general, they're really slow until you start optimizing them at compile-time. And with each one of those optimizations, you get another layer of indirection with regards to how disconnected the speed of the code you wrote should be vs. how fast the final product actually is. Haskell has no business being as fast as it is already, but GHC gives it to us at the price of long compile times and very fuzzy performance properties that are very finicky and expert-friendly.

The problem I see here is just the unsolved computer science problem of how to reduce the complicated, drawn-out, and error-prone job of a C programmer into the succinct job of a functional programmer without fundamentally pretending modern computers work in a way they don't.

Not trying to detract from your point, but it's interesting to note that even C and x86 are "pretending modern computers work in a way they don't" (see http://blog.erratasec.com/2015/03/x86-is-high-level-language...).

The complain list on Ocaml is almost always smaller than on Haskell. It might be easier to just fix Ocaml's issues and use it. If not permanently over Haskell, then temporarily until Haskell can get their more complex issues solved.

I think Haskell is optimized for _rewriting_ code. Personally, I think this is far more important than reading code!

Being able to read code is great (e.g. Python), but if you can't change things without fear the natural tendency of the codebase won't be in a good direction.

Haskell can actually take a while on the first write, but once you have the rails of the type system down it's sooooo easy to change things, even in a codebase you're new to or haven't touched in a while.

I think that's changing. A lot of the over-proliferation of operators came from missing functions (like Data.Function.(&)), missing typeclasses (Like with Data.Lens or other generic operators), or missing sugar (like Applicative Do or Idris' bang notation).There's definitely some cleanup work since the ecosystem's changed so much, though.

I disagree.

Haskell, like Perl, gives users more freedom to express themselves than other languages.

Unlike Perl, many (most?) Haskell features are oriented towards ease of statically understanding programs without executing them. Haskell culture is much about reasoning power around Haskell programs.

Reasoning about programs is the ability to read code in depth.