Ruby 1.9 & Rails 3.0
I’ve always been a big proponent of Ruby 1.9, I make no bones about it. My question is why wouldn’t you be? It’s faster, more powerful, easier to use, and makes things a lot clearer and cleaner than 1.8. So why then are pretty much all of us still running our applications on 1.8.x? Great question, and as far as I can tell there is really only 1 answer.
That answer? Because no one else is. It’s stupid really, but it’s the truth. We’re all afraid to run our applications in 1.9 because we don’t know many other people that are. Because of that it makes it hard for you to make your application work with 1.9 because all those gems and libraries you use aren’t 1.9 compatible, so you’re forced to keep running your app on 1.8. And so the cycle continues.
Enter Rails 3.0. Here is a major upgrade to the most prominent web framework in the Ruby community, and I would argue the reason that most of us got into Ruby in the first place. This upgrade will force us all to make some pretty severe changes to our applications to make them fully compatible. The changes in ActiveRecord alone are so sweeping and massive that we, as a community, are going to have to put some serious time into upgrade our applications. Yet, despite this, we are all going to do it.
Why are we all going to upgrade to Rails 3.0? Because it looks cool and sexy, and we want those great new features and all those performance enhancements to make our applications run faster. Which leads me back to Ruby 1.9.
In Rails 3.0 they are dropping support for Ruby 1.8.6 and below in favor of Ruby >1.8.7 and >1.9.1. I propose that Rails 3.0 becomes Ruby 1.9 compatible only. Think about it. What a perfect opportunity for us all. We are all going to have to upgrade the libraries and gems we maintain to support Rails 3.0 and we are going to be upgrading our applications to Rails 3.0, so why not go full steam into Ruby 1.9?
There is no better time than now to push forward into the future as a whole community. Let’s put Ruby 1.8 behind and reap the benefits of what Ruby 1.9 has to offer. What do you say? Can we do it? I think we can.
Tags: active record, rails, ruby
February 8th, 2010 at 10:31 am
I was also disappointed with the lack of support for Ruby 1.9.1, but then again I plan on deploying on Passenger with 1.8.7.
February 8th, 2010 at 10:40 am
Good luck with EncodingErrors then.
February 8th, 2010 at 10:45 am
I’ve been saying that for months now on ruby-talk. Putting 1.9 thingies into 1.8.7 is only going to make things worse because people won’t have an incentive to move on to 1.9, especially gem authors. Rails 3 should be 1.9.1-only.
February 8th, 2010 at 11:02 am
It would make for harsher upgrade paths, that’s for sure.
February 8th, 2010 at 11:17 am
I agree with you, yes its going to be a bit of a hard upgrade, but I prefer upgrading my apps once to rails3 and ruby1.9 that doing this twice.
February 8th, 2010 at 11:34 am
The question is whether this would increase the adoption of Ruby 1.9 or decrease the adoption of Rails 3. Probably the former, but we won’t know unless we’re forced to.
February 8th, 2010 at 11:51 am
I agree. I think there was a major opportunity missed with pushing the community forward. However, I wonder if “too much change” would have created too much of a rift for some people to cross. One of the major problems in the Python community I’m aware of is the divide between the 2.x and 3.x. People are refusing to adopt because of the amount of time/money it would cost to upgrade. This comparison could be made in the Ruby/Rails community. We’re at a major crossroads here where a major upgrade to the most popular framework has been pushed. There are major websites on the 2.x Rails platform (and some still on the 1.x) that upgrade is going to be hairy. Introducing a new language upgrade on top of that might be enough for people to not upgrade.
tldr: maybe it a battle best left for another day?
February 8th, 2010 at 12:00 pm
Sounds like a good plan but we need to get hosting providers on board too. Does anyone know when Heroku will add 1.9 support? They’re currently using MRI 1.8.6.
February 8th, 2010 at 12:13 pm
@ James McElhiney: Heroku is offering 1.9.1 now through their beta program. I got the latest staging version of Shortbord up there now. The performance is incredible. The beta has some issues, but it’s worth trying to get into the beta program.
February 8th, 2010 at 12:24 pm
Let’s be better and faster than python folks. Totally agree.
February 8th, 2010 at 12:35 pm
The reality everyone immediately glances over is that the upgrade path between 1.8-1.9 is ridiculously minor. Ridiculously. As in, half your Rails mini-apps probably already work without modification if you just setup your ENV right. The larger projects might have some more significant encoding issues, might need to change a few idioms, but unless you’re using something like ParseTree, it’s not going to be significant.
Rails3 is a huge leap in itself. 1.9 doesn’t tack on that much extra work. I really can’t see the justification for saying “I would have totally spent the next few *weeks* upgrading to rails3 if it wasn’t for the extra few *hours* I’d need to spend upgrading to 1.9!”
February 8th, 2010 at 12:58 pm
I would say that Rails 3.1 should be bug fixes for Rails 3.0.
Rails 3.2 should be ruby only 1.9 compatible.
I would rather upgrade to rails 3.0 and then move to ruby 1.9. Two big changes at that same time could be tough.
February 8th, 2010 at 1:00 pm
The last time I tried upgrading to 1.9, there wasn’t even proper debugger support (i.e, it just didn’t work). This was only a few months back. That should be a bare minimum for pushing any new language version forward. Several other libraries I tried out had issues as well. Upgrading for the sake of upgrading doesn’t really buy me anything.
Another major hurdle is that all the major linux vendors are shipping 1.8 still. So, running 1.9 on my EC2 cluster puts me into unsupported territory, which isn’t a nice place to be. The reality there is it’d be much easier for me to move to JRuby to address my performance needs than it would be to move to 1.9.1.
February 8th, 2010 at 1:06 pm
I am just starting to learn Ruby 1.9.1. I plan on moving on to Rails 3 and using the two together. It’s really a no brainer knowing it is faster and more powerful combination.
February 8th, 2010 at 1:10 pm
[...] This post was Twitted by hugobarauna [...]
February 8th, 2010 at 1:24 pm
I tried using Ruby 1.9.1 on Rails3 projects this weekend (using RVM). It was a complete failure (site wouldnt even start). Bugs have all been reported, but I ended up just switching back to Ruby 1.8.7 fixed everything.
So, don’t expect a smooth ride at the moment.
February 8th, 2010 at 2:30 pm
Rails 3 will definitely prefer Ruby 1.9.2 — when it’s released — and require Ruby 1.8.7 or later.
If you’re running 1.9, I’d recommend building 1.9.2dev rather than using 1.9.1. It’s big upgrade, it has quite a few behavior changes, and Rails master is developed against 1.9.2 exclusively (though we do continuous integration against 1.9.1 for good measure).
The key to *requiring* 1.9.2 is full mysql-ruby, pg, and sqlite3-ruby encoding support. These database drivers have had ages to upgrade but still aren’t up to snuff. Pitch in, make it happen, and you’ll find the database-backed web app world one step behind you.
February 8th, 2010 at 3:25 pm
1.9 only, totally agree – most Ruby devs I know re afraid of 1.9 for some reason. For the Ruby-cause!
Kevin Menard:
if RUBY_VERSION >= ‘1.9′
config.gem ‘ruby-debug19′, :lib => ‘ruby-debug’
else
config.gem ‘ruby-debug’
end
jc: It’s web platform beta; use on own risk.
February 8th, 2010 at 5:18 pm
I’m not a rails developer myself, but the assumption you have is that people will only upgrade their gems to 1.9 if you force them to do so. My experience is that people want to update their gems to 1.9, but are doing so in their copious free time.
February 8th, 2010 at 5:28 pm
Grimen:
I appreciate the response. But having to do that is also a bit absurd and illustrates why moving to 1.9 is a pain in the neck. It feels like death by a thousand cuts. Trust me, I’m not staying on 1.8 because I love the way the GC crashes. I’m staying there because it’s the most pragmatic thing to do.
February 8th, 2010 at 5:42 pm
@Jeremy: Or we could just push towards adopting DataObjects as a DB later undereath ActiveRecord and Arel.
DataObjects (DO) has support for MySQL, SQLite3, PostgreSQL and several other DBs. It supports Ruby 1.8.6 through 1.9.2. It also has encoding support on 1.9. It works with JRuby and even Rubinius (!). The windows MRI gem is a “fat binary” allowing the same gem to work with 1.8 and 1.9. It has non-blocking support like neverblock. It is supported by DataMapper and Sequel, and DM has been using it for well over 2 years. The gem installation command is the same across all versions and flavors of ruby. The interface is uniform across all the drivers It has an active developer community and great support. Oh, and it’s also extremely fast.
I could go on but you get the point. DO was 1.9 compatible over a year ago, while most of the other DB drivers are lagging behind the curve as Jeremy points out.
One of the DO developers (myabc) recently started porting Arel to work with DO: http://github.com/myabc/arel/tree/do — I know he’d appreciate some help from the community. Hop into #dm-hacking on IRC, and ask myabc, dbussink or myself (dkubb) what you can do to help.
February 8th, 2010 at 5:51 pm
@Jeremy: I completely second Dan’s suggestion of adopting DataObjects for AR. That’s a great idea Dan, and one that I wish happened a long time ago. Think of how much cleaner the AR/ARel code would get if it only had to work with a single unified API. Plus, I used to be a big DM supporter/contributor back in the day, and I can tell you that those drivers are rock solid and FAST!
February 8th, 2010 at 9:05 pm
Agreed! Most of active projects will do their migration to 3.0 & 1.9 in order to support the new technologies, those slow or abandoned projects will not be compatible any more, leaving room for new ones with better and cleaner code. Harsh progress?? but still progress…
February 8th, 2010 at 10:05 pm
Rails 3.1 should require ruby Ruby 1.9.2 at the bare minimum. Let’s make it happen!
February 10th, 2010 at 1:56 am
@Grimen. I don’t know who started the RUBY_VERSION >= ‘1.9′ idiom but they got it backwards. Ruby 1.9 is released, everyone should be writing for (and with) 1.9 aiming for 1.8 compatibility not the other way around.
I understand it’s a subtle difference but an important one and has the added advantage that when the time comes to drop 1.8 support (and it will just like 1.6 conditions disappeared over time) it will be easy to remove all your 1.8 compatibility code which is neatly marked as such
if RUBY_VERSION = ‘1.9′
# … 1.8 compatibility backports, monkey patches get required here.
end
Developing any new code in 1.8 at this point isn’t doing anyone any favors and hinders progress that we desperately need. Even if you don’t personally you can bet every one of us uses gems daily that would benefit from 1.9.
February 10th, 2010 at 2:03 am
Formatting error on the code sample, with no preview and no edits. Gist is here: http://gist.github.com/300090
February 11th, 2010 at 6:26 pm
@Shanna: It’s was nothing wrong with RUBY_VERSION >= ‘1.9? in apps when hundreds of gems was not compatible in 2009. I’m coding in Ruby 1.9 all day long, but neither of us are superman and can make all gems be 1.9-compatible: I’t sup to the community as whole to fix that. While complex gems like ruby-debug is not 1.9, RUBY_VERSION >= ‘1.9? is totally fine as I see it. Rather 1.9 in mind than not at all. A I said, I’m only on 1.8 when I have to.