Tomorrow is christmas. If everything goes according to plan Matz&co will deliver an (almost?) stable version of the nextgen Ruby interpreter, 1.9. We're getting a better language running on top of a faster interpreter. Just how big of an improvement will it be? The jury is still out although in my experience most applications will not see much more than a 50 - 100% improvement. Far from the fastest dynamic language on the planet, but hey, that is not (at all) the reason we all love Ruby.
I really like Ruby 1.9. I like the evolutionary approach, leaving the crazy (cool) experimenting to others, making major but responsible improvements in the areas where Ruby is the weakest right now: unicode support, performance, thread model. All good. All useful. All necessary. Sweet, +1 and thumbs up etc.
During the course of 2008 I have made several attempts at running my development environment on the Ruby 1.9 trunk. It has been quite painful. Trunk always compiles and installs flawlessly. Never had any problem there. Running two, three rubies has never been a problem either.
Now, when it comes to library code the situation is not as rosy. Actually it's a mess.
I can totally see why a mainstream RoR developer doing plain-jane fancy-pants 2.0-ish websites isn't overly interested in testing out Ruby development releases, but that doesn't hold for library code.
Why oh why aren't gem authors swarming all over their stuff, hard at work on getting ready for Ruby 1.9? I mean, wtf? What's up with people? I sometimes feel there are more projects with specific jRuby support than there are projects supporting Ruby 1.9.
A little list of incompatible gems:
Rails, Haml, Eventmachine, jRails, Mongrel, FasterCSV, RedCloth, libxml-ruby, utility_belt, rspec, rcov, wirble, git, ruby-debug, linecache, hpricot, ...
And the list goes on an on. Often times the fix is a one-liner, dead easy stuff. C extensions accessing struct members directly rather than through the macros. Code treating String instances as Array instances (which is a bad practice under 1.8 too btw). Passing Procs instead of Bindings when eval'ing (rspec, I'm looking at you).
(of course, any gem depending on any of the above also break, so e.g. newgem breaks on RedCloth making me wonder why I need a text2html lib to use a gem building tool. Sigh.)
Most of the times it is so easy to fix the code that I'm pretty sure the author never even bothered to run his/her stuff under Ruby 1.9.
This, to me, is hard to accept.
Most of us make a pretty decent living from Ruby. It's an open source project and as far as OSS goes, we often brag about how nice&awesome the community is. The gem producing/forking subset of ruby programmers is unusually large and I clearly remember the "WOW!"-feeling I had the first time I realized how the readability of Ruby made it easy to actually understand and improve "advanced" library code. We have fantastic tools at our disposal. Most gems are fairly well tested and many of them are forkable with two mouseclicks from github.
Will people please, please, please make their stuff work under Ruby 1.9? Like yesterday? Please?
Like it or not, this thing being released tomorrow is the next Ruby. It is the tool of your trade. You need it. You need your tools to work with it. You wrote them, you blogged about them, your clients depend upon them.
Nice article David, but you may have one fact wrong, FasterCSV does not need to be ported because the former core CSV module is now FasterCSV http://blog.grayproductions.net/articles/gettin... :)