

Ruby's Biggest Challenge for 2009 - acangiano
http://antoniocangiano.com/2009/03/23/rubys-biggest-challenge-for-2009/

======
jd
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.

~~~
Andys
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.

------
davidw
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.

~~~
tesseract
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.

~~~
chrislo
> 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"]

~~~
tesseract
Ah. Maybe it should have been done in hex?

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

------
jwilliams
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?

~~~
rcoder
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.

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

~~~
FooBarWidget
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.

~~~
berntb
What Perl version on what OS?

~~~
FooBarWidget
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.

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

------
sho
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!

~~~
batasrki
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

~~~
jcapote
The latest Passenger supports ruby 1.9.1

~~~
thras
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.

~~~
FooBarWidget
Phusion Passenger has Debian packages.

~~~
thras
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.

~~~
FooBarWidget
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.

------
villageidiot
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.

