Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; he spends his daytime hours at the startup he founded, Tilde Inc.. Yehuda is co-author of best-selling jQuery in Action and Rails 3 in Action. He spends most of his time hacking on open source—his main projects, like Thor, Handlebars and Janus—or traveling the world doing evangelism work. He can be found on Twitter as @wycats and on Github.

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 thing that road blocked me when I was trying out ruby 1.9 was that ruby-debug didn’t work.
I’m not sure if it does now or there are some alternatives, they weren’t easily googleable at the time.

Interestingly, the biggest blocker for us is that Engine Yard doesn’t support it. (Based on http://www.engineyard.com/technology)

Once they do, I expect we’ll spend some time digging into if there are any specific issues holding us back, but it’s not worth doing that if we couldn’t deploy it. So it might be a bit of a chicken/egg problem there, if EY is waiting for increased demand before prioritizing support.

Cheers,

-Bryan

I remember everyone talking about the main problem with Ruby was it’s speed, which in turn caused the “Rails doesn’t scale” meme. If, however, Ruby’s speed was a really big issue in Rails applications, everyone _would_ have switched to 1.9. The fact that people didn’t landslide to 1.9 tells us something about Ruby 1.8′s speed issues. It can’t be that big of a problem after all! Moving to 1.9 probably wouldn’t fix that many of the scaling issues.

I think the main problem is that Rails 2.3 and edge _doesn’t_ work on 3.0. I had to install someone’s fork of the sqlite3 gem to have it spit out UTF-8. I had to do this http://github.com/augustl/kii/blob/master/app/controllers/application_controller.rb#L5 – in order to allow none-ASCII characters in URLs (wikipedia does this, e.g. http://en.wikipedia.org/wiki/Øystein_Sunde). I had to add `# encoding utf-8` to a few files. In many cases, you can’t just swap to 1.9 and have lunch, since 1.9 doesn’t allow people to be careless about their encoding. Until someone creates a good, comprehensive list of errors and solutions to 1.9 encoding issues in Rails, people won’t switch, because people won’t know how to fix these errors, I think.

My take: gems and extensions going form DB adapters like MySQL and sqlite3
(which I worked the past week on getting them running)

In my environment, I’m still not confident with ruby own tests due stalled and segfaults, but that is another subject.

There are others including myself which uses instance_eval and the lookup rules for it has changed, so workarounds needs to be put in place.

As Gregory Brown suggested once: create your project for 1.9 and then retrofit support for 1.8, is going to be more easy than the opposite.

I test and work with both 1.8 and 1.9 versions, so far, so good, but for production still use 1.8.6.

As someone who uses Ruby Enterprise Edition (with Passenger), I’d need to see a Ruby 1.9 implementation of it before switching.

Correction: I meant to say “_doesn’t_ work on 1.9″, the ruby version, not “_doesn’t_ work on 3.0″, the rails version.

I think it’s also partly about support from hosting providers and vendors. I bet if I called EY today about deploying a Ruby 1.9 application I would be told that I would fall outside of official support… that says enough on its own when a lot of businesses chose which Ruby they target.

I can’t speak for everyone, but the reason I haven’t officially switched is because I don’t churn out a new project every month. I have a few large projects that I maintain. Everything is working great, my clients are happy, and the applications are all stable. Why fix what isn’t broken? It’s not worth the headache, even a small one. I have a pretty comprehensive test suite for my apps, but I have a hard time believing the switch to 1.9 will be 100% problem free. I feel like my time would be better spent on other things, such as new features that add value to our products or bring in more money. I even feel like time away from the computer would be a better use of my time. On my next new project I definitely start with 1.9.

I’m waiting for better packaging on win32 for ruby 1.9. Minor thing and the binary builds for 1.9 where you have to assemble all the correct libraries on hand works fine, just annoying.

Some libraries and plugins I use don’t work with 1.9.

Can’t migrate till they do.

Some like SOAP4R might never be made to work with 1.9.

I have to agree with Mark. As someone who spends a great deal of time submitting patches attempting to fix 1.9 incompatibility, having ruby-debug work on 1.9 and/or other debugging tools would be a great help.

Rails 2.3 and 3.0 (edge) work *almost* fine on Ruby 1.9.

2 months ago I was bitten by ActiveResource bug #1272 (still not committed), while doing presentation on REST in Rails using my friend’s computer, who decided to switch to Ruby 1.9 and didn’t have 1.8 version installed at all.

Tests don’t work out of the box – you have to manually install test-unit gem.

Installing db gems is also not that easy as on 1.8 (at least it wasn’t last time I checked) – i.e. simple ‘gem install mysql’ doesn’t work on Ruby 1.9.

For the me, what annoys me the most if the fact that ruby-debug doesn’t run on 1.9. And I guess that other tools aren’t ported over yet.

If big names like EY and others were pushing 1.9, I’m sure the adoption rate would be greater. Unfortunately it’s not the case and I heard SnowLeopard will ship with 1.8.7 so people won’t have be forced to upgrade.

- Matt

We are using REE on our production servers. When we will have stable REE 1.9 (or any other stable production ready Ruby implementation) then we will be happy to use Ruby 1.9.

I second August’s comments.

The biggest blocker to running my rails apps on 1.9 is encoding issues. Most of the gems I use have been patched to avoid obvious encoding incompatibilities, but the 3 areas that still need work are: params handed to rails by Rack (as August mentions), erb templates and strings coming from database drivers (or ActiveRecord).

params, model attributes from the MySQL and erb templates all get marked as ASCII-8BIT if they contain bytes > 0x7F and cause exceptions when you try to mix them with strings marked as UTF-8.

I believe there’s a fix for the erb issue in edge Rails at the moment and a before filter can be used beat params into submission. That leaves model attributes. There’s a question about where the best place to place a solution – the DB driver or AR? I have a patch at https://rails.lighthouseapp.com/projects/8994/tickets/2476-ascii-8bit-encoding-of-query-results-in-rails-232-and-ruby-191 that treats the encoding as a type casting step, but I’m still in two minds about how appropriate this is.

@August – I’ve experimented with code like the following gist to santise the params hash in my Rails apps. It needs to be recursive if you want to fix strings submitted by forms, etc.

http://gist.github.com/149473

I’ve been running on 1.9 for months, and it’s sad to see the rest of the so-called community ignore it and continue to live in the 1.8.x sphere, since there’s little future there as far as matz et all is concerned.

Sure, there’s has been a few bumps in the road, such as having to *gasp* patch and update libraries along the way. The biggest problem is that everyone just sits on the arse waiting for someone else to do the job. It doesn’t take much effort, but it does take a little bit. Talking about it won’t make it happen; switching one or more projects today and take the dive is the only way to move forwards.

Main show-stopper for 1.9 as platform for RoR apps is database adapters encoding problems. As mentioned above, comprehensive list of possible encoding related errors/problems and their solutions and fixing other db adapters than sqlite and mysql would be great help.

Happy to see you write positively about Ruby 1.9. I think there are no more arguments to stay on 1.8. I switched to 1.9 some months ago and it was no fun, because some vital gems did not support it. Now things look different. Now everything you need works on 1.9. And if it doesn’t, you can easily make your mark on popular OSS projects and fix it. The language enhancements in 1.9 make sense and are fun to work with. Let’s not act retarded and switch to 1.9. It’s time.

I’d love to use 1.9 and particularly for it’s speed, but heroku doesn’t support it either. I get indifference when I ask others about benefits of using 1.9.

As a hosting company, we’re currently looking for a way to run Ruby 1.8 and 1.9 nicely alongside each other on one single server within our current platform (Plesk + Apache + Passenger). But we’re not really pusing hard on this, simply because there is no demand from the market.

As Rails developer, the uncertainty if things will work with 1.9 keeps me on 1.8. But I see many positive blog posts about running Rails on 1.9, so I should really try it out sometime. I just don’t really require the new language features at the moment and for demanding applications I use JRuby (which is on it’s way to 1.9 compatibility, too).

@malcontent which other gems and plugins? I’m trying to determine the actual specifics of what is needed here :)

