Erlang, the next Java

I had the fortune of doing a lot of work with Erlang over the last 3 years, even helping to ship a product that relied on it for some middleware. Erlang is great for some tasks, and if you don't know it (and you're of a programming discipline) you should learn it, if only to get comfortable with Actor concurrency.<p>My newest job requires interoperability with a lot of Java code, so I've been working with Akka, using Scala. While I haven't yet been able to examine if it really can scale the same way that Erlang does, so far its been off to a fairly good start so long as you are disciplined.

Is the ending of this paragraph a typo or a joke?<p>"One way that Erlang differs from OO languages is its emphasis on failure. Any message can fail. Processes don't raise an exception, they fail. Systems are structured as worker processes at the bottom that are likely to fail, with manager processes above them that restart the failed processes. Because programmers expect processes to fail, they"

Also, this is a 3yo talk. At what point do we say, no, no it's not (and I'm a Java guy who really likes Erlang).

I like the article's emphasis that it is the lack of shared state that is more important than the fact that the language is functional. Also it is the "mystical view" of objects that contains all the value. Unfortunately its also the baby that some people fail to see when they want to throw out the object bathwater.

I like Erlang, but it is not going to be the next Java in terms of ever ranking at the top of something like LangPop.com.