This is an old article (2008) and some things might have changed with Akka for Scala (http://akka.io/) which tries to give Scala much of the functionality of Erlang. I personally haven't tried Akka but I have a good friend prototyping with it right now.
The sad thing is that this same friend just built a huge system with Erlang for another company and loved it. It did the job wonderfully and performed under pressure like a champ. However the new gig for him wouldn't let him use a 'non-java' programming language. Scala is even a stretch.
Given my experience with Erlang, I can wholeheartedly recommend it to someone looking to build a system in Erlang's sweetspot.
I thought that Akka was going to be the missing link on Scala also. So I started investigating and building, and ran into some roadblocks. In particular, I found that Scala offers actors, but the distributed and highly available cluster aspects that Erlang's OTP offers were missing from Scala. Akka looks like it's going to provide this, at first blush. But after further investigation, it doesn't really provide that, yet, at least it didn't last I checked.
So I posted this question on StackOverflow and on the Akka mailing list:
The question is about how you build fault tolerance, such that your cluster has no single point of failure. At the time, the principal authors of Akka responded saying that you can't right now out of the box, and they're working on that for a later commercial release.
Since then I started looking at integrating Scala + Zookeeper, and more seriously considered Go + Zookeeper, and it revived my interest in Erlang.
The author of the project claim, that with time Erjang will be better/faster than Erlang, since JVM getting improved faster, than standard Erlang VM - BEAM.
Erjang is looking good, they have almost implemented the full functionality in the standard BEAM implementation. You can quite happily run distributed Erjang together with distributed Erlang BEAM, it is very impressive. As LFE (Lisp Flavoured Erlang) runs without problems on Erjang (it would be surprising otherwise) this means that there is now another Lisp on the JVM.
The author cites immutability as a large concern for using Scala. Immutability is pretty easy in Scala - use vals (like final in Java) and persistent datastructures (which have the same API as mutable objects), so I don't think this is a valid concern. Almost everything I write is immutable.
I'm not very familiar with Erlang, but I thought mutability was pretty easy to achieve there. Maybe it's the messages that have to be immutable? Could someone clarify?
The closest thing Erlang has to mutability is the process dictionary (get() and set()), which can be thought of as a sort of memcache for each process. Native variables themselves are immutable, without exception.
Unless you have a really good reason, using the process dictionary is generally frowned upon.
While the dictionary itself is mutable the data in it, both keys and values, is immutable like all data in Erlang. It is the same with ETS tables which behave more or less like processes, the data in them is also immutable.
The sad thing is that this same friend just built a huge system with Erlang for another company and loved it. It did the job wonderfully and performed under pressure like a champ. However the new gig for him wouldn't let him use a 'non-java' programming language. Scala is even a stretch.
Given my experience with Erlang, I can wholeheartedly recommend it to someone looking to build a system in Erlang's sweetspot.