Ruby 1.9—Right for You?

As is becoming a tradition, Matz announced the next major release of Ruby on Christmas day.

Let's start by thanking both him and the entire Ruby core team for the efforts to get us here.

So, should you go and put this new Ruby to work right now? Let's see:

The Upside

This release contains a boatload of new features. Mauricio Fernandez has an impressive list (soon to be updated).

• Performance: this new Ruby runs on the new YARV virtual machine. For most compute-intensive applications, you'll see significant speed improvements.

• Support for string encodings and transcoding. Every string in Ruby can now have an associated encoding (ASCII, UTF-8, SJIS, and so on). You can transcode the contents of a string (for example converting ISO-8859-1 to UTF-8).

• Integrated RubyGems and rake

• Cool new goodies such as Fibers

and so on and so on.

The Downside

• This is a development release, not a production release. It has known bugs, and there'll be more to come.

• It contains several incompatible changes (block parameters are now block-local, String is no longer Enumerable, "cat"[1] now returns "a", rather than 65)

• It is more rigorous that 1.8 when it comes to detecting invalid code. For example, 1.8 accepts /[^\x00-\xa0]/u, while 1.9 complains of invalid multibyte escapes

Because of this, and based on my experience working on the third edition of the PickAxe, a whole bunch of existing gems and other libraries are broken.

So, Should You Use It?

In production? Probably not yet. It isn't intended for production use, and there will be some rough edges.

For development? Maybe, but take note of some of the issues with gems and other libraries. If you rely on third party code, make sure it has been tested against 1.9.0 before taking the plunge. That goes for Rails users, too.

Now, if you're a library developer and gem maintainer, this is the perfect time to check out a copy of Ruby 1.9 and make sure your code is compatible. Over the coming months, more and more of your users will be basing their applications on 1.9. The future success of your gem requires compatibility.

For experimentation? Absolutely! The new features are wonderful. Not only do they make writing Ruby code even more enjoyable, they also open up whole new avenues to explore. How will fibers (both asymmetric and symmetric) affect they way we code? Let's all find out by playing with them.

My Recommendation

Download 1.9 (either as a tarball/zip file, or directly from the Subversion repository). Build it and install it, but not as your default Ruby. Instead, use the --prefix option to put it somewhere else (I store it under my home directory, so I don't need to be root).

$ autoconf
$ ./configure --prefix=/Users/dave/ruby19
$ make
$ make install

Then, I just add /Users/dave/ruby19/bin to my path, and I'm using my nicely sandboxed version of Ruby 1.9.

$ PATH=/Users/dave/ruby19/bin:$PATH
$ ruby -v 
ruby 1.9.0 (2007-12-26 revision 0) [i686-darwin8.11.1]

If I install gems with that version in my path, they get installed into the sandbox, not globally. If I use the sandboxed version of Ruby when building extension libraries with extconf.rb, those extensions install into the sandbox. But, if I suddenly have to look at a problem in production code that means I have to use Ruby 1.8, I simply fire up another shell with my original PATH, and it's as if Ruby 1.9 doesn't exist.

1.9 is the future of Ruby, and it's a future that will be mainstream very soon. Start playing with it now, so you'll be up to speed when Matz creates his first production release.

Comments

[Joon You]

Excellent post! I think creating a VM using Parallels or VMWare to play with 1.9 is another good option without taking any risk. Just my $.02.

[Dr Nic]

I created another user account, installed ruby19 locally and added it to the front of the path; then checked out copies of all my gems and tried to run their tests. First problem was with the rake command requiring a 1.8 library that's no longer in 1.9 (ftools).

The process of moving to 1.9 will take time as we iron out new dependencies, deprecations etc 1 by 1.

It'll be worth the effort though!

[Rick DeNatale]

Nic,

Assuming you are talking about yesterdays release of 1.9.0, Rake is now part of the distribution, so rather than using a gem version of Rake with 1.9 you should be using the 1.9 version of Rake.

Rubygems is also now part of the standard 1.9.0 distribution. The intent is for much if not all of the standard library to be repackaged as pre-installed gems, at least according to what's been said of late on ruby-core.

[M. Edward (Ed) Borasky]

What you describe is pretty much my plan with one exeception: I want to be able to use all the Ruby behavior/test driven development tools, and I want to be able to run benchmarks against multiple versions of Ruby. So I need a "master" Ruby, probably MRI, running RSpec, flog, heckle, ZenTest, etc., and multiple sandboxes, one for each "Ruby Under Test". This sort of thing is more or less trivial on Linux -- chroot is your friend, etc. But what about Windows? How do you do a "sandbox" on a Windows machine?

[dubek]

irb(main):001:0> RUBY_VERSION
=> "1.8.6"
irb(main):002:0> "cat"[1]
=> 97
irb(main):003:0> "cAt"[1]
=> 65

:-)