I’ve just finished porting a rails 1.2.6 site to rails 2.3 running under ruby 1.9. I’d just like to say that overall it wasn’t that much of a hassle.

Most of the gems we use had no trouble running under ruby 1.9 or I could get my hands on a ruby 1.9 version of them. Generally plugins weren’t an issue either. This isn’t a huge app but it’s not tiny either (about 40~ models, 30~controllers).

The major issue I found and this is where I think that a lot of effort should be spent (apart from updating your gems to be ruby 1.9 compliant) is adapting exidting software to be encoding aware (ruby 1.9 string character encoding).

This issue alone could have been a major show stopper for us as neither the active record adaptors nor the actual db bindings (mysql in our case but the issue exists for most cases) are encoding aware. i.e. Currently rails 2.3 ignores the character encoding the db is in and returns ruby 1.9 strings as us-ascii.

As I mentioned thanks to the fact that people have been able to patch AR mysql adapter (there’s also a fork of the mysql bindings for ruby) to basically hack in fixed support for utf-8 we’ve been able to side-step this issue. Note the db is not the only place that isn’t encoding aware but luckily I’ve found patches for most issues.

However, these patches are mostly hacks. i.e. They provide support for only utf-8 which is why they haven’t been adopted by rails core who argue for a more generic approach to allow support for any encoding. Personally I think that they should accept these patches (perhaps with some slight modifications) on an interim basis (to be supplanted by a more generic solution later on) as utf-8 will satisfy the great majority of rails users. Otherwise you can’t really say rails 2.3 is ruby 1.9 ready if it isn’t aware of at least the most generic encoding ruby 1.9 provides.

