Is it safe to use Ruby 1.9 yet?

rubyonrails-talk
1

I haven't been following the RoR community for a while as my work caught up to me, but now things have slowed down a little and I'm looking at getting back to learning Rails for my web app idea (a customized CRM type app for services like lawn care, carpet cleaning and pool cleaning).

As I see, the current version of Ruby 1.9 is 1.9.1-p129. Is Rails compatible with this version? I know from a little reading before that there were issues and upgrading was NOT recommended; has this changed? Any common gems that don't work, or have most of the bugs been ironed out? I already started writing some of my code in Ruby 1.8.7 (Rails 2.3.2) so I'm considering upgrading now to 1.9.1 but I don't want to start an upgrade only to find that a lot of basic things aren't working.

Right now I have both Ruby 1.8.7 and 1.9.1 installed side-by-side on my MacBook just to be on the safe side.

2

Rails 2.3 is; plugins and gems may be not be. I see no reason to upgrade at the moment.

See http://isitruby19.com for compatibility info.

Best,

3

Hi, I have been using it in production for about 3 months after its

release and I must say that I have noticed a considerable speed up of

my applications. Furthermore, I noticed this more so with the bigger

applications that required more processing. Ruby 1.9.1-p129 is definitely

ready for production with Rail 2.3.2/Edge IMO. I did have to make some

minor mods to gems but it was well worth the deep dive.

At this time, I’m also starting to do some testing with JRuby and MacRuby

implementations since the Global Interpreter Lock (GIL) doesn’t exist in

these 1.9.1 implementations. Now, you can really start to write some concurrent

applications if this is your internal requirement. However, Ruby 1.9.1-p129 still

has GIL which means you can only execute a single thread at a time. Thus, your

programs will run sequentially unless you off load your threading to external

processes.

Good luck,

-Conrad

4

Conrad Taylor wrote: [...]

Hi, I have been using it in production for about 3 months after its release and I must say that I have noticed a considerable speed up of my applications. Furthermore, I noticed this more so with the bigger applications that required more processing. Ruby 1.9.1-p129 is definitely ready for production with Rail 2.3.2/Edge IMO. I did have to make some minor mods to gems but it was well worth the deep dive.

Good to know...but why not just use Ruby EE? It acts just like MRI 1.8.7, so no modification of code is required, but it's significantly faster, or at least that's what the benchmarks say. Is Ruby 1.9 enough faster than Ruby EE to justify the extra work of modifying gems?

Best,

5

Marren, as far as I know, the GIL still exists in Ruby EE. The minor mods

were either on the Ruby side or the C-Extension side and I’m looking to do

a bit of concurrent processing.

MacRuby is being used because it allows me to seamlessly interact with the

Objective-C/Cocoa. Furthermore, it has no GIL and plans for better support for

multi-core systems.

JRuby is being used because we need to interact with existing Java frameworks

with parts of the system.

My boss wants me to push the technology to its limits and see what’s possible.

BTW, we do a lot of AI, bioinformatic, and other related projects and I’m dealing

with systems with the following configurations most of the time:

CPU: 8-cores

RAM: 16 GB minimum

HDD: 4 TB minimum

However, I tend to also do e-commerce stuff on the side and I can see where good

concurrency would be beneficial to the user’s experience. In short, I’m using the

implementation/technology that best supports the specific part of the system because

one size doesn’t fit all.

-Conrad

6

* Marnen Laibow-Koser <rails-mailing-list@andreas-s.net> [2009-07-02 23:24:45 +0200]:

Conrad Taylor wrote: [...] > Hi, I have been using it in production for about 3 months after its > release and I must say that I have noticed a considerable speed up of > my applications. Furthermore, I noticed this more so with the bigger > applications that required more processing. Ruby 1.9.1-p129 is > definitely > ready for production with Rail 2.3.2/Edge IMO. I did have to make some > minor mods to gems but it was well worth the deep dive.

Good to know...but why not just use Ruby EE? It acts just like MRI 1.8.7, so no modification of code is required, but it's significantly faster, or at least that's what the benchmarks say. Is Ruby 1.9 enough faster than Ruby EE to justify the extra work of modifying gems?

AFAIK, Ruby EE is not significantly faster, but has a much smaller memory use?

-J

7

Well, here’s Antonio’s Cangiano benchmarks from the December 2008 shootout which tests Ruby performance:

http://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008

I’m sure that these numbers are different today but it’s snapshot of the performance compared to other implementations

back in December. My requirements are different from your requirements because I tend to do more Ruby development

without Rails. Also, I need to be able to interact with non-Ruby frameworks/libraries in various parts of the system.

-Conrad

8

Good information Conrad.

However, going back to the original question by the OP…

The short answer is (it can be done)

The long answer is (with a lot of work and hurdling many issues)

If you’re versed in C/C++, Ruby C extensions API, C/C++ build process,

and understand the Ruby 1.8.6/1.9.1 differences this should be a relatively

straight forward process.

So, if you are the type of person that is patient and is willing to work

through many possible issues and you don’t mind that some gems are not

ready yet - then make the jump.

Or, the safe route IMO, is to stay with what you have.

A better approach would be to do the following:

a) download and install Ruby 1.9 for non-production purposes

b) optionally install the relevant multi-ruby gems or write a Ruby/Bash script

to switch between the different implementations

c) read the README file and execute the relevant tests of the gem(s) you

need for your Rails application against the relevant Ruby implementations

d) play with your Rails application against the different Ruby implementations by

executing the relevant tests of your Rails application as well as browser

testing

e) now you have a Ruby 1.9 test harness in place for your Rails application

In short, one should start to prepare their Rails applications now for Ruby 1.9 and

the same could be said for both gems and plugins.

Good luck,

-Conrad