How Many Rubies Does the Future Hold?

Posted by Obie Fernandez on Oct 25, 2006

Sections

Process & Practices,

Development

Topics

Dynamic Languages ,

Ruby ,

Change

Tags

Community ,

Language Features ,

Innovations ,

Commercial Offerings

Nick Sieger, winner of the award for best note-taking at RubyConf 2006, gives us the best summary of Ruby's future, in terms of platforms: "There are now at least 8 active implementations of Ruby (Ruby, Yarv, JRuby, Cardinal, Rubinius, MetaRuby, Ruby.NET, IronRuby), and two interop bridges (RubyCLR and RubyCocoa)! The biggest news was that there are plans to revive the Ruby testing project (formerly the Rubicon) and share as many tests as possible among the implementations."

As covered by Pat Eyler and Tim Bray, this year's RubyConf featured an implementor's summit, where leaders of all of the projects mentioned above got together to discuss Ruby's future (and make decisions about it). In Tim's words, "with all these alternate-implemenation projects under way, I’d say Ruby’s bets are pretty well hedged."

However, not everyone was quite so optimistic. In The Impending Ruby Fracture, blogger David Pollack captures the sense of anxiety that at least some members of the community feel about the future of Ruby.

So, there are 4 Ruby runtimes in various states of being built.  They all (except for 1.9) will be fully compatible with 1.8 and they will all run Rails just fine.  So, what's going to happen when some enterprise customer wants interfaces or some other optional typing mechanism (Matz is dead-set against any form of non-duck-typing in Ruby.)  What happens when some enterprise customer wants to close open classes from modification from just any other class (oh, you mean a library that we did a GEM update that just re-wrote our code to send all strings that match /[0-9]{3}-[0-9]{2}-[0-9]{4}/ to some server hosted in Russia?!?)  What happens is the JRuby team integrates Java's sandbox model into Ruby.  It means that the .Net guys do their security magic.  Who knows what Evan will do.  It's unclear what Matz will do.  Maybe the 37 Signals guys say, "this is a real problem and something has to be done."  Maybe Matz listens or maybe the Rails guys just team up with another vendor that provides more enterprisey, more predictable support for the runtime.

On that last note, he may have gone too far by saying the following:

Sooner or later, the Rails guys will realize they're the dog and start finding a tail that's easier to wag for the customers with lots of money.  That will likely lead to fractured Ruby syntax and fractured Ruby dialects.

Ouch! Given the words and behavior of the Rails team to-date, the prediction that they will ultimately be the driving force behind the fragmenting of the community is both controversial and unsubstantiated. I asked David Heinemeir (creator of Ruby on Rails) to comment on the article for InfoQ and he responded somewhat angrily:

What he's talking about is called a fork. It can be done to any open source programming language. His is a cookie-cutter argument that's not particular to Ruby in any form. Furthermore the people LEAST interested in Ruby 1.9 is the Rails core guys. In a lot of ways, I couldn't care less. Ruby 1.8 is more than good enough. There's no urgent need for Ruby 1.9. The ability to adorn Ruby 1.8 with ActiveSupport is pretty much all we need. Even if Ruby 1.9 didn't materialize within the next three years, it'd be highly unlikely that I'd give a damn.

In the Wikipedia article about forking, the Jargon File is quoted as saying:

"Forking is considered a Bad Thing — not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs/XEmacs split, the fissionings of the 386BSD group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore."

Charles Nutter, one of the leads of the JRuby project also chimed in to address the fears of a fork from the JRuby perspective:

I am not interested in creating an incompatible version of Ruby, and to that end we have taken great pains to make sure even quirky Ruby behavior continues to work correctly. Ruby's quirks are not eggregious enough to drive day-to-day developers away, so though the temptation may exist to "fix" things, such a change would cause fragmentation. I would like JRuby to be not only a new language option for Java developers, but also a new VM option for Ruby developers. Only by staying true to Matz's vision can we make that happen for both worlds.

Perhaps the longest rebuttal (so far) of David's concerns was posted this afternoon by Ed Borasky, who challenges the idea that Ruby will fracture anytime soon:

I think Ruby the language and its community form what is known as a complex adaptive system. Like a person, complex adaptive systems often are born, grow, mature, age and die. I'm not sure where Ruby and the Ruby community are in this spectrum -- perhaps the Rails phenomenon marks "late adolescence". But "fracture"? I don't think so.

Ed backs up his rebuttal with a series of comments, including a reminder about the way that enterprise vendors treat languages, in a nutshell "It's all about the money":

Enterprises move slowly. And while the support for the .NET and JVM implementations by Microsoft and Sun respectively means they won't die on the vine, it doesn't necessarily mean that they will succeed. There are an awful lot of good applications out there in the web space that will never be rewritten in Rails or Ruby. Bluntly put, business is about money. If jRuby doesn't make money for Sun, it will die. If the Ruby/CLR bridge or the native Ruby .NET implementation from Australia don't make money for Microsoft, they will die.

Will any vendor be able to make large profits investing in Ruby progress? Inversely, is it just a matter of time before the "forces of evil" rumored to be stirring within Microsoft fork Ruby, just to try to destroy it, presumably out of spite? Can John Lam keep it from happening from within Microsoft? With so many questions hanging and so many directions being pursued, the future for Ruby certainly looks interesting, and potentially very dramatic.

1. Back to top

   Thanks for the plug, etc.

   by M. Edward (Ed) Borasky

   'Inversely, is it just a matter of time before the "forces of evil" rumored to be stirring within Microsoft fork Ruby, just to try to destroy it, presumably out of spite? Can John Lam keep it from happening from within Microsoft?'
   
   Well ... every usable programming language I've ever dealt with has co-evolved within a community of vendors, users and standards organizations and committees. I don't expect Ruby to be any different. I expect vendors like Sun and Microsoft (and IBM???) to come up with "extended subsets". I expect computer scientists to argue about syntax and semantics. I expect people like myself to beg for things that will make my life easier in the language, and I expect the vendors to tell me, "come back when you're ready to spend some serious cash to fund the developers."
   
   It's all C under the hood anyway. Which is really too bad -- it should have been Forth under the hood. :-)

   Reply

2. Back to top

   Re: Thanks for the plug, etc.

   by Pat Eyler

   "It's all C under the hood anyway. Which is really too bad -- it should have been Forth under the hood. :-)"
   
   Well, it still could be ... having forthRuby as the 9th (or whatever) implementation might be a good thing. Are you volunteering to lead the project? ;^)

   Reply

3. Back to top

   Re: Thanks for the plug, etc.

   by M. Edward (Ed) Borasky

   Not if Carbone is alive and well. Then again, Koichi seems to be building a stack machine with direct threaded code. Don't look now, but that's Forth/vmgen. :)

   Reply

• Older >