well well.

I'm going to be honest, I've never really got into Ruby. Yes, it has some nice features (good list and hash table syntax; tuples), and of the trinity of perl, python and ruby its certainly the prettiest to read. But its just, well, so single-cpu, single-thread centric. Now, Ruby+Rails does meet that ubuqituous use case: code behind web servers, but that's it. I'm still not sure about its scalability or ease of distribution. Because once you start depending on remote things, from S3 storage to adword services, even if you are in rest-land, you are talking to slow servers where delays are inevitable, and things that look like in-process invocations are wrong.

Erlang has an interesting mix: a bit of functional programming, a bit of message passing. Admittedly, it does seem biased towards CORBA for distribution, but let's spend a moment to think of some nice aspects of CORBA:

1. There are stable standards for the various bits of the CORBA specs
2. Built in support in Gnome.
3. Vinoski and Henning provide a nice book on the topic
4. Integrates with Java, C++, other systems, with interop that works.
5. No need to go near WSDL or XSD when coding

I'd be curious about how well it would integrate with ICE for sure.

One selling point for Erlang is that it scales out to highly parallel 16-way and later CPUs. Now, in the past, languages that have focused on that have failed. And of course there was the Alice Graph Reduction Machine. I worked with someone who didnt finish his PhD on that...I think he was too embarrased by the end, that Imperial Colleges distributed Lambda Calculus engine was slower than the client 68K-based SunOS workstation by the time they had finished it.

But that was the past, where improvements in scalar processing meant that single CPU parts retained an edge, and Intel's x86 revenues let them invest in the fabs for the next generations of CPU; using capital investment to give them an edge over competing CPUs. Nowadays everyone is making multiway CPUs.

Which means eventually, all developers have to deal with it. I wonder if the increase in bugreps related to Ant's <parallel> task are a sign of this in Ant. SmartFrog is concurrent from the ground up, but once you bring RMI into the mix it is very hard to be 100% sure you will never have race conditions or deadlocks. You can't blindly use synchronized(this) {} everywhere, if every method call to an other object could trigger an RMI call, then and RMI callback on a separate thread. Concurrency in a distributed object framework is hard -and that goes for stuff that use SOAP but retain the RPC/RMI metaphor.

So, maybe this is Erlang's big day. I shall certainly place an order. I wonder what Erlang's REST facilities are?