This articles is now 5 years old - any Erlang programmers who can enlighten me about the current state of Erlang compared to the predictions in this article?
The library support and community have both deepened. Riak has been built, Facebook Chat has proven its scalability, open source projects have mostly moved to GitHub, #erlang and #erlounge IRC channels on freenode.net are very friendly and well populated.
In the web space, there are now several options if a small team wants to build something to scale to 100k+ concurrent connections on a single server. Hackers in #erlounge are regularly benchmarking systems with 500k+ users. It's crazy talk.
Actually, I was talking to a few facebook guys a couple weeks ago and they rewrote the chat app in c++ a few years ago. The primary motivator was that nobody knows Erlang, while most of their engineers already know c++. I found that really surprising coming a from a company that prides itself as having the smartest people around, and, as awesome as Erlang seems, after hearing that I might think twice about using it for a project if there's a possibility that I'd be hiring other engineers to work on it with me.
I think that certain realities take over when you get as big as facebook is. It's not the little start-up that could anymore, it's now the 800 lb Gorilla that churns though staff. While you might be able to have the smartest people around at your beck and call you'll want to keep the system accessible to as many of them as possible so your options are always open and there are always going to be more C++ programmers around than Erlang programmers.
This is weird though because erlang is way easier to wrap your head around than C++. A C++ programmer should be able learn erlang in a a couple weeks max. If they can't do that then I probably don't want them doing C++ code for me either. Now if they rewrote it in java, because java programmers are easier to find, that might be less weird but C++?
Yup - because the language extensively uses tail call optimisation, inlining and other rewriting in the execution it used to be hard to reconstruct the original state of the code on a run time failure. It is less of a pain than it seems not to have line numbers in error reports - but it is still a pain.
Actually, the inliner is not used unless you explicitly enable it (for the core). The runtime BEAM backend may decide to inline as well, but that is another part entirely.
But yeah, it is not much of a problem having no line numbers when your functions tend to be of a 4-5 line size.
