Ruby or JRuby

[Martin L'ecuyer]

Hi i'm new here and new with Ruby. I just start to learn Ruby and Ruby
on Rails. My question is wich between Ruby or JRuby should i learn. What
the diffrence and why one and not the other one. Thanks

 

[Charles Oliver Nutter]

Hi i'm new here and new with Ruby. I just start to learn Ruby and Ruby
on Rails. My question is wich between Ruby or JRuby should i learn. What
the diffrence and why one and not the other one. Thanks

For learning, there's not a whole lot of difference. JRuby is almost
completely compatible with Ruby 1.8.6, so what you learn on one should
generally apply to the other.

- Charlie

 

[James Herdman]

[Note: parts of this message were removed to make it a legal post.]

Hi Martin.

Don't look at is as "JRuby versus Ruby", so much as two different
implementations of the same thing. I'd focus on using whichever is best
suited for your computing environment. If you have no limitations that would
prevent you from running plain old Ruby, I'd stick with that for the time
being.

James

 

[Robert Dober]

This is a tough call, I would rather learn Ruby1.9, but that will not
be such a big difference at the beginning.
When you start playing around JRuby will have the advantage that you
can test 1.8 code and 1.9 code by simply providing the --1.9 option to
the interpreter.
Installing Ruby1.8 and Ruby1.9 on the same machine is a major pain.

HTH
Robert


--=20
Si tu veux construire un bateau ...
Ne rassemble pas des hommes pour aller chercher du bois, pr=E9parer des
outils, r=E9partir les t=E2ches, all=E9ger le travail=85 mais enseigne aux
gens la nostalgie de l=92infini de la mer.

If you want to build a ship, don=92t herd people together to collect
wood and don=92t assign them tasks and work, but rather teach them to
long for the endless immensity of the sea.

 

[David Masover]

Installing Ruby1.8 and Ruby1.9 on the same machine is a major pain.

It really wasn't, for me. The easiest way is to simply give the executables a
suffix -- irb1.9 vs irb. And I don't know that typing "irb1.9" is harder than
"jruby --1.9".

 

[Juan Zanos]

It really wasn't, for me. The easiest way is to simply give the
executables a
suffix -- irb1.9 vs irb. And I don't know that typing "irb1.9" is
harder than
"jruby --1.9".

Probably the installation difference is minor if you just want to
learn and experiment. It's more of an issue if you seriously want
to adopt ruby 1.8 and 1.9 on many machines, different platforms, and
critical applications. Then you have to be more careful with Ruby
1.8 and 1.9. Different package managers and installers are going to
give you different snapshots. You'll want to be sure you have some
kind of system in place for managing, updating and backing off all
the different permutations so that your apps will be reliable.

If Ruby 1.8 and 1.9 source came in a version control system such that
it was quick and easy to retrieve specific versions that would
probably help a lot. Then you could try various versions without
worrying too much if there are any issues and you could probably give
good specific information about problems to ruby developers so they
can fix them.

 

[Robert Dober]

It really wasn't, for me. The easiest way is to simply give the executables a
suffix -- irb1.9 vs irb. And I don't know that typing "irb1.9" is harder than
"jruby --1.9".

At first I thought it was a brilliant idea, so I did it but gem1.9
install bombed because it did not find gem, I do not think that I did
anything stupid.

Anyway I have opted for ruby1.9 into /usr/local/bin and jruby in my
home dir with an alias to $JRUBY_HOME/bin/jruby
and shell functions for jgem, jrake, jirb etc.

That is painless and good enough for me.

BTW I spent a day of installing and reinstalling ruby1.9 and ruby1.8
on the same machine and nothing I tried made them coexist without
*major* shell scripts for switching. As those might not scale to
changes I gave up on it, but maybe I was too tired and missed
something stupid.

Cheers
Robert

 

[Hassan Schroeder]

BTW I spent a day of installing and reinstalling ruby1.9 and ruby1.8
on the same machine and nothing I tried made them coexist without
*major* shell scripts for switching.

?? When I have multiple versions of anything on one system, I just
install each to its own directory, and then have a file with something
like, e.g. file named ~/187

export RUBY_HOME=/usr/local/ruby1.8.7
export PATH=$RUBY_HOME/bin:$PATH

:: and then I just type '. 187' -- tickety-boo and bob's yr uncle.

Never had a problem from using that approach.

FWIW,

 

[Joel VanderWerf]

At first I thought it was a brilliant idea, so I did it but gem1.9
install bombed because it did not find gem, I do not think that I did
anything stupid.

I've gone the '--program-suffix=19' route, just to play with ruby19, and
not had a problem, but I've avoided using gem19.

What happens if I do

gem19 install rake

for example? Well, it overwrites my old rake, and the new rake has a
hashbang line that invokes ruby19. Kaboom.

Maybe gem install should be aware of things like program-suffix in
rbconfig, and use them?

 

[Robert Dober]

?? When I have multiple versions of anything on one system, I just
install each to its own directory, and then have a file with something
like, e.g. file named ~/187

export RUBY_HOME=3D/usr/local/ruby1.8.7
export PATH=3D$RUBY_HOME/bin:$PATH

:: and then I just type '. 187' =A0-- tickety-boo and bob's yr uncle.

Never had a problem from using that approach.

FWIW,

I had absolutely no problem running Ruby this way. The problem I had
is with gems.
But maybe all those approaches are sound, I am notorious for
"forgetting" things, too bad one cannot do
Test Driven Installation
R

--=20
Si tu veux construire un bateau ...
Ne rassemble pas des hommes pour aller chercher du bois, pr=E9parer des
outils, r=E9partir les t=E2ches, all=E9ger le travail=85 mais enseigne aux
gens la nostalgie de l=92infini de la mer.

If you want to build a ship, don=92t herd people together to collect
wood and don=92t assign them tasks and work, but rather teach them to
long for the endless immensity of the sea.

 

[Robert Dober]

Maybe gem install should be aware of things like program-suffix in rbconfig,
and use them?

42+
R.

 

[Hassan Schroeder]

I had absolutely no problem running Ruby this way. The problem I had
is with gems.

Just out of curiousity, what kind of problem?

But maybe all those approaches are sound, I am notorious for
"forgetting" things, too bad one cannot do
Test Driven Installation

Yes, well, there is the issue of forgetting to install particular gems in
the different versions -- but the error messages lead me to that "fix"
eventually

 

[Robert Dober]

Just out of curiousity, what kind of problem?

Joel explained it better than I did, it comes down to the fact that
gem does not know about the suffix.
R.

 

[Hassan Schroeder]

Joel explained it better than I did, it comes down to the fact that
gem does not know about the suffix.

Ah, that's why the suffix thing makes no sense to me -- if you use
the default names for everything and set your path to the desired
version, everything works just fine, e.g.

/usr/local/ruby1.8.6/bin/ruby
/usr/local/ruby1.8.7/bin/ruby
/usr/local/ruby1.9.0/bin/ruby

and so on, jruby installations as well.

 

[Robert Dober]

Ah, that's why the suffix thing makes no sense to me -- if you use
the default names for everything and set your path to the desired
version, everything works just fine, e.g.

/usr/local/ruby1.8.6/bin/ruby
/usr/local/ruby1.8.7/bin/ruby
/usr/local/ruby1.9.0/bin/ruby

and so on, jruby installations as well.

hmm that indeed looks promising, I must have hosed things with links,
thanks for sharing!
Robert

--=20
Si tu veux construire un bateau ...
Ne rassemble pas des hommes pour aller chercher du bois, pr=E9parer des
outils, r=E9partir les t=E2ches, all=E9ger le travail=85 mais enseigne aux
gens la nostalgie de l=92infini de la mer.

If you want to build a ship, don=92t herd people together to collect
wood and don=92t assign them tasks and work, but rather teach them to
long for the endless immensity of the sea.

 

[Marc Heiler]

Installing Ruby1.8 and Ruby1.9 on the same machine is a major pain.

It is a breeze if you use Application-like approaches (like on
Gobolinux). I still, up today, wonder why there are problems with Mac OS
X + ruby.

Anyway, if you follow the FHS approach then for sure things will get
messy, because the FHS itself encourages bad practise.

Just look at the workaround provided before:

/usr/local/ruby1.8.6/bin/ruby
/usr/local/ruby1.8.7/bin/ruby
/usr/local/ruby1.9.0/bin/ruby

It uses versioned directories already. When will people realize that the
FHS in itself does not evolve in any way?
I do however think that these directories look ugly, and wont be in the
default search path anyway. Gobolinux would use /Programs/Ruby/1.8.6 for
this, Heretix/Rubyx did use /pkg/ruby/1.9.6 (unfortunately this
distribution died...), what PC-BSD is using I dont know but I think /pkg
too - not sure here.

that's why the suffix thing makes no sense to me

Personally, I never understood why i.e. debian makes a symlink to
ruby1.8 (or the other way around)

Versioning binaries is another hack to work around what the FHS imposes
on you - else, there would be no need for symlinking binary versions at
all, no?

PS: Gems, even if they work nicely, will forever be dependent on the
FHS, for as long as distributions use it. And thus, gems will forever
have those problems which popup again _and_ again. (rubygems are nice
though, i just think that they should be an integral part of ruby,
without the need for require 'rubygems' before any _specific_ gem is
required. This explicit requiring for rubygems is a small design
limitation imho.)

 

[Hassan Schroeder]

Just look at the workaround provided before:

Never thought of it as a 'workaround' -- just the way to install multiple
versions of anything

/usr/local/ruby1.8.6/bin/ruby
/usr/local/ruby1.8.7/bin/ruby
/usr/local/ruby1.9.0/bin/ruby

I do however think that these directories look ugly, and wont be in the
default search path anyway.

Well, "ugly" is in the eye of the beholder, certainly, but I like being able
to`ls /usr/local` and see at a glance what versions of what are installed.

And "not in the default path" is the whole point -- the version available
to a given shell instance is /only/ what you explicitly put in your path.

YMMV,

 

[David Masover]

I've gone the '--program-suffix=19' route, just to play with ruby19, and
not had a problem, but I've avoided using gem19.

What happens if I do

gem19 install rake

for example? Well, it overwrites my old rake, and the new rake has a
hashbang line that invokes ruby19. Kaboom.

Maybe gem install should be aware of things like program-suffix in
rbconfig, and use them?

Ideally, it should. However, you can do this:

gem19 install rake --format-executable

Then it will install rake19.

I actually don't use that, because I got tired of typing it all the time. I
instead installed 1.8 and 1.9 in separate locations, and wrote a few wrapper
scripts to set up PATH and RUBYLIB appropriately.

 

[Michael Guterl]

I've gone the '--program-suffix=3D19' route, just to play with ruby19, an= d not
had a problem, but I've avoided using gem19.

What happens if I do

=C2=A0gem19 install rake

for example? Well, it overwrites my old rake, and the new rake has a
hashbang line that invokes ruby19. Kaboom.

http://muness.blogspot.com/2009/02/easily-switch-between-ruby-186-and-191.h=
tml

The shell script at the url above seems to be working well for me.

Best,
Michael Guterl