Go build something with it, like a phone switch, then we'll talk.
Kidding aside, I think the fact that Erlang got thrown into the production ring so early is perhaps a hindrance to its growth in some ways. They can't just go fiddling with the language at this point without some serious breakage, whereas newer languages like Scala and Clojure would probably not create major problems should they go through a few incompatible versions. Yes, people are using them in production, but not for things like phone switches!
Haskell needs an equivalent to OTP and cross-process/cross-server message passing before it can seriously replace Erlang.
I say this as someone who would like to see that happen (though I have no resources to do it myself). But until that happens, Erlang has a niche that Haskell can't fill; you can toss robust, multi-machine-scalable servers together in Erlang way faster than you can put them together in Haskell. It's not something intrinsic to the language, it's just Haskell doesn't have the libraries.
To my understanding, a major reason that Erlang was written was because they needed a concurrent system with soft real-time guarantees - in order to work for telephony, it had to operate within predictable, bounded amounts of time.
Conventional Prolog wasn't an option* , because the backtracking inherent in its execution model leads to significant variance for worst-case timing for individual operations. The same problem can happen with lazy evaluation, for both time and space - while the sophisticated compiler optimizations can allow for some really remarkable amortized performance, individual worst-case measurements can still have some serious outliers.
* Though Erlang was prototyped in SICStus Prolog.
With lazy evaluation, forcing a thunk for a seemingly minor operation can trigger a burst of postponed work. This can be a problem if it means a sudden drop in a game's framerate, for example, much like non-incremental garbage collectors' pauses have made people wary of using GC. Similarly, a JITting compiler can do more elaborate optimizations if it can afford to stall the program perceptibly while performing them, but that would disqualify the compiler for many real-world uses.
Real-time operation can impact performance, much like implementing full transactions slows down databases. Still, it's a fairly significant feature in its own right, and a language that does concurrency faster overall, but cannot prevent occasional erratic timing, is aiming for a different target than those (e.g. Erlang) that have such guarantees. It's not unusual for a program that juggles tens of thousands of connections to need to respond to them promptly, for example. Concurrency isn't just about performance.
(Also, that's why the Erlang movie has that "Declarative real-time programming NOW!" banner in the background. :) )
Mature, consistent and simple to use libraries with good documentation is what Haskell lacks most. The foundation is great. Scalable servers could be a good niche for Haskell, but it would probably need backing by one or more companies to get there.
Haskell has amazing potential... But it's hard to argue with Erlang (running Ericsson's 24/7 real-money business), OCaml (running Jane Street's 24/7 real-money business) and so on. Is there anyone with serious performance and reliability requirements that's bet the farm on Haskell (yet)?
It's definitely an interesting language; but I would see it as more competitive with C, C++ or Java as a language for building high reliability components.
I'm starting my grad career under one of the co-founders of Galois (Andy Gill), and one of his projects while there was to build some kind of VHDL generator tool for encryption (I only saw a high level description in a presentation, so I may not be entirely accurate describing it as such).
It created layouts that performed over 10% faster than the best hand-tuned layouts at the time. My understanding is that it was for the DoD.
Kidding aside, I think the fact that Erlang got thrown into the production ring so early is perhaps a hindrance to its growth in some ways. They can't just go fiddling with the language at this point without some serious breakage, whereas newer languages like Scala and Clojure would probably not create major problems should they go through a few incompatible versions. Yes, people are using them in production, but not for things like phone switches!