The other issue which though not major is certainly a big pain point for me is that ruby-debug still doesn’t have a ruby 1.9 version ready (I believe the actual issue is with the linecache gem). Could someone please get on to this. I almost feel naked without it.

Again, in our case we don’t mind having a patched rails for now (we only upgrade the stack very rarely), so overall I’d say the process was painless and the site is now happily running under passenger 2.2.4. NOTE: Not in production yet!

Regards,

Saimon

When starting a new project I *always* start out with r19 to see what happens. I usually timebox it to one full workday, at the end of which I decide weather it’s worth to continue or not. So far I’ve been able to make most projects run under 1.9 but it has always implied using non-standard versions of gems and libraries. This, to me, is a show stopper for using 1.9 in production. This in turn implies having to maintain double versions (1.8/1.9) of the code base. As 1.9 often requires trunk versions of gems and libs, often enough with ad-hoc hacks I made, I end up with code that isn’t backwards compatible with 1.8, so I can’t vendorize them…

The end result is that I end up leaving 1.9 compatibility unmaintained.

All in all I think things *are* slowly improving, to the point I’m prepared to suggest clients we go 1.9 for greenfield development.

Great to see some attention to this subject! :)

Beyond the specifics, I think there is also a lot of ignorance about Ruby 1.9, especially because it’s been a bit of a moving target in the past, and most Ruby programmers have their day-to-day to worry about before keeping up with language design issues that can seem fairly abstract.

It would be nice if somebody out there could maintain one page that simply and frankly summarized the state of Ruby, addressing questions such as:

* What do I get for moving to Ruby 1.9?
* Will there be any backwards-compatibility issues in moving my old code to Ruby 1.9?
* What problems are people seeing with Ruby 1.9?
* How good is library/framework support for Ruby 1.9?
* What do all these Ruby version numbers mean anyway?

If we actually want the whole community to make this move, I think more needs to be done from a communications/education perspective. That’s an *if*, though. I’m actually speaking as somebody who continues to be, if not skeptical of Ruby 1.9, at least a bit curmudgeonly about it.

I have been using ruby 1.9 for development on a few of my personal projects, but I consistently run into little things that make me switch back to ruby 1.8 (till I can get a patch together for the problem) and then back to ruby 1.9. Ruby 1.8′s ParseTree gem can’t work in ruby 1.9 (I think) and I have not seen any attempts to get a good working replacement. Its an issue for a few gems that depend on it, but in some cases you can do without, like in Merb it added merb-action-args and in DataMappaer, dm-sweatshop unique requires ParseTree. That is probably the biggest road block for me.

I have been using Rails 2.3.2 with DataMapper pretty successfully in ruby 1.9, with only dm-sweatshop not working 100% correctly.

Also, if I am not mistaken, regarding REE, didn’t all the REE changes get put into ruby 1.9? If I am not mistaken, I know at least the copy-on-write changes where.

Sorry, I should look things up before I speak. Nope, ruby 1.9.1 is still not copy-on-write enabled, so it looks like there is still a reason to have a REE v1.9.1.

It may sound silly, but if Apple added Ruby 1.9 to OS X (and let you choose your version like they do with Java), I think it would have a huge impact on adoption by developers. Most people I know use Leopard’s version of Ruby and aren’t interested in monkeying with their Ruby installation.

As I’m using REE, I won’t upgrade until there’s a REE 1.9.x. But even without REE I’d be stuck within minutes, as I hear that the mysql gem does not work properly yet and I have no interest in trying to patch it myself.

Judging by isitruby19.com, mysql is not the only popular gem that’s not compatible yet, so I guess there’s a good reason for ‘normal’ rails app developers not to upgrade yet. On the other hand, the website unfortunately does not differ between versions, so there’s no easy way to tell if the issues that were reported months ago have already been fixed.

Once there’s an article on rubyonrails.org labelled “Rails 2.3.x and all popular gems now support 1.9, here’s how to upgrade your server within 20 minutes”, people will switch.

PS: has Rails 2.3.3 been released? I’ve seen it being tagged on github a week ago, but there’s no official announcement…

