Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

What do we need to get on Ruby 1.9?

A year ago, I was very skeptical of Ruby 1.9. There were a lot of changes in it, and it seemed like it was going to be a mammoth job to get things running on it. The benefits did not seem to outweigh the costs of switching, especially since Ruby 1.9 was not yet adequately stable to justify the big switch.

At this point, however, it seems as though Ruby 1.9 has stabilized (with 1.9.2 on the horizon), and there are some benefits that seem to obviously justify a switch (such as fast, integrated I18n, better performance in general, blocks that can have default arguments and take blocks, etc.).

Perhaps more importantly though, Ruby’s language implementors have shifted their focus to Ruby 1.9. It has become increasingly difficult to get enhancements in Ruby 1.8, because it is no longer trunk Ruby. Getting community momentum behind Ruby 1.9 would enable us to make productive suggestions to Matz and the other language implementors. Instead, we seem to get a new monthly patch fixing Ruby 1.8.

So my question is: what do we as a community need to shift momentum to 1.9. I’m don’t want a generic answer, like “we need to feel good about it”. I’m asking you what is stopping you today from using Ruby 1.9 for your next project. Is there a library that doesn’t work? Is there a new language feature that causes so much disruption to your existing programming patterns to make a switch untenable?

I suspect that we are all just comfortable in Ruby 1.8, but would actually be mostly fine upgrading to Ruby 1.9. I also suspect that there are small issues I’m not personally aware of, but which have blocked some of you from upgrading. Rails 2.3 and 3.0 (edge) work fine on Ruby 1.9, and I’d like to see what we can do to make Ruby 1.9 a good recommended option for new projects.

Thoughts?

92 Responses to “What do we need to get on Ruby 1.9?”

The reason IMHO is the “legacy code”. No one is willing to pay time to fix issues that might come up with the move. To make it worse, many projects don’t have associated test suites, which makes it harder to do the move.
Some ppl also don’t want to take the hassle of trying it, complaining about many gems and plugins that don’t work well with Ruby 1.9. May be we should do something about it, like hackfest to maintain those gems and plugings.

I see alot of people asking for the database drivers to be updated to support Ruby 1.9. The DataObjects (DO) database drivers have had 1.9 support for a while. They’re also very fast, are non-blocking, and recently added UTF-8 support for 1.8 and 1.9. The API is uniform between all the drivers and there is an active community supporting it.

However for DO to work with ActiveRecord some help is needed to port the AR adapters over. If anyone is interested in helping with this feel free to ping me (dkubb) or the DO maintainer (dbussink) on IRC/github.

We would definitely try to switch to 1.9. Last time when I tried, even merb was not ready but it was last year.

Just for sake of curiosity , what this blog run? 1.9 or 1.8

