Erlang is at long last getting the break it deserves.
scaleordie.com
scaleordie.com
What people will use it for is up to their imagination. Wings3d (http://www.wings3d.com/) is a good example of using Erlang outside of its "intended" domain.
Don't forget that when Java came out, it was only "good" for writing applets...
Chat, IM, SMS, message queues, etc. are all well-suited for Erlang. Tasks that involves lots of I/O and parsing, not so much.
Erlang has weaknesses, but certainly those are not it. Basically, Erlang excells at writing servers. Take a look at YAWS (http://yaws.hyber.org/) for a web server written in Erlang that can actually outperform more traditional web servers in very realistic scenarios.
If I had to name a weakness or two of erlang offhand:
1. Integrating foreign code with Erlang is very different from traditional FFI and requires some initial legwork (libraries like Erlectricity http://github.com/KirinDave/erlectricity/tree/master , for example).
2. String manipulation. Erlang doesn't have a real string type. Its string libraries and core string type assume using linked lists for strings, which is spectacularly inefficient. However, there is a movement and a proposal to change the string type to Erlang binaries and provide an alternative string library. Hopefully that will address the problem.
Other than that, it's a reasonably fast and rock-solid implementation of an FP language with a mountain of solid IPC library code integrated at the language level.
I think the "Erlang sucks for strings" argument is overblown, and it's rarely if ever backed by real world experience and/or data. Erlang is fine for most string handling tasks you'll find in a typical (web) application.
We have to be honest identifying our tool's weaknesses, Yariv, even if we like them. EEP-009 (http://www.erlang.org/eeps/eep-0009.html) and EEP-010 (http://www.erlang.org/eeps/eep-0010.html) are extremely important for the continued growth and adoption of Erlang.
Erlang may not be optimal for applications that do heavy string processing, but the significance of that statement is overblown. Take typical webapps for example. What kind of string processing do they do? Very light stuff. They spend of their cycles slurping binary data from the database and sending it down a socket. Erlang is excellent for this usage. They occasionally take form inputs from a user, in which case they do some simple processing to ensure the input is properly escaped. Erlang handles that just fine.
Most of the "Erlang sucks for strings" arguments remind me of the "Ruby/Java is slow" arguments. They're sort-of true, but they just don't matter for most applications.
Please don't confuse this sentiment with any anti-erlangism or any assertion that Erlang isn't fantastic. I just want to be realistic, and I'd love to have faster string processing to make faster routing code for Fuzed (http://github.com/KirinDave/fuzed/tree/master).
The best thing Erlang has going in the parsing area is the binary pattern matching, which if you convert a string to a binary works wonders and is much faster. IN fact switching a string to a binary, doing your parsing with binary pattern matching and switching it back to a string CAN be faster in Erlang than using Erlang's string functions.
I won't go into comparisons to other languages, mostly because my personal opinion is that Erlang has so many other great features that not being good at string processing is a minor issue.
Come on guys, give Erlang a break.
Erlang deserves nothing. Its just another language - one which I happen to think has filthy syntax, and will probably never use for that reason.
Heavy? They must be going by Facebook's user base, not amount of code (the system is a hybrid of multiple languages) or even actual usage (they just launched it, I doubt everyone has switched over from IM yet, if they ever will).