Erlang is slow, if your problem has a certain structure. Your problem must be CPU bound. And constant factors must matter. In almost all other cases it is more capable than most other systems. And the Erlang solution to CPU bound problems is to punt it to a separate program built for that purpose. Ericsson has done this for years by pushing CPU bound things into hardware because C is too slow for what they are doing.
Erlang does, however, target latency over throughput. This means that to the Erlang system, it is more important to provide low latency than to provide high throughput. Usually it is very fast, but this choice can in certain situations hurt throughput.
The primary reason that Erlang is targeting a JITed VM right now is that it will make it possible to write more of the Erlang VM in Erlang itself, rather than C. This in effect means that Erlang will be easier to port, so that is a very good thing.
In my experience, larger systems run extremely fast in Erlang. This is due to faster development cycles and that you don't have the luxury of optimizing your C code in larger projects.
It is fallacious to pretend erlang is slow because otherwise you have to write bad, unoptimized C code. First of all, unoptimized C is still an order of magnitude faster than erlang (or more!). Second, there are other languages besides just erlang and C. For example, compared to erlang I can write the same thing in haskell instead, have it written faster, have fewer bugs make their way into production, and have it run faster.
If your C code is doing linear scans over arrays where a dictionary style lookup is really needed, then there is no way in hell the C code is going to beat the Erlang code. I've seen this again and again in C programs.
As for your Haskell program, you are right. But you will spend the next 3 months trying to fix memory leaks due to lazy evaluation :)
I think the bottom line, one we can agree on, is that a program written is not the end of development. It needs maintenance and where certain programming languages makes it easy to do something, other languages have a harder fare, and vice versa.
Erlang has a state-of-the-art interpreter. And a runtime written in C. It is not a slow language if you have a program that spends most of its time waiting for other things to complete or in the runtime. In fact, that is where it shines.
That said, don't write CPU-bound jobs where constant factors matter in Erlang. It is a bad fit for this, because of its interpretation overhead.
So now we're not just comparing optimized erlang to unoptimized C, but optimized erlang doing X to unoptimized C doing Y. You can write the wrong code in erlang too, C does not have any special (mis)features that encourage doing the wrong thing. It dishonest to say "erlang isn't slow" and use "I can write slower C code if I do it on purpose" as evidence.
The thing is that "slow" is naturally relative. I hate it when people claim that a tool is slow. By far the most important factor in getting programs that work isn't the technology but the mind behind the code. This is true for any programming language.
I guess the succinct answer is: No, Erlang isn't slow if you know what you are doing, barring the Caveat about CPU-bound problems. The message I am trying to convey is that there is more to fast programs than the execution speed of the technology at hand. It is a factor, admittedly, but it is not the sole factor.
