Carry On

The comments to Cedric Otaku's "verdict" on Erlang are a better read than the post itself. A smattering of choice words...

It is amusing to watch people attempt to tear apart and deconstruct Erlang, trying to refute its benefits, while Erlang coders continue on their merry way creating incredible software. Carry on, Java programmers!

and

What you're saying in effect is that despite the fact that the Erlang guys have already proven this stuff in practice time and again with actual, working, reliable, and long-running telecommunication systems (and systems in other fields as well), your gut feelings are a much better proof and indicator of what actually works in practice and what doesn't, so the reader should believe you, not them. Wow.

and

The real difference here is that it is much simpler (i.e. you don't even have to think about it) to run the supervisor process on an entirely separate node in your cluster. This is paramount for real fault tolerance in a running system, and you don't even have to think about it in erlang. I don't know how easy or hard this would be to accomplish in Java, but it is stupid simple in erlang.

and

In fact, the "post message to mailbox" operation has historically been the most tightly tuned hand-written algorithm in the entire erlang VM, for exactly that reason... but go ahead and assume it sucks. :)

and

Someone suggested Java can't compute 4 digit factorials. Use BigInteger - and it comes back in a snap for the factorial of 1000.

(You gotta love *that* one, don't you!) And...

Man, I'm sooo over language wars.

Finally from the post itself...

The only way a process can modify the state of or talk to another process is by sending a message to that process. Regardless of how lightweight the implementation of this message passing is, there has to be a lock on all these inboxes to guarantee that when dozens of processes send messages to your own process, these messages are delivered and treated in the order they are received from.

Erlang makes no such ordering guarantees. The messages from any process A to any process B will arrive in order, but independent of the interleaving of messages to B from processes C to Z or beyond.

And like Mark Baker has said about designing Restful HTTP systems: nobody said it would be *easy* just more simple and rational than other approaches. I don't know anyone who said Erlang made complex, distributed programs *easy*. But Erlang makes some aspects simple, gets you thinking in the right way, and has a body of knowledge and community easily available to help you build large systems.

Earlier in the year the team I am on took on building the kernel of a potentially large system using Jini/Javaspaces. That is the most "erlang-like" tool for building large, distributed systems in Java. (No, ESBs are not even in the running.)

The software was fine. The mechanisms worked. The biggest lack was the community. It would take a good deal of effort to build up our own knowledge base. There were bits and fragments and people like Dan Creswell we could call on to get advice here and there. But Dan moved on from J/J for the most part into another full-time gig. The rest of the community just wasn't there.

That community and knowledge base seems to be pretty much in place for Erlang development. That in itself is a huge advantage. Carry on.