I’ve posted a partial response as “Mechanizing the Path to Ruby 1.9″ (http://www.cfcl.com/rdm/weblog/archives/001674.html). The gist of my posting is that we should use mechanized tools to help us assess and track the 1.9 compatibility of the Ruby infrastructure (eg, gems, plugins, tools).

I started using Ruby 1.9 w/ Rails 2.3.2 on my latest project and it definitely has not been seemless, though I can’t say it’s that bad either. I’ve already come to enjoy some 1.9-specific features, such as ordered hashes. The problems I’ve had were solved by explicitly specifying UTF-8 encoding on pages that used it. I also had problems with UTF-8 strings in the params, though a quick Google search found this page and James Healy’s solution in one of the comment’s above worked just fine.

I support the core dev team’s position that we need a more generic solution, but at the same time UTF-8 seems to be a good default, and should work out of the box. I’ll also second comments that we should accept UTF-8-specific patches on the interim until a more general solution is implemented. Frankly, it would be the lesser of two evils.

The developers, especially anyone working on gems, should install Ruby 1.9 as the ‘main ruby’ (/usr/bin/ruby) on their system. Aka, make 1.9 the default choice for deploying rails app, etc. From there, take the boyscout approach: find something broken? Fix it a piece at a time.

I don’t know how feasible this is, but having some help from the test frameworks to execute against 1.8.x and 1.9.x would also be helpful.

REE and Jruby are both compatible only for ruby1.8 .
The speeds of Rails run on r1.8 or r1.9 are of little difference. Encoding type is also a problem.

If r1.9 provides bytes code, the switch will become very soon.

One Click Ruby Installer for Windows! Notice that Windows is still dominant OS. In my company some have to use Windows XP / Vista on development machines. Because of IE6, the browser used by 70% of our corporate clients, MS Office, etc.

BTW many people wonder why MySQL became much more popular than Postgresql. Now tell me since when Postgresql has Windows native port?

As for me, I want to know, what is going to be done around bug with LARGE unicode problems in 1.9 (bug with UTF8 output in erb)

We’re going to fall into the same hell with string encoding, as in Python, when programmer MUST remember on EVERY line about encodings.

For me, the new features in 1.9 are nice-to-haves rather than must-haves, and so don’t justify the potential costs of upgrading. What could change my mind would be more war stories from people who have made the leap, particularly describing bloody but successful campaigns. Also, calls-to-arms like this post will certainly encourage me to try 1.9 out on personal projects, even if I don’t feel I can risk it for client work yet.

Last time I was using ruby 1.9.1 ruby-debug-base and ruby-debug-ide are not available to ruby 1.9.1 yet. At times, programming without access to a debugger can lead to wasted time. The debug gems are the last gems I am waiting for.

I attended RubyKaigi 2009. Thanks for coming to Japan and speaking a session.

To return to our subject, there is NO stopping me from using 1.9 because I’m not a aggressive rails/merb user. And if I(we) encounter not working some libraries on 1.9, I(we) can make it work with writing and sending a patch: that’s open source. Actually I send a patch for an other library(not a web framework).

BTW, JRuby can work 1.9 mode with command line option “–1.9″.

We just need to get those gems ported, and that can be easily done with some coordination. Long post on the subject at my blog.

@Rich Morin
I like the way you think but I don’t think we need that much automation. If there is a clear and straightforward process, developers will hand port the gems/plugins they need and we’ll have a critical mass in no time.

I’ve been working on ruby-debug, and I think I’m almost there, except for maybe catchpoints. That might require changes to core ruby, or a totally different approach on my part.

If you want to see what I’ve got so far, click on my name.

We’ve just upgraded to RoR 2.3.3 on Ruby 1.9.1. The situation is really annoying – Rack is completely broken for few months. In RoR 2.3.2 it was possible to keep frozen, modified version of Rack in application, now it’s not. RoR loads the broken 1.0.0 version. I can’t release my own gem, because nothing wants to work with gem “qoobaa-rack” everything wants “rack”, the only way is to modify gem and store it somewhere (lot of work on deployment). Webrat is also totally broken. The main problem is: even if I make a patch, I have to wait 3-4 months for “official” release that includes it. HOW MUCH WORK DOES IT COST, TO RELEASE THE e.g. 1.0.0.1 FOR RUBY 1.9.1 GUYS? I’m really irritated and I think I’m giving up.

I have a lot of apps in production. Some of them are quite old, some I inherited. Most have a good test suite, but a few have zero tests (the ones I inherited). Most of the apps are in a legacy state, meaning they are not in active development and the owners are unwilling to pay for work to be done on them that provides no additional benefit to them. Those apps will likely never be ported so I will always have to support 1.8.

For me it comes down to motivation. As of yet, I have found no compelling reason to port any app to 1.9. The time investment seems to be significant (or at least unknown) and there is little or no return on that investment. Give me a reason that makes sense for my business and I’ll move.

For me it’s just Chef, which is dependent on merb and thus only works on 1.8.

Do you happen to know anybody that’s well versed on the merb internals Yehuda? ;)

About 7 months ago, I made the effort to make one of my projects compatible with 1.9. What I ran into were only small issues, such as instance_variables returning symbols instead of strings, Observable using a hash instead of an array, Array#to_s returning “[]” instead of “”, and having to use require “digest/md5″ instead of just require “md5″. These were pretty simple things to deal with, and once I did my application used less than half the memory it used under 1.8.7 (and parts of it were faster, too). That more than made up for the time invested in fixing the small issues above.

I would imagine other people are having the same experience: you install 1.9, try to run your application, and it fails because of some small changes. At that point, it is often easier to say, “Well, it works under 1.8 so I’m not going to worry about it until I have to.”

How hard would it be to patch Rubygems to allow substitutions? Something like Gem.substitute “somegem” => “someguy-somegem” which would affect require and any dependency actions. Browsing the Gem namespace does not make immediately obvious any chokepoint for name resolution.

