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.
Tags: rails
November 30th, 2009 at 12:59 am
I’m sticking with 1.8 for the forseeable future. Given that application performance is not a problem for me and application stability is something that I care about, there’s simply no reason to even consider moving to 1.9 at this stage.
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.
November 30th, 2009 at 1:22 am
I know where you’re coming from and I agree to some extent, but I still consider it worth pursuing and writing about. Ruby 1.9 is stable and completely usable; it’s simply a pity that the most common framework doesn’t work on it. It looks bad, too, for the language, and considering the amount of time I’ve invested in Ruby in general and Rails in particular, that’s something I am significantly invested in.
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!
November 30th, 2009 at 2:30 am
I actually think the reason people are so cache-crazy in the Rails ecosystem is that there are lot of pathologically coded apps out there which perform dozens (and dozens) of database queries per request.
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…
November 30th, 2009 at 2:45 am
Yeah, well me neither really. But a blog post and/or pointed comment on a Lighthouse ticket every now and again is well within my “I care about this enough to spend the time writing it” threshold. I’ve spent much more time replying to your comments : )
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.
November 30th, 2009 at 3:31 am
I was going to pen a bit of a rant myself about 2.3.5, actually, based on the fact that the reason they did the release was to get a security fix out, but if you do a “git log v2.3.4..v2.3.5″ you’ll see that alongside the security fix and some (welcome, I guess) bug fixes, there is a lot of other churn which isn’t really justified in my opinion. But in the end couldn’t muster the motivation to do so (at least me existing specs and Cucumber features continued to work).
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.
November 30th, 2009 at 10:43 am
As I understand it, it will display pages correctly if there are no partials containing non-ascii characters, yes. And it’s not like you have to be doing crazy foreign shit either – one of my apps dares to use a few unicode arrow symbols in various ways, with the same problem.
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.
November 30th, 2009 at 2:22 pm
See, this pisses me off:
Were a few bugs, eh. Past tense. Guess I, and everyone else on that ticket, are just experiencing a group hallucination!
November 30th, 2009 at 4:27 pm
I think it’s because they speak English and they simply don’t care. You can rest assured that if it did affect them or their userbases then something would be done about it.
November 30th, 2009 at 4:33 pm
Ah well. I’m sure it will be fixed eventually. For now, the “place these two monkeypatches in your init folder” hack is painless enough.