So is this stuff getting folded into Ruby proper? If not, why not?

As far as I know: these REE releases/patches are for 1.8.7, a release of Ruby that isn't quite being actively developed, only maintained. Stuff similar to this is being folded into the official Ruby interpreter, which is now at 1.9.1 (1.9.2 soon!).

The uptake of Ruby 1.9.1 has been slow, and people are staying on 1.8.7 for compatibility reasons. Thus, these patches are trying to bring better memory performance to the old but widely used 1.8.7.

Swap 1.8.6 for 1.8.7 and you'd be more correct.

Can someone explain why this was downvoted? People are staying ion 1.8.6, not 1.8.7 (though some are moving there).

1.8.7 is being developed; 1.8.6 is in maintenance mode by way of EngineYard.

http://redmine.ruby-lang.org/

    * Ruby 1.9 - Edge version of Ruby
          o Ruby 1.9.1 - The latest stable release of Ruby 1.9 series.
    * Ruby 1.8 - Stable development version of Ruby
          o Ruby 1.8.6 - An ancient stable release of Ruby that Rails users love
          o Ruby 1.8.7 - A stable release of Ruby for bridging a gap between the 1.8 and 1.9.
    * Ruby - Version-independent topics

It probably will eventually... there are some cultural and linguistic aspects that are slowing down the process. Ruby is also not officially on a distributed SCM yet...

Good question. I'd like to know too.

This may sound silly, but I think it's the language barrier.

Also, Matz has been very loyal to the core group of Ruby maintainers even after Ruby has gone beyond fad status. Matz has been reluctant to put Ruby on a distributed SCM as well.

I expect all of these issues to be resolved within the next few years...

I think you're right about the language barrier.

Also, I don't really care if these community enhancements make it to the "proper" Ruby or not. The main thing is that it is available to the community, whether christened as the "Matz" Ruby or not.

true, but it's just a pain to use someone's nonstandard fork of ruby... there are a lot of awesome ones on github already, though, and I recently noticed that the latest version of ruby enterprise edition has rolled in a few of the better known ones.

Also why aren't we all using or moving to Ruby 1.9, instead of sticking with 1.8?

I think the main reason is simply that 1.8.6 has been "good enough" for most people. It reminds me a lot of Apache 1.3 vs. Apache 2.0.

For a long while, there were also no debuggers for 1.9.1, which is a big deal for some people. Mark Moseley has done a lot of work to get them working on 1.9.1 so luckily this isn't really a concern any more.

http://github.com/mark-moseley

I made Ruby 1.9 my default Ruby using Macports (using the +nosuffix variant) a few months ago. Other than finding a few trivial bugs in my code and some other people's, it's been painless; though of course your mileage may vary.

I migrated my site to Ruby 1.9.1 about a month ago and it was mostly painless. It's now running up to 4x as fast for some requests!

It's finally time to start developing entirely in Ruby 1.9 guys. Trust me.

What does your deployment look like? Nginx/Apache in front of Thin/Mongrel?

We've tried various deployments over the years with various levels of success.

Our 1.9 deployment is Nginx -> HaProxy -> Thin

I had trouble getting Mongrel to work in 1.9 (it was my favorite in 1.8) although apparently you can do it. Thin just worked(tm) so I switched to it painlessly.

I'm guessing passenger... they've had support for 1.9 for some time now.

I ran Passenger for a while in the past but I really didn't like how it would pause every rails process briefly when spinning up a new instance. Maybe that's been fixed now.

Monit may be harder to set up, but it works very well once it's running.

you mean mongrel? Monit is a monitoring platform...

Actually I meant Monit, sorry.

Ruby has a memory issue with long running processes. They seem to grow and grow and need to be restarted when they get out of hand. People commonly use Monit or God for this.

When you use Passenger, you can have it restart your processes after a certain amount of requests to prevent the memory leak issue, but when it happens it seems to block all requests to all processes for a short time, which is annoying to end users. It means your site can be speedy and zip along, then just pause.

I did but was surprised how many others didn't (and still haven't). There were some hiccups but nothing insurmountable.

Of course I blew everything away upgrading to Snow Leopard so I'll have to replace/upgrade with 1.9 again (though I'm also considering Ruby Version Manager).

1.87 is a transitional release designed to ease some of the pain of moving to 1.9. Some gems and libraries, also, aren't fully 1.9 compatible. I think more so than even these is that getting people to change can be fairly difficult.

Folks can get an idea of the gem migration situation here:

http://isitruby19.com/

It's easier to development on proven technology than to upgrade sometimes, especially when there are tight product deadlines.

Also, running on a Mac, it is easier to use whatever Mac is using so that your code has less bugs across different dev machines.

One of the big improvements ruby enterprise edition made is to make Ruby's GC copy on write friendly. This allows you to run a lot more ruby processes per frontend in a web environmet, since you're usually ram limited.

Afaik 1.9 didn't address this.

the reason for me is that (afaik) ruby-debug doesn't work with ruby 1.9.

im soo much more productive when i can set a break point and see why my flow isn't working.

Hello, you can find a port here:

http://wiki.github.com/mark-moseley/ruby-debug

fantastic! thnx