Is it safe to use Ruby 1.9 yet?

Rails
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

On Jul 2, 1:46 pm, Wayne M. [email protected] wrote:

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?

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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

3

Okay, I’ve been developing on 1.8.6, 1.8.7, and 1.9.1-p129. After so
many frustrations with 1.9.1-p129, I stopped developing RoR with it.
Your best bet is to stick with 1.8.6 or 1.8.7 depending on your
development environment.

The biggest issues are the following:

Gem incompatibilities
Gem binary builds
Core ruby binary builds

I have pretty much encountered them all. I even managed to create a 75%
windows build for Ruby 1.9.1-p129 using VC8 instead of ming. There are
simply too many packages to build. Ming is being used for building Ruby
now by many.

If you think you can still do it, then visit the following links:

Do a search on all the core gems you will be using in RoR to make sure
they are now compatible. The biggest issues with gems are:

mysql, sqlite3, mongrel, rspec, and a few others

I have work arounds for all of them and actually have a fully working
1.9.1 but it took a lot of doing and I had to build some of the binary
gems myself to get there.

If using windows:

Luis L. is the SME on this project…

You can also get some good answers from Roger P…

If using linux:

Do a search for your linux distro and installing 1.9.1. Make sure you
have all of the libraries on hand before you build from source. Failure
to do so will create some issues. You will still have issues with gems
though.

4

On Thu, Jul 2, 2009 at 10:46 AM, Wayne M.
[email protected]wrote:

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.

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

5

Conrad T. 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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

6

On Thu, Jul 2, 2009 at 2:24 PM, Marnen Laibow-Koser <
[email protected]> wrote:

–
Posted via http://www.ruby-forum.com/.

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

7

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

8

On Thu, Jul 2, 2009 at 7:41 PM, Marnen Laibow-Koser <
[email protected]> wrote:

faster than MRI, at least in conjunction with Passenger. I recently

Posted via http://www.ruby-forum.com/.

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

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

9

Flower Born wrote:

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

-J

According to Phusion’s own benchmarks at
Performance and memory usage comparisons — Ruby Enterprise Edition , Ruby EE is
faster than MRI, at least in conjunction with Passenger. I recently
found a set of Ruby-only benchmarks taking into account JRuby as well as
all other leading Ruby interpreters, and in those, I seem to recall that
REE fared even better – comparable to JRuby and significantly faster
than MRI. Of course, now I can’t find the URL for that one. :stuck_out_tongue:

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

10

On Fri, Jul 3, 2009 at 6:33 AM, Älphä Blüë
<[email protected]

wrote:

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

11

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)

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.