One thing the Python community has is a more clear migration path, both in terms of documentation guiding what to do and libraries to help out the transition, such as “import from future”. I was wondering if someone didn’t already start a “require ‘future’” feature to help out. Mechanizing the migration would also be great though I am pretty sure there are big caveats that will get in the way (such as less trivial syntax changes).

I need ruby-debug-ide to work. I’ve fallen in love with Netbeans for my Ruby development; in order to maintain my productivity, I want to continue to use Netbeans.

I second Sean, ruby-debug or another easy to use debugger is a must. Even more so as gems/plugins broken on 1.9 which come with no test suite will seem to be the biggest blocker right now and definitely need debugging (and tests :-)

@Jack Dempsey – We’ve updated the Ruby Switcher to work with the latest version of Ruby 1.9 and various other Ruby VMs.

http://blog.thinkrelevance.com/2009/7/29/ruby-switcher-working-with-multiple-ruby-versions-has-never-been-this-easy

The Ruby Switcher is a super-lightweight tool for switching between Ruby versions. You can easily experiment with Ruby 1.9 to try out a gem or two, and if you run into issues, you can safely retreat back to 1.8.x (after you report the Ruby 1.9 problems you encountered to the gem maintainers, of course ;-).

It gives you shell-specific Ruby versions. So while one terminal window is testing out a gem or app in Ruby 1.9, you can have another terminal performing the same tests with Ruby 1.8.7, (or JRuby, or Ruby 1.8.6, or REE, or Leopard Ruby, …).

I have to agree with others – the missing debug functionality is a showstopper for me too.

ruby-debug for Ruby 1.9 is done and functions pretty much the same as the Ruby 1.8 version. Two main differences at this point: in 1.9, sometimes stack frames get combined when they shouldn’t; and sometimes you can’t set breakpoints where you should be able to.

See: http://github.com/mark-moseley

I’ll look at ruby-debug-ide now.

ruby-debug-ide is working now; new gem is at http://cloud.github.com/downloads/mark-moseley/ruby-debug/ruby-debug-ide-0.4.7.gem

copy to local dir, from that dir, install with:
gem install ruby-debug-ide -l –ignore-dependencies

I put up a gist on how to install Mark’s ruby-debug in OSX assuming you have the ruby19 port installed: http://gist.github.com/159524

I may be coming to this a little late but I found this out over the weekend. I couldn’t seem to get rspec/autospec to work with rails 2.3.2 and ruby 1.9. Dropping down to ruby 1.8 made things work, though. That’s what’s keeping me from jumping over to 1.9.

An encoding aware mysql adapter is holding me back, currently.

I’ve tried kwatch-mysql-ruby, which works fine with 1.9, but only returns ASCII encoded strings, no matter what you set in the db or in database.yml.

And I’ve tried tmtm-ruby-mysql, which is encoding aware, but doesn’t work with Rails 2.3.3.

Maybe it is best to make mysql_adapter.rb work with tmtm-ruby-mysql, which seems to be the most promising solution from my point of view. But anything would be great to get going with Rails 2.3, MySQL and UTF8.

I really, really want to get up-and-running with 1.9. This is what’s stopping me at the moment: I have a lot of legacy projects to deal with, all my libraries work with 1.8, I haven’t found a definitive guide as to what to prepare and expect for working in 1.9, and all our production servers run 1.8.

Personally I have not changed because of ONE reason:

The Encoding stuff.

Fixing this would require fixing all my german umlauts in my scripts, and with ruby 1.8x it simply works.

Perhaps one day I spend more time on it, but right now I really dont have a reason to switch to 1.9 at all. 1.8x works wonderfully and I could probably live with it for years to come.

The encoding really screams for problems (for me, probably not for others, but that is how *I* feel, and I have been using ruby since 5 years so it is pretty annoying …)

I’ve been damn near exclusively on Ruby 1.9 for, uh, a very long time. Maybe early 2008? I can’t really remember exactly.

I never really ran into many problems at all in all that time (but then again, I don’t develop in Rails, nor do I use any SQL databases, so all the problems people have been running into with this old tech are things I’d never encounter).

While I did consider that to be the bleeding edge a year ago, it’s patently ridiculous for this to still be any sort of discussion, as we’re moving into 1.9.2 with 1.9.1 having been completely stable and usable.

As of a month or two, everything new I release is 1.9+ only; I am no longer providing any sort of 1.8 support in any of my projects or gems (less because of any difficulty with providing such support, and more because I want to do my small part in helping the community *finally* move forward—maybe somebody wanting to use one of my libraries will finally realize it’s 1.9–time when they see the README from said project, if I’m lucky). The time has come and passed for everybody to quit asking “When do you think it will be ready?” and realize it is and has been.

