This really isn’t the place to come for Ruby news. But that’s OK, because I have the pointers to where you should go. Plus, one of the news stories is making me think “Smells like Erlang.”
Where to Read · Antonio Cangiano has started a regular This Week in Ruby, which seems to hit all the high points. I’ll expand on a couple of items that I thought were high impact.
The Book · Hey, there’s a new edition of Agile Web Development with Rails, which is good and not unexpected. I’d kind of wondered why we hadn’t heard much lately out of Sam Ruby; now we know. Me, I don’t use Rails myself (I have an attitude problem about database software). But lots of smart people do.
The Summit · Charles Nutter wrote this up at length. I was there for a lot of it, lurking except for a one-liner: “twbray thinks trans-Pacific co-operation on test suites would be a big step forward for Ruby.”
What I wanted to highlight was all these teams getting together online cheerfully and without any detectable attitude to talk things over. Kudos to Matz for launching it, and to everyone for pitching in. I don’t want to go over the top, but with this many teams full of Really Smart People competing co-operatively to build the best Ruby, well, how can Ruby lose?
Erlang · Check out Charles Nutter’s description of the multi-virtual-machine (MVM) issues here and here.
The notion is that multiple VMs in a single top-level VM have no programmer-visible shared data, so if they want to talk to each other they need to interchange messages. Rubinius is furthest along in thinking about this, and the verbal description of how this works made me think of Erlang.
My experience in the Wide Finder didn’t particularly make an Erlang-lover, but I sure did come to appreciate its message-interchange framework.
Now, no dialect of Ruby is ever going to be as purely functional as Erlang (thank goodness) but I have to say that the notion of this sort of message-interchange API wired into the language kernel seems like a A Really Good Thing, as we face the many-core future with woefully inadequate tools.
Contributions
Comment feed for ongoing:
From: Nathan Bell (Apr 27 2008, at 22:45)
Non-shared state Ruby sounds really interesting, I'm excited to see more Erlang-like philosophies sneak into other VMs.
One of the things that makes Erlang's shared-nothing multi-process paradigm so powerful, though, is the fact that processes are incredibly light weight, you can spin up several thousand and the VM will barely blink an eye. Lightweight processes facilitate the VMs ability to shift them around on different cores/cpus and scale and hide most of the details from the programmer (though I respect that your experience with Erlang left you slightly soured on that promise).
Multiple virtual machines running on top of another virtual machine sounds decidedly not light weight, and so I'm skeptical you'd want to use it as a way to abstract out scaling to the extent that that Erlang attempts to, but maybe that's the point.
[link]
From: Jeff Carroll (Apr 28 2008, at 11:52)
I've always been mystified by the apparent lack of enthusiasm for Occam on multicore hardware. It's an imperative procedural language with a syntax that explicitly specifies algorithmic parallelism; in its current form it'd be pretty verbose for running thousands of concurrent threads, but it would seem that would be fairly easily fixed, if only with a preprocessor.
Besides, what's the point of using thousands of threads to run your program if the hardware's only capable of a hundred or so?
[link]
From: Tim (but not THE Tim) (Apr 28 2008, at 20:59)
Understand I'm not a true language geek, but if the architecture of the underlying operating system's dispatch system and the hardware handle preemptive resume scheduling, then you want to run more threads than the hardware supports so that when one is waiting for something (I/O, an event, etcetera) another thread can be scheduled to process instructions.
[link]
From: someone (Apr 29 2008, at 15:48)
Criticizing Erlang for being lousy at ad-hoc scripting tasks is like criticizing Java for not being good for writing operating systems: it's missing the point and fails to evaluate the language against its design goals.
[link]