Is it safe to use Ruby 1.9 yet?

#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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

#2

On Jul 2, 1:46*pm, Wayne Molina <wayne.mol... (AT) gmail (DOT) com> wrote:

Quote:

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
marnen (AT) marnen (DOT) org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

#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:

http://isitruby19.com/

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:

http://github.com/oneclick/rubyinstaller/tree/master

Luis Lavena is the SME on this project..

You can also get some good answers from Roger Pack..

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.

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

#4

On Thu, Jul 2, 2009 at 10:46 AM, Wayne Molina <wayne.molina (AT) gmail (DOT) com>wrote:

Quote:

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.

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

#5

Conrad Taylor wrote:
[...]

Quote:

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
marnen (AT) marnen (DOT) org
--
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

#6

On Thu, Jul 2, 2009 at 2:24 PM, Marnen Laibow-Koser <
rails-mailing-list (AT) andreas-s (DOT) net> wrote:

Quote:

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,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen (AT) marnen (DOT) org
--
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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

#7

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

Quote:

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

Quote:

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen (AT) marnen (DOT) org
--
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

--
jan=callcc{|jan|jan};jan.call(jan)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBAgAGBQJKTWjPAAoJEBcDvo3O83d6nqUH/3uloLU1tff5PVvOP9XEN7aw
Jke5R73PTKcnz8r8Mm0kVqn8VQ05VrvM4Nk2OqUxt7L2vCZNpd 5dqzG73rknV9L5
e5/3FQnkbF06Mq3uC2HRWy08cXifdxmkUjQsvzOcweyvwjhQzLbhM KlEB8cZBa8D
+0Ruk9fsuvIP1AU+CONlbGdDm/2xPSo3nN5xND+9ssck9kPe5og248cNGndnnGoV
4NoDBBGLD+gGg01fvy04/WBugadrvQ5COwj4X2XSo01DvPeEO3mCG7notvzCrSDx
FIS2U2gsvFqlFfCAJnv57VYWm0eUlXWdrnZ4k2Th51F9n9sVtx DvRKXnXkOfDrM=
=2yKV
-----END PGP SIGNATURE-----

#8

Flower Born wrote:

Quote:

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

-J

According to Phusion's own benchmarks at
http://www.rubyenterpriseedition.com/comparisons.html , 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. :P

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen (AT) marnen (DOT) org
--
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

#9

On Thu, Jul 2, 2009 at 7:41 PM, Marnen Laibow-Koser <
rails-mailing-list (AT) andreas-s (DOT) net> wrote:

Quote:

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
http://www.rubyenterpriseedition.com/comparisons.html , 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. :P

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen (AT) marnen (DOT) org
--
Posted via http://www.ruby-forum.com/.

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

#10

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.

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---