There is only one thing preventing me to start using Ruby 1.9:

* Encoding problems

Beside of that all my applications works under Ruby 1.9 and all the gems are working. It’s sad because I would migrate today if it wasn’t for the encoding issues.

FWIW I successfully installed ruby-debug for 1.9 on my macbook http://bit.ly/zMKdZ
This was my big issue too.

what we need is a ruby repository that only have gems for 1.9.x no backward compatible with the old 1.8.

In this repository:
– only allow code that run fine on ruby 1.9.x
– remove any backward compatibility with 1.8.x (it make more difficult to maintain and affect performance).

procedure :

1.- created a way to id gems that are ready for ruby 1.9 (maybe using http://isitruby19.com/ ).

2.- move to a test sandbox for compatibility testing for ruby 1.9.x

3.- if pass the test , remove any code that make the gem compatible with other ruby different to 1.9.x.

4. do the compatibility test again for 1.9.x.

5. put it at unstable gem for 1.9.x

6. allow people using the unstable repository to test and grade it,etc.

7. if pass , move it to stable.

The problem for moving to 1.9 is that people wan to move to it but keeping compatibility with the old 1.8. the solution is to separate the repository for 1.8 and 1.9. keeping both together is a mess , people no have idea what work for 1.9 or no and make the code more complex and difficult to maintain and hurt performance.

note: this is my personal opinion… I’m not a expert .

sincerely
Angel Rodriguez

Chef is the one thing I still need on 1.9. Any chance of a progress report on Chef?

For those with encoding issues, please read:

http://gnuu.org/2009/11/02/ruby-1-9-encoding-issues-again/

http://gnuu.org/2009/11/06/ruby19-rails-mysql-utf8/

Most encoding issues are easily solvable but unfortunately scare off developers too quickly.

Here is my experience with starting a ruby 1.9 + rails 2.3.5 project recently. I had problems with rubygems, which couldn’t find my rails gems. Some problems with the encodings, as the people before me mentioned and some compatibility issues with mechanize.

http://www.valentinmihov.com/posts/rails_2_3_5_with_ruby_1_9_1_dev_notes.markdown

You will find also how I handled the problems. Unfortunately I am not sure that most developers will take the time to dig into these issues. I hope that it is just a matter of time and polishing to make the ruby 1.9 transition.

I believe that also the rails framework should communicate the solutions for the common problems. For example it took me too much time to figure out that I should set the LANG variable in order to change the default encoding in ruby (at first place I didn’t know that the default encoding was the issue).

On the Rails front…. This is a major issue….

http://oldmoe.wordpress.com/2009/04/18/objectextend-leaks-memory-on-ruby-1-9-1/

I stupidly migrated a site’s code to 1.9.1 in production, and this is causing me a major headache. I’m sort of getting round this by semi automatically restarting my thin processes periodically. The same code base does not leak under 1.8.7 (well the 1.9.1 code has some modifications due to some changes needed for 1.9.1 compatibility, but other than that it’s the same code).

This is a killer for Rails users who use the :extend => Module in their associations (which I normally always do)

If you know this is being worked on or has been fixed in trunk (Still seems to exist in trunk from what I see), please let me know, I would be so grateful!

I also agree that memory/GC profiling is a must as well. I’ve kind of relied on ps aux / top for which is not great. Any production site needs some way to stress test CPU *AND* mem usage imo, so again this is a priority.

I think the whole ruby/python team is MAD.

They didn’t think of the language features 2-3 years ago and are now making changes that BREAK basic code.
Is it necessary — in most cases NO .. some of the changes are because they can just make them and let rest of the world follow . like the idea of removing “.” from automatically loading the modules. Security Risk my foot – they add just added “require_relative” .. self contradictory to start with.

Or removing string functions — if the core team in 2000 couldn’t think of internationalization properly and is tweaking the base class to the point of BREAKING working code — I have ZERO confidence that what I fix in 1.9.3 will not BREAK TOTALLY in 2.0 ..

You guys are smart .. but are evil — you don’t create products .. just “nice features” in language —
and Yehuda don’t even get me started on the rails fiasco — I have spent MORE time (at least 1x .. on the install issues than on writing code .. .!!!

Leave a Reply

Archives

Categories

Meta