All I can ever find is performance comparisons, but it must be more than
just this or else why wouldn't everyone use Jruby? Would someone who
knows layout the differences between the major interpreters? Why
shouldn't I always use Jruby considering it has so much better
performance? What are the advantages and disadvantages of each
interpreter?
--
Posted via http://www.ruby-forum.com/.
Performance is not the only issue when selecting an interpreter.
We do use Jruby in a few places, but only when Jruby provides a
feature that is too difficult in the normal version.
Why don't we use it everywhere?
1) We dont want to heft around the massive JRE
2) Some gems do not work with Jruby and the alternatives are awkward
3) The performance improvement isn't that great (network and database
latency tend to overshadow everything)
Even if Jruby was consistently twice as fast as the normal interpreter
it will only amount to a < 10% improvement in the overall application
performance for the sort of apps we create.
The biggest improvements in performance for our applications come from
better algorithms and caching 
In addition to the points Peter Hickman made, there are other things to
keep in mind as well:
* Better performance on microbenchmarks generally does not tell the whole
performance story. Some other implementations may be faster at some
things.
* The JRE takes a while to spin up when starting a new process. That
means that for small programs that are occasionally run briefly to
accomplish very small tasks, JRuby can actually be much slower than
other implementations.
* In some cases, it is easier to get another implementation installed in
your target deployment environment.
* Licensing concerns may come into play. Rubinius, MIR/YARV, and
(surprisingly) IronRuby are all distributed under more permissive
licenses than JRuby these days. This might turn out to be important
for some deployment scenarios.
* The fact the JRE is tied to Oracle now, and Oracle has been going
around rattling its litigation saber at anyone dealing with alternate
Java implementations makes a lot of people wary about using the JRE
where it is not strictly necessary.
* Rubyists in general tend to target MRI/YARV first and foremost, and
other implementations are often treated as second-class citizens for
purposes of compatibility testing. My impression is that Rubinius will
have the least problem with this long-term, because it will probably be
the closest thing to MRI/YARV for purposes of compatibility. JRuby is
an apple that falls rather farther from the tree than that.
I make no judgments in this email about any of the above points; I'm just
explaining some reasons people might have for using other Ruby
implementations. I'm sure someone could come up with some other reasons
one might want to choose a different Ruby implementation, too. The
upshot is that performance benchmarks are not everything.
(By the way, with the number of Ruby implementations out there, I may
have overlooked something that would change some of the specifics of
things I said here. I think the general message is pretty accurate,
though, regardless.)
On Sun, May 06, 2012 at 08:13:26PM +0900, ruby gem wrote:
All I can ever find is performance comparisons, but it must be more than
just this or else why wouldn't everyone use Jruby? Would someone who
knows layout the differences between the major interpreters? Why
shouldn't I always use Jruby considering it has so much better
performance? What are the advantages and disadvantages of each
interpreter?
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
I'll give you the reasons people tell us they choose (and do not choose) JRuby.
Pro:
* JVM features
** Solid parallelism and concurrency libraries that have been tested
for many years
** Excellent performance through JIT and the new invokedynamic features
** The best GCs in the world
** Wide selection of libraries that are also 100% managed, and don't
impose restrictions like C extensions do
** Portability - JRuby works on any platform where the JVM is available
* Existing JVM infrastructure
* Android applications
* Large datasets (JVM handles much better than e.g. MRI)
* Straight-line performance (JRuby should generally be the fastest
when running on JRuby 1.7 + Java 7 JVM)
Con:
* Slow startup (partially JVM's fault and partially our fault...we
continuously improve here).
* C extension support (we have partial support, but it's not being maintained).
* Process size (we are larger, but you can often do more than MRI
without needing multiple processes).
* Many POSIX features from Ruby aren't or can't be implemented (fork,
low-level sockets, process control).
* Some people just hate Java or the JVM and anything associated with them.
We've never had anyone say they're not using JRuby because our licenses.
- Charlie
On Sun, May 6, 2012 at 6:13 AM, ruby gem <lists@ruby-forum.com> wrote:
All I can ever find is performance comparisons, but it must be more than
just this or else why wouldn't everyone use Jruby? Would someone who
knows layout the differences between the major interpreters? Why
shouldn't I always use Jruby considering it has so much better
performance? What are the advantages and disadvantages of each
interpreter?
* Licensing concerns may come into play. Rubinius, MIR/YARV, and
(surprisingly) IronRuby are all distributed under more permissive
licenses than JRuby these days. This might turn out to be important
for some deployment scenarios.
This is false. JRuby is licensed under three licenses, and you can
pick whichever you want to use: GPL, LGPL, and CPL. The CPL is a more
permissive license like Apache or BSD.
http://www.opensource.org/licenses/cpl1.0
* The fact the JRE is tied to Oracle now, and Oracle has been going
around rattling its litigation saber at anyone dealing with alternate
Java implementations makes a lot of people wary about using the JRE
where it is not strictly necessary.
Oracle is going after *one* alternative Java implementation (Android,
which Google tries to sell as not being Java) largely because they
(Oracle) failed to successfully come up with a way to recreate mobile
Java and want a piece of this pie. It will likely come to almost
nothing in the courts.
Sun/Oracle has also stated a few times that Android could or could
have used OpenJDK, and they encourage forking and experimentation on
top of the GPL-based OpenJDK codebase. This isn't a fight about the
JRE...it's just politics and greed.
* Rubyists in general tend to target MRI/YARV first and foremost, and
other implementations are often treated as second-class citizens for
purposes of compatibility testing. My impression is that Rubinius will
have the least problem with this long-term, because it will probably be
the closest thing to MRI/YARV for purposes of compatibility. JRuby is
an apple that falls rather farther from the tree than that.
The fact that JRuby falls far from the tree is a good thing.
Implementations dependent on C extensions are going to always have
that cross to bear, for example, dealing with badly-behaving C code,
reduced parallelism, and GC complications. JRuby + JVM language-based
extensions have no such limitations.
- Charlie
On Sun, May 6, 2012 at 11:20 AM, Chad Perrin <code@apotheon.net> wrote:
Why don't we use it everywhere?
1) We dont want to heft around the massive JRE
I'd hardly call it hefty... a typical JRE download is from 10 to 30MB.
Even if Jruby was consistently twice as fast as the normal interpreter
it will only amount to a < 10% improvement in the overall application
performance for the sort of apps we create.The biggest improvements in performance for our applications come from
better algorithms and caching
Probably the best argument for simply writing good Ruby code rather
than hoping for an implementation to solve all your problems, eh? 
FWIW, JRuby 1.7 on Java 7 JVMs will start to show significantly
improved performance...on some real-world benchmarks I've tested
things are anywhere from 2-10x faster. Of course, that will maybe
amount to an 18% improvement in your overall app performance, but that
might be desirable too...
- Charlie
On Sun, May 6, 2012 at 6:39 AM, Peter Hickman <peterhickman386@googlemail.com> wrote:
I'll give you the reasons people tell us they choose (and do not choose) JRuby.
Pro:
** Solid parallelism and concurrency libraries that have been tested
for many years
** Excellent performance through JIT and the new invokedynamic features
* Large datasets (JVM handles much better than e.g. MRI)
* Straight-line performance (JRuby should generally be the fastest
when running on JRuby 1.7 + Java 7 JVM)
These are the reasons we have JRuby running some of our system routines which would otherwise be runnable in any other Ruby implementation.
Con:
* Process size (we are larger, but you can often do more than MRI
without needing multiple processes).
* Many POSIX features from Ruby aren't or can't be implemented (fork,
low-level sockets, process control).
These represent frustrations we observe with running under JRuby. I'm not a big fan of Java, but the phrase "horses for courses" comes to mind.
Sam
On 20/05/12 01:00, Charles Oliver Nutter wrote:
> * Licensing concerns may come into play. Rubinius, MIR/YARV, and
> (surprisingly) IronRuby are all distributed under more permissive
> licenses than JRuby these days. This might turn out to be important
> for some deployment scenarios.This is false. JRuby is licensed under three licenses, and you can
pick whichever you want to use: GPL, LGPL, and CPL. The CPL is a more
permissive license like Apache or BSD.
It is quite different from the Apache License v1.x through v2.x.
Similarities include patent license. Differences, at first glance,
appear to invovle the fact the Apache License 2.0 (for instance) includes
modification notes in all modified files and a limited form of
advertising clause, and the fact that the CPL requires notice of where to
receive sources if it is distributed in "object code" form (equivalent to
the upstream source provisions of the GPL in the case of noncommercial
redistribution). Maybe I misread something when I skimmed the license.
Meanwhile, the Revised BSD License and Simplified BSD License are both
certified as compliant with the Copyfree Standard Definition, and impose
no substantive restrictions on recipients of the software apart from the
simple requirement to keep the license with the software.
To be fair, though, I had never seen any notice of the CPL as a
disjunctive multi-license option for JRuby, so thank you for letting me
know about that option.
>
> * The fact the JRE is tied to Oracle now, and Oracle has been going
> around rattling its litigation saber at anyone dealing with alternate
> Java implementations makes a lot of people wary about using the JRE
> where it is not strictly necessary.Oracle is going after *one* alternative Java implementation (Android,
which Google tries to sell as not being Java) largely because they
(Oracle) failed to successfully come up with a way to recreate mobile
Java and want a piece of this pie. It will likely come to almost
nothing in the courts.
Oracle also imposed limitations on its Community Process implementation
working group that forced the Apache Foundation to cease development of
its Harmony project and drop out of that group. There are also rumors of
Oracle demanding that Boeing start paying royalties on contracted
deployments of Java software with the Oracle implementation of Java.
Sun/Oracle has also stated a few times that Android could or could
have used OpenJDK, and they encourage forking and experimentation on
top of the GPL-based OpenJDK codebase. This isn't a fight about the
JRE...it's just politics and greed.
What's the "politics and greed" component here? How is reimplementation
to better suit the Android platform, rather than using the OpenJDK as
distributed by Oracle (which depends on some less-free files for most
deployment use cases), a matter of "politics and greed"? It sounds to me
like the "politics and greed" characteristics of the fight are over
Oracle's desire to keep others from making use of the Java language in a
way that does not positively affect its bottom line directly.
>
> * Rubyists in general tend to target MRI/YARV first and foremost, and
> other implementations are often treated as second-class citizens for
> purposes of compatibility testing. My impression is that Rubinius will
> have the least problem with this long-term, because it will probably be
> the closest thing to MRI/YARV for purposes of compatibility. JRuby is
> an apple that falls rather farther from the tree than that.The fact that JRuby falls far from the tree is a good thing.
Implementations dependent on C extensions are going to always have
that cross to bear, for example, dealing with badly-behaving C code,
reduced parallelism, and GC complications. JRuby + JVM language-based
extensions have no such limitations.
If I assume you're talking about the technical benefits of Java, I think
that's a matter for the person choosing an implementation to decide.
It's also not really relevant to what I said. I'm not sure whether
you're trying to dispute what I said with this statement; if so, I think
you're off-target, and if not, I don't have a specific opinion on this
matter at this time.
On Sat, May 19, 2012 at 09:44:56PM +0900, Charles Oliver Nutter wrote:
On Sun, May 6, 2012 at 11:20 AM, Chad Perrin <code@apotheon.net> wrote:
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]