[Ach]

Hi Dave,
Thanks for informative post. I am a beginner Ruby experimenter and am going to read a solid book (preferably yours!) to learn about it. So which version do you recommend for jump start? Will I lost a lot if I read your current book?
-Thanks for help

[Dave Thomas]

Ach:

I think I'd recommend starting with the stable Ruby 1.8. In that case, the second edition of the PickAxe is the guide to take with you. If you get it from our site, you'll be able to upgrade to the third edition, which covers Ruby 1.9, for a relatively small amount.

Dave

[Ruby what?]

Is this another fad? Why don't you use Mod Perl?

[Ryan Allen]

Ah, integrated rake and rubygems, I think that's excellent! I wonder what's going to happen to all those other VM projects still working on 1.8?

[Luca]

Hi Dave,

Great post! Do you already debugged with ruby 1.9?
I tried to install ruby-debug gem, but it fails during the building. I also noticed a fatal error with the -r debug argument.

[Dave Thomas]

Luca:

The debugger hangs for me (on OSX). It's one of the things broken in the development release.

[Carl Bourne]

Great article - compiled and installed easily.

Only problem is the TextMate's RubyMate throws the following error:

RubyMate r8136 running Ruby r1.9.0 (/Users/cbourne/ruby19/bin/ruby)
>>> testversion.rb

:0:in `require': /Applications/TextMate.app/Contents/SharedSupport/Bundles/Ruby.tmbundle/Support/RubyMate/catch_exception.rb:13: invalid multibyte char (SyntaxError)
/Applications/TextMate.app/Contents/SharedSupport/Bundles/Ruby.tmbundle/Support/RubyMate/catch_exception.rb:13: invalid multibyte char
/Applications/TextMate.app/Contents/SharedSupport/Bundles/Ruby.tmbundle/Support/RubyMate/catch_exception.rb:13: syntax error, unexpected $end, expecting ')'
...ML e.message.sub(/`(\w+)'/, '‘\1’').sub(/ -- /, ' — ')...
...

Any suggestions on how to fix it?

[Andrew]

I prefer to use configure --program-suffix=19

This creates everything as normal but calls the binary "ruby19", irb19, ri19, etc

[Stefan Kroes]

I had had a lot of issues getting ruby 1.9 to work in this way and other simiilar ways. Finally I tried macports (google!) and that installed ruby 1.9 and all dependencies on both my macs without problems.

Install the package from the site
Add export PATH=/opt/local/bin:/opt/local/sbin:$PATH to your .profile in your home dir
Run: sudo port selfupdate (in the console)
Run: sudo port install ruby19 (in the console)
Wait quite a long time (like 20 minutes) and you are all done!

[John Griffiths]

As always you are a genius, I'll try this over the weekend and see if my blogging engine handles the new 1.9 release; would be pretty awesome if it did without a hitch ;-)

All the best, love the screencasts you did for pragmatic programmer.

[Luca Guidi]

Dave, I successfully installed ruby-debug on my macbook with multiruby: http://bit.ly/zMKdZ