Over the last week or two there’s been a bit of commotion with various parties in the blogosphere making the case for Scala against Erlang or for Erlang against Scala. Here’s a see spot run summary of the main writers and their positions / content:
Ted Neward (1, 2) – Ted (how confusing) is in the Scala camp, and thinks that the library approach of Scala’s actor library is preferable to Erlang’s VM (BEAM). He cites managability as a major concern. He also thinks that adapting a process style model into the JVM would be easier than adding SNMP monitoring to BEAM. The length of the Barcelona project bibliography suggests otherwise, but we’ll never know unless some brave soul goes and tries to do this. Fortunately, the JDK is open source now. One has to wonder whether such a change could make its way through the JCP, though. Unfortunately for Ted, I found that many of his arguments were weakened by his lack of knowledge about Erlang.
Steve Vinoski (1, 2, 3) – Steve’s articles are more about the reliability aspects of Erlang, and he’s mostly trying to correct Ted’s facts on Erlang. He thinks that Erlang had proven its reliability chops by running for years non-stop. Given the frequency with which Java app servers need to be (or are) bounced, this doesn’t seem that incredible to me.
Patrick Logan (1, 2, 3) – Patrick piled on after Steve and has spent most of his writing trying to correct/challenge Ted’s assertions about Erlang. Patrick thinks that the conventional (i.e. JVM and CLR) runtimes will have problems implementing an Erlang style shared-nothing model, since the pre-existing libraries for those runtimes are not engineered in a shared-nothing manner.
Barry Kelly was an observer of the Neward-Vinosk-Logan discussion, and added some commentary on the impact of VM primitives on things like lift. This is a point which resonates with me, because it seems to me that both languages and language runtimes will need some work to meet the challenges of large scale multicore computing.
Yariv Sadan has done a pile of stuff in Erlang, and supplied his own summary of the differences between Scala and Erlang. There is a very informative exchange between Yariv and lift author David Pollak in the comments of this one.
That’s the short rundown. This is a very interesting problem space — before I turned into database programming language guy in graduate school, I was angling to be a concurrent programming language guy. Along the way to that I got pretty good doses of functional and logic programming, as well as actor programming. That work was in the context of people planning to build (for the day) highly concurrent computers, on the order of 1000’s of processors. Today, multicore hardware is not quite up to that level, but it is approaching it pretty quickly. If there is any force in computing that is likely to precipitate the need for a new programming ecosystem (language, runtime, libraries), I think concurrent programming is it. I also think there is just not enough experience with this problem to have a real sense of what is really going to work. Cliff Click and Brian Goetz were right when they said that we just don’t have a good programming model for this stuff. Absent a model, I don’t know how we can think that we really understand what the runtime needs to deliver.
Erlang already has built-in SNMP support. It might not be at the BEAM/VM level (I haven’t tried it yet), but adding Erlang-style processes to the JVM or CLR would be *at least* as hard, probably much harder, considering the shared-memory semantics of most languages not named Erlang.
I researched the Actor model this year, and wrote the same program in Erlang, Scala, Rubinius and Io using their Actor/Erlang-style concurrency libraries. Erlang was orders of magnitude faster than the other three, and Scala was the slowest. Also, I was able to run hundreds of thousands of Erlang processes on my MBP, whereas I couldn’t get even a few hundred running reliably in Scala or Rubinius. Io scaled to thousands of coroutines in my testing, but not tens or hundreds of thousands.
References:
http://erlang.org/doc/apps/snmp/index.html
http://www.erlang.org/doc/pdf/snmp.pdf
I know you were citing Ted, but the statement about Erlang’s missing SNMP functionality is false.
I haven’t used myself, so I can’t comment on its quality, but Erlang’s SNMP support seems pretty decent:
http://www.erlang.org/doc/apps/snmp/part_frame.html
I attended that Click/Goetz talk and was disappointed. Clearly both speakers are heavily invested in the status quo. There are plenty of potential models, actors/message-passing, tuplespaces and transactions among them, and they are pretty old. Click/Goetz were right – they/Java don’t have a model. But while they kicked sand at Erlang and STM, they failed to acknowledge the elephant in the room – it’s quite likely that the traditional OO architecture of a program as a graph of mutable stateful objects, exemplified by Java/C#/Python/Ruby et al, is a poor fit for concurrency.
I think we do have a model for concurrent programming: actors/processes that send and receive messages. I personally can’t imagine another model, well maybe actors/processes that share memory!
Rich,
I agree that Click/Goetz are heavily invested in the existing Java infrastructure, and I am not sure that I agree with their assertion that the OS and VMs are ready to go. But I don’t think that any of the potential models have proven themselves on a very broad scale.
I think that they danced around your point on mutable stateful objects, and I also suspect that mutable objects represent problems for concurrency.
@Jim Roepcke do you have a blog write up of what you were specifically benchmarking between actor frameworks? the great language shootout clearly shows that for creating N actors and passing messages between them, erlang > scala, but not by “orders of magnitude”. i’ve also heard d.pollack make a case that for actual processing (what you do with the message) that scala is many times faster than erlang.
Wow! You do “see spot run” very well. Nice. I don’t have any stake in this particular debate, but it is nice to have an appraisal like yours to get a feel for the concerns and approaches.
jherber: I haven’t published my results yet, I’m refining my paper, I might submit it to the ICFP Erlang workshop.
We have tried the SNMP module as it is one of the basic feature for our supervision console for ejabberd. It works well. If you know what you do you can gather very low level information about Erlang, the state of the VM, etc.
@jherber The great language shootout obviously should be taken with a huge grain of salt, but I thought I’d just mention that the thread-ring benchmark specifies exactly 503 processes, which is hardly enough to reason about differences when running hundreds of thousand processes.
It’s noteworthy, perhaps, that among the top entries in that benchmark, Erlang, Mozart, SML and Scala use a message-passing solution, while Haskell, Smalltalk, GCC and Lisaac all rely on a mutable shared token.
Personally, I think it’s interesting and fun that both Scala and Erlang are gaining ground. Perhaps trying to master both is a worthwhile pursuit?
Pingback: Janko in a Jar » Blog Archive » Mochiads injection