Erlang is a very specialised language. It does one thing well (scalability) at the expense of not really being a general purpose language.
The syntax is just weird, not only in a paradigm-way (pattern matching is not huge in most languages, but, hey, that's the way of doing stuff in functional programming), but on strange places ("read" lines ending on dot, semicolon takes time, it does not share any common syntax definitions with the languages used by 99% of the programmers). That sets a high bar in approaching the language, so it's difficult to "play around" with it (at least compared with other languages)
While I like some of the advantages of Erlang, the lack of general support for a lot of common operations (and yes, string manipulation is a huge deal) and the fact that it is designed with a very very particular problem in mind makes it "a silver bullet". Not in the usual meaning, but in the way that's only useful for killing a werewolf. For every other task is too expensive and just not the proper tool.
I was involved in a project that used Erlang for something not well suited for it, and it was absolutely awful, you have to wrestle with it to perform common stuff that in other languages is done by the standard library. Again, you win something, but only in a very very VERY specific problem.
(I've used it in another project when it was the proper tool, and, in that case, it's still not the most pleasant experience, but you're getting a clear win)
This. It's amazing and powerful if you need 1m+ client connections per server. Outside of the epic scale engineering problems of facebook, twitter, google, amazon, whatsapp... It's very difficult to get anything done with Erlang.
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 amazing and powerful if you need 1m+ client connections per server.
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.
For those following along at home, rvirding is one of the inventors of Erlang.
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:
Yes, that's me. Where is the "comment below"? Couldn't find it.
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.
I'd say it works for small scale as well. The concurrency is awesome, but (and this may just be from limited experience) I've yet to see another language that handles binary matching and manipulation as well. I tried to sell my current office on erlang for one project. Take a dozen mutually incompatible protocols (used by systems that can't be updated easily to a new or common protocol, that's actually been tried and is why there are a dozen protocols now) and create a proxy/translator server for all of them. In essence we have a dozen networks that can't talk to each other, but send the same information using their own formats. Writing a translator from one protocol to another (or my suggestion of one protocol to intermediate representation to second protocol, need only 24 translation modules instead of 12! translation modules) was trivial for my proof of concept sytem. The concurrency was really just a nice bonus, in this case.
That's the hype, but if you ask the people who built it, it's actually more about fault tolerance than scaling. And indeed, I'm using it for a semi-embedded system where stability is important, something that Go and Node.js, for instance, didn't seem quite ready for when we evaluated them a year ago. Erlang is pretty rock solid and is something that we'll be happy to have running without worries.
The syntax is just weird, not only in a paradigm-way (pattern matching is not huge in most languages, but, hey, that's the way of doing stuff in functional programming), but on strange places ("read" lines ending on dot, semicolon takes time, it does not share any common syntax definitions with the languages used by 99% of the programmers). That sets a high bar in approaching the language, so it's difficult to "play around" with it (at least compared with other languages)
While I like some of the advantages of Erlang, the lack of general support for a lot of common operations (and yes, string manipulation is a huge deal) and the fact that it is designed with a very very particular problem in mind makes it "a silver bullet". Not in the usual meaning, but in the way that's only useful for killing a werewolf. For every other task is too expensive and just not the proper tool. I was involved in a project that used Erlang for something not well suited for it, and it was absolutely awful, you have to wrestle with it to perform common stuff that in other languages is done by the standard library. Again, you win something, but only in a very very VERY specific problem.
(I've used it in another project when it was the proper tool, and, in that case, it's still not the most pleasant experience, but you're getting a clear win)