Forking Ruby—my RubyConf Keynote is now up

There's a sound that no presenter wants to hear, and that's dead silence. And that's what greeted me when I made the suggestion in my RubyConf keynote that the community should fork the Ruby language. I think by the end of the talk, though, most people were convinced.

Am I anti Ruby? no.

Am I suggesting Matz is doing a bad job? Not in the least.

But I do think the complexity of the current language inhibits experimentation with language features. Want to implement parallel Ruby? If you do it with the current syntax and semantics, you'll be struggling with the integration of global variables, the non-threadsafe nature of require, continuations, and so on, and so on. So before starting these kinds of experimental projects, I'm saying we should fork the language. Produce variants that let us focus in on the aspects under test. Make the new language a rich-enough subset that you can do useful work with it. Then let people play with it. Maybe the ideas are stellar, in which case we can all talk about integrating the changes back into the mainline language. And maybe the idea didn't pan out, in which case we can quietly forget it, and we've done no damage to the language itself.

A mutation is an altered fork of the original. And mutations are essential to the diversity and strength of a genetic line over time. Let's not be afraid to create Ruby mutants and let them compete.

The keynote is available from Confreaks.

Comments

[Chad Brewbaker]

Listening to the talk as I write this post but reading the blog entry I had three things.

1) Writing rubyish parallel extensions with MPI under the hood for the MRI wasn't all that bad, you just need a few global variables and need to start up MPI before the VM. My problem may have been specific to Blue Gene/L, but I got stuck with 1.8 and gave up with the introduction of 1.9 because I needed everything to run under a single OS thread. I'll try to find my latest version of gRuby for MRI 1.8.6 and post it.

2) The Array class is ok, but it should be used sparingly. For small data sets and linear time processing it is a good choice, but Ruby needs something similar to the STL Vector, List, Map, Multimap that have efficiency guarantees with them. I don't care if Ruby is 10x slower, but I have to have my big-O guarantees.

3) We need to benchmark the serialization functions and make them ultra-efficient. When doing parallel programming you communicate a lot of objects, and unless serialization stays acceptable at the Ruby level you have to go under the hood and mess around in C land.

[DanF]

I like it Dave. Especially RubyLite. That's pretty much what drove me back to Python from Ruby. Operator bloat and rails being insane. And nice presentation via confreaks.

[Nathan Youngman]

If the presentation didn't mention, there were two "forks" going under Sapphire some time ago:
http://www.rubyinside.com/sapphire-two-different-new-re-implementations-of-ruby-819.html

And of course all the implementations that are attempting to maintain parity with MRI... JRuby, IronRuby, Rubinius, MacRuby...

[Dave Thomas]

Nathan:

Apart from the second Sapphire, those are forks of the current interpreter. I'm talking about forking the language itself.

The second Sapphire is closer to what I had in mind, but is still (to my mind) not radical enough.

Dave

[Nathan Youngman]

Interesting talk... experimenting with variants. Isn't Sapphire Steel an actual RubyLite-esque language, or is it not that radical?

The Evolution of Lua is a great paper to read on trimming and refactoring a language. Obviously Lua doesn't fit the same domains as Ruby, but it's an interesting study of staying nimble.

The trimming mentioned rather reminded me of the goals behind Python 3, which is due to be released tomorrow.

[Oscar Del Ben]

I think forking a project is one of the best ways to learn how to use it. Thanks for the advice

[Charles Oliver Nutter]

Hey Dave, you should have been around for the lightning talks. Check out mine on Duby:

http://rubyconf2008.confreaks.com/duby.html

I've got ideas for other modifications as well; they're easier to try in JRuby than in the C impls.

[Roger]

There was a fork of python that made it more multi-thread [1] but...nobody really took it [1]

What do you want to trim from ruby?

The idea has some merit. As does duby.

-=R

[1] http://www.artima.com/weblogs/viewpost.jsp?thread=214235

[Victor]

It seems like we have perfect example of the forking on the higher level now: Rails << Merb.

Initialy Rails idea was moved away from main branch and formed new project: Merb. This new project was mutated and evolved into new form. Now it is moving back to Rails with new features tested and audited.

Is this what you want to see in the Ruby language context?

[Dave Thomas]

Victor:

It's a great example of the kind of process I'm hoping to see (and kudos to both teams for pulling it off)

[rawsausage]

Good speech. Shame you did not talk about the standard libraries, which should die in fire. Slow. I tried learning Ruby. The language wasn't hard. Then I tried to actually start building real world stuff using it. Stonewalled.

There's nothing modern to build GUIs with. There are no crypto functions around. RPC possibilities that I tried were all insanely slow and nearly undocumented. None of the net/* really supports SSL/TLS without (again, without nearly any real documentation) gray hair and lots of patience. I would have gladly also done some XML manipulation but the documentation was too bad.

The Ruby folks should really understand a few thing as absolute truths:
1. API documentation != documentation. The APIs alone rarely describe what you shall receive via the API.
2. In real life there are minimum requirements when building applications (such as SSL support). If they do not exist, the tools change instantly.
3. Bindings (ie. to pyGTK) never equal to a real solution because they have more moving parts (elevated risks involved), and it is not enough to point to the C API docs or similars (because people use Ruby for using RUBY, not C! They wan't to have nothing to do with the native libraries). They still require 100% complete real documentation! On top of that, they are too much of hassle because many platforms do not ship with them out of the box, or they aren't necessarily packaged.
4. Ruby needs a way to build GUIs. A Rubyish way. Modern way. For instance shoe. By default.

I think the libraries should be cleansed. You can throw 90% of the stuff away at first, and then add the missing important things. Then document. Until that is done, I and a few million others will keep using Java. It really sucks (worse is once more better) but it works.