One thing I hate doing in Ruby (or any language for that matter) is setting up a web service or anything that requires a read/write socket. That's one of the reasons I like Erlang so much - the messaging takes a lot of the hassle out of the equation.
You build a module, register it (so you can address the module by name instead of PID), and send messages (see my tutorial a few entries ago). I've also become interested in the message bus idea. All concerned processes are tied into a communication circuit wherein they listen for messages addressed to them and send replies as appropriate.
Erlang offers fantastic stability (one project that involved 2 million lines of Erlang code achieved a nine nines reliability, which is absolutely unheard of) but is somewhat counter-intuitive when you're getting started. Ruby (or Python, PHP, etc) is very fast to write and generally makes sense but I find it's a pain in the ass to do network I/O. God help you people who do it in C or Java.
So I got to thinking that having an Erlang-powered 'spine' may be just the thing for a SOA. If one bites the bullet and writes an Erlang back-bone to handle the interconnectivity between machines and act as a central nerve fiber between interpreted language processes.
The hard part in my mind would be adding a smooth interface between Ruby and Erlang but once that's done it's trivial to hang another Erlang endpoint off the bus to do the talking.
I'm probably not describing this well and as such it may come out sounding really, really stupid. But I think it will at the very least be a good learning experience. The more I work with Erlang the more I like it and the more potential I see in it. If you haven't looked at it, I strongly suggest you at least give it a try. It can look very strange and will challenge some of the basic ways you think about coding, but it is very worth it.
If message passing ease is the only thing you're looking for, it would likely be much easier to create and use a message passing API for ruby instead of trying to make a ruby erlang language bridge.
If you design your API carefully, it can abstract the socket stuff for you (but you obviously loose some low-level control when you decide to do things that way).
Message passing isn't the only idea behind it, but if it were, you're right. Something like the Revactor gem would be simpler.
The advantage to having an intelligent back bone is that it could not only relay messages between interpreted language processes, but could also receive and send messages itself. If nothing else, the idea that one of the Erlang nodes could transfer it's state to a known but under-used machine and continue it's business there is just fun-sounding.