When 2.3.5 came out with the patch that worked for 1.9.1 I tried using that but unfortunately every app became ultra slow. So some good advice is to stick to 2.3.3 with 1.9.1 you get speedy apps and speedy database access!

To install it:
gem install rails -v 2.3.3

Anyway that’s what I’m sticking with until 2.3.6 with 1.9.x works equally fast/stable.

As for stability I can vouch that 1.9.1 with 2.3.3 is indeed stable (was running for months with no visible memory leaks or performance issues on my debian servers).

I hear constantly people saying to stick with 1.8.x but that’s like sticking with g++ 2.x which the linux kernel tried to do for a long time. In the end it’s better to move on (I mean the author of ruby has, so why not the rails developers?). It is inevitable that rails should in the end run on 1.9.x since that is where ruby is going …

Improved compatibility with Ruby 1.9

There were a few small bugs preventing full compatibility with Ruby 1.9. However, we wouldn’t be surprised you were already running Rails 2.3.X successfully before these bugs were fixed (they were small).

Were a few bugs, eh. Past tense. Guess I, and everyone else on that ticket, are just experiencing a group hallucination!

But I don’t think submitting data to the DB will work, ie through a form, without the “fix params” patch referenced in the ticket, since Rails will try and fail to pass the incorrectly encoded UTF8 to the database. Well that was my experience anyway, didn’t test it all that thoroughly.

2.3.5 does seems to have fixed one 1.9-related bug, to do with string comparisons, so at least most authentication will work now. I just can’t understand why they didn’t roll in the other fixes as well. In fact if I was not such a charitable person I would be tempted to think they are taking a perverse pleasure in not rolling out the patches, which have been extensively used and verified by myself and others on the ticket for over *6 months*. Certainly precious few other reasons spring to mind.

I agree it would be nice if Rails just worked with 1.9. As I understand it, it basically does if you live in a monolingual world where only US English is spoken.

It really will be good when we can trust 1.9 enough that even conservative actors such as yourself have no qualms about deploying on it – that will only happen when the mainstream sees it as a genuine option and has time to pound out the bugs. My goal is simply to bring that day forward a little bit. I like 1.9, I want to be able to standardise on it, it’s as simple as that really.

Rails is a chaotic mess where the only thing that seems to work in getting things fixed is making sufficient noise and nuisance of one’s self that the committers come to see it as a profitable use of their time to type the one-line command that merges the six-month-old well-tested patches that do the fixing. This post, along with all others by myself on the topic, are simply calculated to be that noise. I am also attempting to save time for hapless fellow developers wondering why their “Ruby 1.9 compatible” rails applications are not, in point of fact, compatible with Ruby 1.9. Call it civic duty.

In any case, agree with you that it’s a good thing that somebody is pressuring for 1.9 support; I’m just saying that I’m not gonna be that person…

Ruby 1.9 is faster and uses less memory than Ruby 1.8 – these are both significant steps towards freeing Ruby from its (unfortunately well-deserved) reputation of being slow as cold molasses and an utter pig for memory. It’s worth pushing those holding the commit rights to take 1.9 compatibility a little more seriously IMO.

You might not have an issue with speed – probably your application is cached to the hilt. Remember that such caching strategies are a significant amount of work to implement and are not necessary at all for many other languages – PHP generally runs fast enough that you don’t even need to start thinking about caching until you’re seeing a lot of hits. Even python, usually the language Ruby is most directly contrasted against, kicks its ass in terms of speed. The fact that caching is such an important subject in the world of Rails is good in some ways but also speaks volumes about the underlying speed problems. And that’s before we even start talking about memory usage.

Ruby 1.9 is not the be all and end all, and caching is still important. But it’s a step forward. I would like to see Rails take that step.

I’m not using 1.9 in production for web servers yet but I’m using it for image processing daemons, etc. The work is all done; I have had no problems at all using most of the common libraries, and I’ve seen significant speedups and efficiency gains, usually around the order of 50%. That might not sound like much but if you’re processing 50,000 images then it’s the difference between 3 days processing time and 2 – and memory usage is greatly reduced, obsoleting hacks like REE. I have never had any stability issue whatsoever. The only problem is Rails, so I’ll keep bugging the core team until they commit those damn patches and we can all forget about it and move on!

Let the brave, the reckless, and those who insist on updating to the “newest and shiniest” bang their heads against this particular brick wall, while I get on with my life elsewhere.