Ruby's Biggest Challenge for 2009 | Hacker News Reader

Ruby's Biggest Challenge for 2009

antoniocangiano.com

60 pointsacangiano33 comments

Rails is in a though spot right now. Facing a big challenge, a huge challenge even. And arguably, a challenge it didn't have to face.

Why introduce a new VM and break backwards compatibility at the same time? Why not first give people a better VM, with bytecode, better threads and all the other goodies? When people know that upgrading is painless (think Perl) then you can just upgrade without thinking twice about it. If you know you have to check the compatibility checklist of all software you have ever installed (for all you know your text editor depends on Ruby nowadays) then upgrading becomes a very unappealing task.

So, step one: introduce new VM. Step two, still don't break backwards compatibility. -If- you have to break the language, at least put some legacy mode in, so people don't have to port every script on their system.

Why introduce a new VM and break backwards compatibility at the same time?

I agree that "Big bangs" aren't always a good idea. However, what I believe is the case is - Any language geeks can feel to tell me I'm wrong here - is that the new VM benefited tremendously from making Ruby's syntax more regular. "MRI", Matzo's Ruby Interpreter, produced the unfortunate effect of making whatever its haphazard result were into "Standard Ruby". Making a faster interpreter that preserved all this stuff would be hard. So in this case, a "big bang", however painful, made sense

The incompatibilities that have hit hardest are for the modules that use C language extensions. This can't really be helped for such a major change to the underlying structure.

The ruby language changes were mostly included in Ruby 1.8.7, and so most "pure ruby" libraries that worked there also work in 1.9.

I wish you'd use LangPop.com for stats instead of TIOBE:-) I agree about the marketing/communication aspect of things though: I was under some sort of impression that 1.9 was, like "odd numbered Linux kernels" some sort of permanent-beta. I'm not quite sure where I got that idea, but a few other people I know seemed to be under the same impression. Something else that might help is a prominently located guide/tutorial to upgrading to 1.9.

Good point about LangPop, David. I will reference it in future posts.

I believe that 1.9 was supposed to be a beta (1.5 and 1.7 were), but the plans for 2.0 got to be too ambitious and there came a need for a version number between 1.8 and 2.0. I suppose it could have been called 1.10 but there were presumably good reasons.

> I suppose it could have been called 1.10 but there were > presumably good reasons.

If I remember correctly, that's due to the way ruby sorts strings

  ['1.8','1.9','1.10'].sort  #=> ["1.10", "1.8", "1.9"]

Ah. Maybe it should have been done in hex?

  %w[1.8 1.9 1.A].sort  #=> ["1.8", "1.9", "1.A"]

I saw "GIL" and had a look into it (Global Interpreter Lock apparently) - seems like a very heavy-handed mechanism to put in.

In fact, it seems, well, extremely lazy -- but I'm not sure I understand the thinking behind it. Are there pros/cons to having a GIL approach?

Without a GIL, you not only have to make sure that your entire VM + runtime are re-entrant, but that every library you call into is, too. You can call it "lazy," but it's a fairly standard + pragmatic way to safely layer multi-threading atop arbitrary C libraries.

Add to that the fact that, without the GIL, there becomes a need to define what qualifies as an atomic operation. Since Ruby didn't have a standard bytecode until recently, this ends up being an implementation-specific nightmare (even with the YARV bytecode, it's still an implementation-specific issue not likely to be resolved soon). In other words, without GIL, what's thread-safe in MRI might not be in JRuby or vice versa.

The successful approach seems to be what Tcl (and Perl, I hear) do: one interpreter per thread, with message passing/shared memory.

I don't know about Tcl, but Perl's approach is anything but successful. I have a Perl app of about 40000 lines. It takes 15 seconds to create a single thread, and after it's done, Perl segfaults. Every Perl thread duplicates the AST, making memory usage bloat to ridiculous proportions. I found out that forking new processes is faster and uses less memory.

What Perl version on what OS?

Perl 5.6.2 all the way up until 5.8.8. On Windows XP, Fedora Linux and Ubuntu Linux. Same results everywhere. Perl threads only work for apps less than 2000 lines. Go beyond that they'll blow up.

Tcl doesn't have a reputation for being "New! Exciting!" but it has a very reliable runtime.

Ok - well I figured that this could be done on a much finer-grained, case-by-case basis (?), but I clearly haven't touched on the issue in enough detail.

I think Ruby's biggest challenge for 2009 will be getting standardized.

Hm, Rails still doesn't work fully on 1.9.1. There's a few bugs relating to character encoding in templates still, you can find details on Lighthouse. It mostly works though. I've switched exclusively to 1.9.1 for console work, which is unaffected by the ActionView bug.

I agree with the point about how projects not being ported to 1.9 begin to look unmaintained. It's been 3 months in stable now, and a year of betas before that - I can't help but start thinking any project not moving as fast as possible towards compatibility might not be one anyone should be relying on.

Most unforgivable offenders: Mongrel and the DB libraries

Most pleasant surprise: RMagick!

Thanks sho. I edited that sentence about Rails and linked the word "complete" to your comment.

Oops - I didn't want to make a big fuss about it! It's only when you're using unicode in templates, won't affect the vast majority of people. It 99.9% works : )

Well, for all those developers outside US it's more like 0,01% works, because unicode is always used in templates. But hopefully it'll soon be resolved.

I don't think anyone thinks Ruby 1.9 is a stepping stone for Ruby 2.0. We're not using it because it isn't fully supported yet by Rails (so /agree sho).

Perhaps more importantly, a lot of us are waiting for Rails 3.0 to move our existing applications over since there are huge risks and pains with shifting to a new version of a framework from something that currently works fairly well.

Fair enough. But for us, we've had so much pain from 1.8 that the second it looks like 1.9 mostly works we are throwing the switch. If I never have to hear or think about 1.8 leaking memory ever again that will still be too soon.

Admittedly, it wasn't that much of a problem with web, most of my "fun" from 1.8 has been with long-running processes. If you're not running them, or trying to run them I should say, there would probably be a lot less urgency - although it is faster in general anyway, so might be worth a bit of pain.

So yeah, not yet. Soon, though.

I don't think that Mongrel is maintained anymore. I am not sure about Phusion Passenger's, aka mod-rails, compatibility with 1.9.1

The latest Passenger supports ruby 1.9.1

I'm more than a little impressed with Passenger. It didn't exactly adhere to Debian conventions, but it's new and nothing in Ruby-land does.

Regardless, it was a breeze to set up, and seems to be running great.

It looks like a lot of effort was invested into this -- I wonder if they'll be able to make money.

Phusion Passenger has Debian packages.

Where?

On their site, I see some Ubuntu packages which would probably work. But once I get to the point of "probably work", I might as well install the gem version.

The ones provided by Brightbox. I'm under the impression that they should work on Debian seeing that Ubuntu is based on Debian. As far as I know they work out-of-the-box without even having to run the Phusion Passenger installer manually.

"I don't think that Mongrel is maintained anymore."

I think Kirk Haines is looking after Mongrel now.

What is even more surprising: getting mongrel and DB libraries to work is just a case of a simple 'search and replace' of a couple of things in the C language components of those libraries.

I think the author makes a good case for the upgrade. But I was fairly confident that the migration would happen later if not sooner. The more interesting question for me is why interest in Ruby has been dropping off.

Reply on news.ycombinator.com