Sho Fukamachi Online

So Rails 2.3.5 is out and while I don’t really know what’s new, I can tell you what isn’t – not running on the current stable version of the ruby programming language as reported by Ruby-Lang.

If you would like to start testing Rails on 1.9, you’ll need to apply the patches listed at this Lighthouse ticket, which fix the two most serious problems. A kind user down the bottom of that ticket has pulled the patches into monkeypatches suitable for just slipping into your config/initializers folder – I can confirm that they work for me.

I cannot fathom Rails Core’s bizarre refusal to pull these patches into 2.3.5. Yet another release goes out that is completely non-functional on the newest, fastest and best version of the language, forcing users to seek out and apply non-official monkeypatches – or just forsake 1.9 altogether, as the vast majority seem to be doing. In what way is this in the best interest of the framework or the community? What is holding them back? The patches might not be 100% perfect but they’re a lot better than what we have now, which is that out of the box Rails is broken on 1.9.1.

UPDATE: Happily, the 1.9.1-patched Rails does seem to be working on 1.9.2 as well. I’ve installed ruby 1.9.2dev (2009-09-07 trunk 24787) and my favourite “fussy site” is working there, too. That’s great news, because 1.9.2 is going to be the “serious” version of Ruby 1.9 and has further big performance increases.

So I’ve been ranting recently about Rails’ lack of Ruby 1.9 support. And rightfully so! It’s inexcusable for the #1 Ruby framework to not support the fastest, most efficient version of Ruby, especially not after it’s been available for almost 2 years.

But for some people, it is kind-of possible to use Rails on 1.9 today. Rails’ 2.3-stable (“stable” in quotes) branch has fixed a few of the worst problems in 2.3.4, such as the string comparison bug which made authentication systems unworkable. The showstoppers for me, like the utf8 in templates issue, remain. I wouldn’t rely on it in production – not for a site which your job depends on, anyway – but as long as you don’t use certain features of rails (like i18n), and don’t need to deal with utf8 much if at all, you may be able to use it.

You should want to switch to 1.9.1 as soon as possible. I see between 20% and 50% higher performance than 1.8.7, with memory usage significantly lower and even better, less prone to leakage. In one of my projects there is a daemon which does nothing except wait for items to hit a queue and then launches a script to deal with them. In 1.8.7, it would gain a meg or so every few hours and I’d be nervous about leaving it running unmonitored. In 1.9.1 it sits rock solid on 6.5M for weeks on end. I am totally sold on 1.9.1.

Anyway, here’s the instructions to get Rails up to the latest possible usable state. Open a terminal at the root of your Rails app:

# head into /vendor
$ cd vendor
 
# clear out any other rails
$ rm -rf rails/
 
# clone rails into here
$ git clone git://github.com/rails/rails.git rails
Initialized empty Git repository in /Users/sho/projects/myproject.com/vendor/rails/.git/
remote: Counting objects: 123204, done.
remote: Compressing objects: 100% (27700/27700), done.
remote: Total 123204 (delta 95101), reused 121853 (delta 94037)
Receiving objects: 100% (123204/123204), 21.72 MiB | 380 KiB/s, done.
Resolving deltas: 100% (95101/95101), done.
 
# enter that directory
$ cd rails/
 
# checkout 2.3 stable, ignore the errors
$ git checkout -b  2-3-stable remotes/origin/2-3-stable
warning: unable to unlink arel: Operation not permitted
warning: unable to unlink rack-mount: Operation not permitted
Branch 2-3-stable set up to track remote branch 2-3-stable from origin.
Switched to a new branch '2-3-stable'
 
# go back to the root dir 
$ cd ../..
 
# run rails as 1.9.1. get ready to find out which gems you forgot!
$ ruby1.9 script/server
 
# hello, console
$ script/console --irb=irb1.9
Loading development environment (Rails 2.3.4)
>> RUBY_VERSION
=> "1.9.1"

And there you go. It’s working, kind of. Try it out.

I would probably recommend using thin as the web server, but if you need a working mongrel in 1.9, my gem is still available:

sudo gem1.9 install sho-mongrel

That will probably die when github pulls gems for real but who knows, maybe the official mongrel will have been fixed by then (HA!).

Meanwhile, I’m going to step up my harassment of the Rails Core team to get this crap fixed; it is a fucking JOKE that it still doesn’t work 100%.

update: moved the gem to gemcutter.

Ruby on Rails development seems to be stalled, with no substantial release since March and many show-stopper bugs in the current version, 2.3.4, such as the claimed Ruby 1.9 support which does not work, meaning that the official Rails gem doesn’t run on the only version of Ruby that doesn’t leak memory like a firehose leaks water. Freezing to edge is broken and has been broken for months. Needless to say, that’s because master is now Rails 3.0pre which is in a totally unrunnable state.

The seems oddly low-volume, considering 2.3.5 is over a month late and 2.3.4 has so many problems. Working patches to fix critical errors languish unmerged for months, constantly needing to be regenerated to keep up – not that there’s anything official to keep up with, since there’s no real 2.3.5 target and master is fixated on the faraway 3.0. The Lighthouse tracking system is itself a hopeless, unnavigable mess.

So what’s going on with Rails? With the historical core developers absent or tied up with reinvent-the-world expeditions like the 3.0 rewrite, the projects appears directionless and adrift. Meanwhile the shine fades and word leaks out that all is not well in Railsville.

What happened? Two causes.

Firstly, the shoot-for-the moon total rewrite for Rails 3, leaving Rails 2 languishing for the better part of a year now and Rails 3 in a totally unrunnable state.

Secondly – well, this is just my opinion. But one of the reasons Rails was great at first because it was written by people who actually wanted to use it to make actual proper web apps. And then it became famous, and then it attracted another type of developer – people who just wanted their membership in Rails Core on their resumé – but they weren’t going to actually use it for real-world projects. So instead of getting fixes to seven-month-old show-stopper bugs, we get Engines and RESTful Resource Mapping and Application Templates, none of which are much used or useful in the real world.

Rails is looking sicker by the month. And since Core has bet the company on Rails 3.0, it better blow the world away and fix everything, or I have a feeling a lot of Rails devs are going to start looking for the next big thing. Or actually, the next small thing. I would trade off 90% of Rails’ useless bloat and feature creep for a minimalist framework that actually works, has developers who care, has a readable codebase and a clear direction. Basically, what Rails used to be before DHH got tired of saying “NO!” and it turned into a stumbling monster.

Sinatra? It’s possible but it’s a little too unstructured; great for a tiny API but I’d be worried about trying to use it for a large project. Django is by all appearances in even worse shape than Rails. Ramaze? Looks very interesting.

Update to turn down the tone a bit and correct some links. I will follow up with some constructive posts later; it is actually possible to run Rails on 1.9, just takes some work.