Another big stumbling block is the lack of linux distro package support. You have to jump through hoops to get a ruby-1.9 package installed and be the default ‘ruby’, with the other executables (rake, gem, irb etc) kept in sync.

My primal job is still with Windows and I like to use PostgreSQL for my db. I spent one day testing 1.9.1. and had issues with anything I tried.

There is no way (I didn’t get it) to accesas PostgreSQL from Windows. Gem doesn’t install without compilation and I don’t event want to know how to compile it.

I had problems accessing Exchange server with IMAP and in one application that is processing backup job log I found that 1.9.1 is about 500x times slower reading sequential files than on 1.8. or linux.

That’s where I stopped three months ago. I might again try in three months again and see what is new.

by
TheR

The biggest inhibitor for me is a lack of support for 1.9 by the webhosts. If that were fixed, like a version of Passenger for 1.9 (hint, hint!), then the webhosts would begin the eventual upgrade to 1.9.

As it stands, I develop all my work in Ruby 1.8 because that’s what Dreamhost supports on their service.

For me it’s been the impression from Matz & co. that 1.9 is just a playground for 2.0 features. Has this changed?

I use Heroku extensively for my projects, and they are still on 1.8.6; but that seems is a chicken and egg problem

And by playground, I mean a place for experiments which may be dropped if they don’t work out.

I’ve switched to 1.9 for a couple recent projects and have run into zero problems. And this is using Passenger/Nginx, and both Mysql and Postgres, so I’m not sure what others are talking about–it *already* works!
It would be nice to have ruby-debug so that rcov and metric_fu would work, hopefully someone will jump on this issue soon enough…

The way I see it, with 1.9 being ~40%(?) faster than 1.8, and also having big GC improvements, and having non-hacked-up UTF8 support built-in, and having the majority of common gems already working okay with it, I would ask: what’s the specific reason why you *haven’t* switched to 1.9? It seems like the main reason is just folks not being all that aware of it, as 1.9 appears to be perceived as a beta-developer-only release?

I am putting Ruby 1.9 switch on my calendar at least once every couple of months. And every time I come across an alarming article regarding Ruby 1.9 stability before I get to actually implementing the switch. So I put the decision on a back burner until the issue X is fixed. And then the pattern repeats itself, only with a new X every time.

I feel bad due to my lack of resources of contributing to this (i.e. fixing X myself every time) but in the end my stuff is running great on 1.8.6

However, as other have said, my next from-scratch project will be 1.9 (or Python, thanks to Google’s Unladen Swallow)

For me the biggest problem is that there is no proper documentation. I really tried, but I could not get hold of documentation for the standard library for Ruby 1.9. It is not available online, and running rdoc at home has problems. On my MacBook it never finishes because (I assume) it uses up too much memory. I had a Quadcore Desktop PC running Ubuntu, and managed to finish a run of rdoc occasionally. But then there is still the issue of making it look nice (I don’t know rdoc very well) – it seems to use a random start page, and I have heard that some aspects of the documentation will come out wrong in a naive run of rdoc (couldn’t really verify it for myself).

Before I could investigate further, my Ubuntu upgrade went awry and I was stuck with Windows XP on the Quadcore desktop. On Win XP again rdoc is unable to finish running on ext+lib (Out of Memory Error). At this point I decided that apparently nobody really cares for Ruby 1.9 (no reply to my new bug reports yet, either), so I reverted to 1.8.7 (I am still quite new to Ruby).

If the Rails hosting companies like Engine Yard, Heroku, etc offered an out-of-the box 1.9 instance, I would not hesitate to move my apps to it. It’s the lack of “flip the switch” hosting options that is holding me back.

I recently chose to use Ruby 1.8 for Rails because the Ruby on Rails website recommends using Ruby 1.8. If it recommended using Ruby 1.9 then that’s what I’d use.

I’ve dedicated myself to moving everything I can to 1.9. Any gem I use that doesn’t work, I try to patch. So far, I haven’t run into too many that I use that don’t have a 1.9 compatible version available. I’ve fixed a few gems I use that don’t work, and all in all, it hasn’t been that bad of an experience. I’m learning a lot more than I would have if I stayed with 1.8 and waited for everyone else to do the work.

I want even start trying to upgrade without ruby-debug. AFAIK, the only way to debug is by using print statements. I used to do that back in 1995 and its just too painful for me to consider. In my book a language isn’t prime-time unless I can set a breakpoint and see what’s going on.

I’m thinking about using JRuby instead though. It has comparable speed (considering its a 1.8) to 1.9 but has debugging capabilities.

