TL;DR: "fast" isn't well-defined, and for a lot (or even most) applications "fast" is about latency, not throughput, and Erlang is "faster" in that sense.

[1] https://making.pusher.com/latency-working-set-ghc-gc-pick-tw...

[2] they eventually abandoned Haskell for Go https://making.pusher.com/golangs-real-time-gc-in-theory-and...

The other big part of this is that it can make stream fusion predictable. Currently haskell programs can become 100x slower or faster after some innocuous change, so linear types will make it a lot easier to write fast haskell in general.

http://blog.tweag.io/posts/2017-03-13-linear-types.html

Obviousness is hard to pin down. What may be completely obscure to a Haskell beginner is obvious to a veteran. Is it really fair to count people's strict-language preconceptions against Haskell? I don't know.

GHC provides a wealth of profiling tools that an expert Haskell user can employ to find space leaks. Heck, experts generally know where to look (excessive use of lists, spine-nonstrict data structures) so that the profiling tools become a last resort.

Since performance is exactly a measure of the number of imperative steps that need to happen in a program, low level imperative langauages are going to win in performance-obviousness every time. (Rust probably beating C in terms of avoiding memory problems, C probably beating rust in terms of not supporting language constructs that can make a single line worse than O(1).)

"Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell.

Unless you use GCC's cleanup extension (which runs an arbitrary function when leaving a scope, similar to Rust's Drop trait). Or evil macros which turn innocent-looking code into something else (a well-known project, in some compilation modes, redefines the "if" keyword to track how many times each branch is taken). Or both at the same time (like hiding GCC's cleanup extension with a macro).

This is an oversimplification. Writing fast code for modern processors is all about how much time you spend waiting for memory.

e.g. bubblesort will beat quicksort for tiny lists or large lists which are already sorted.

Or, put another way, 1000 operations against 1ns latency memory (L1) has the same performance as 10 operations against 100ns latency memory (RAM).