If you have fewer than a million people using your application at a time, you're probably better off writing it in a more normal language.
It's pretty dang easy to do that today with LuaJIT/C, and you don't get any of the other baggage (weird syntax, sub-standard string handling, lack of libs, etc.).
I'm literally building something that is right in Erlang's wheelhouse—exactly what is is designed for, and I'm not using it, despite knowing that, because it's easier for me to get exactly what I want in LuaJIT/C today.
I get garbage collection when I want it. I get arena allocation when I want it, too.
I get custom JIT-compiled functions when I want them (DynASM), but I also get JIT-compiled methods in Lua when performance matters less.
I can talk directly to my network hardware with a driver written in Lua. That's likely possible in Erlang, but I have no idea how and no time to learn, either.
I also know how to solve anything I'm likely to encounter in C. With Erlang, I'd have to learn a new way to solve it. Who knows how long that would take to do well?
I really do like Erlang at the conceptual level, but not enough to endure all of the other things I don't like about it. I'm also far less concerned about C than I was 10 years ago. The tooling around C these days is really quite incredible for people who want to do safety-critical systems, or high-availability systems, or whatever. You can get as much assurance about your code as you want with a reasonable amount of effort.
e.g. string handling
Robert - one of the things that occasionally bothers me about Erlang is that if something like string handling is so trivial, then it should be made available as a more extensive library, rather than an exercise that leaves the reader wishing they were using another language that handles boring stuff like that. It may well not be trivial for the person just get started with it, and you've lost a user if they give up in frustration.
Here's one of the other inventors of the language asking for help about splitting a string, for instance:
http://erlang.org/pipermail/erlang-questions/2014-February/0...
I just want to point out that I don't dislike Lua at all, it is a small neat language with some very nice features. It just isn't something on which I would base a parallel system as it has too much sharing and other things which don't go parallel easily. Using it as plugin to erlang for doing "business" logic works quite well, either by communicating with a Lua system or doing like Luerl and implementing it Erlang. This means that Luerl meshes completely with Erlang.