I’ve been playing around with Ruby1.9 since it was released. I tried using rails 2.3 with I was constantly running into encoding issues from various places. Most of them were already mentioned here. I guess you’d be fine if you make web apps exclusively in us-ascii. The moment you have utf-8 chars around it gets messy. I’ve seen that there were some encoding related commits on rails 3.0 but I haven’t tried it since then.

Major show stoppers:

No ruby-debug
No proper db adapters
Rails 2.3.2 has lots of encoding issues

I hope that there will be a rails 2.3.x release fixing those issues. I can hardly wait to switch to Ruby1.9 as it has so many improvements. I’d hope that the rails team would embrace Ruby1.9 as it did with git or REST.

There are a couple of tickets on lighthouse concerning rails own encoding issues on 1.9 yet there wasn’t anything useful presented as a solution. So actually I think whats needed is that Rails itself is really 1.9 ready and that there are db adapters for mysql, postgres and sqlite3 that behave properly although I think the adapters should be easy if they’re not already fixed.

Go Go Go Ruby 1.9 !

I’ve been on 1.9 since it was officially released as ‘stable’—thin & rack are pretty much all I use.

Another BIG vote for ruby-debug here.

I made 1.9 the default ruby on my dev machine about 2 months ago, with 1.8.6 installed as ruby1.8. I find I can get by without 1.8 about 90% of the time. About half of the time I go back to using 1.8, it’s because I need ruby-debug.

The other half of the time, it’s for running old stable Rails projects that have vendored an older version of a gem that doesn’t work on 1.9.

I would love to see the community embrace 1.9. I got several of my smaller production sites working on 1.9 in the space of half a day. There is decent compatibility of gems and plugins out there; the most invasive thing I had to do (which wasn’t very invasive at all) was switch from hpricot to nokogiri for html parsing on one project (note: this was a few months ago, so hpricot may be fine now).

Performance tests ran great on 1.9. On some Ruby-intensive pages I got a 3x speedup relative to REE! (http://earthcode.com/blog/2009/05/ruby_191_is_the_bomb.htm)

Then I ran into the encoding problems (https://rails.lighthouseapp.com/projects/8994/tickets/2476-ascii-8bit-encoding-of-query-results-in-rails-232-and-ruby-191). For me, this was too much to tackle and I pulled back. When there is an authoritative resolution on this, I will gladly deploy my projects on 1.9 and encourage others to do the same.

@aleco: Mysql works in Ruby 1.9.

@Avdi: Whether or not it is a “test” for 2.0 shouldn’t matter. Ruby 2.0 is not even on the horizon yet, and it’s not going to be around anytime soon. In any event, even if you do plan on waiting, 1.9 is ultimately going to be closer to 2.0 than 1.8 is. Ultimately though: Ruby 1.9 is here now, it’s far better than 1.8, and that should be enough of an argument. I’m sure 2.0 will be even better, but that’s always going to be the case.

Frankly, I think most of the “I’m not so sure about 1.9″ talk comes from people who haven’t used 1.9 or is hearsay from other people who also have not used it. Anyone who has actually recently (last ~2 months) attempted to switch has found that a lot of the smaller gems are starting to come together in the way of 1.9 support; if not there are usually forks that fix the problems.

Another issue facing most people is simply trying Ruby 1.9– a lot of people seem to think you can either have 1.8 or 1.9 on a single system, but not both. This is not the case. It’s actually fairly trivial to install Ruby 1.8 and 1.9 side by side on a system as I’ve blogged about here:

http://gnuu.org/2009/06/14/installing-ruby-1-8-1-9-side-by-side/

Getting people to at least start running the YARV implementation easily should help get developers used to the new features and realize the switch isn’t as painful as they imagined. Being able to swap between 1.8 and 1.9 at an instant should certainly make things more manageable.

@August: I’ve also blogged about some of the most common encoding issues here:

http://gnuu.org/2009/02/02/ruby-19-common-problems-pt-1-encoding/

There are some other encoding related resources on Google (from Dave Thomas and others) that should help get people started.

Nice questions Yehuda. For me, its more about the ease of getting 1.9 running. I honestly hadn’t tried until I remembered Chad Humpries installer scripts, as well as some nice switching functions, so I took them for a spin and am happy to say they work as expected.

For those interested I did a quick writeup here: http://jackndempsey.blogspot.com/2009/07/getting-started-with-ruby-19.html

I’m already using Ruby 1.9 and doing well on projects on Linux. I’m still using 1.8.6 at work because I’m stuck on Windows (and behind a firewall) so without the one-click installer it’s pretty futile to get going. I actually just use MS Powershell to do in Windows what I would use Ruby for on Linux.

Sad.

Leave a Reply

Archives

Categories

Meta