Jruby vs. rubinius

Ruby JRuby
1

hello jruby folks – i need your help.

i (somewhat foolishly) signed up for a public “fight” at the
wroc_love.rb [1] ruby conference in wroclaw (poland) next month.
so dirkjan bussink will take the rubinius corner, and me the jruby
one, and we will battle (verbally, i hope) over which ruby
implementation is “best”.

while i have a good grasp of jruby’s strengths (kernel threads,
mature and optimized vm, interoperability with other jvm languages)
i have to admit i know very little about rubinius. what are its
main weaknesses, especially compared to jruby? what possible points
of attack do you see?

any hints / suggestions / ideas appreciated :slight_smile: :slight_smile:

cheers
tim

[1] http://wrocloverb.com/

–
http://tim.lossen.de

2

I’m just going to brain dump reasons why I think it’s better to target
the JVM than to build a new VM.

  • The JVM has millions of man-hours behind it.

You want maturity in a VM you’re going to build your company on. The
JVM has evolved over 15 years of work, and has dealt with countless
challenges that a new VM would have to address for the first time.
There are thousands (if not millions) of JVMs deployed in the world,
running many different sizes of applications on many different
platforms and hardware configurations. It’s simply not possible to
match the maturity of the JVM in just a few man-years of work.

  • The JVM has best-in-class tech across a wide range of technologies

The best garbage collectors are on the JVM. The best optimizing JITs
are on the JVM. Concurrency is solid and stable, with many patterns
available (and many of them supported down to the VM level). And
there’s more and better tech coming every day.

  • The JVM runs everywhere

There are JVMs that run on everything from small embedded devices up
to massive servers with hundreds of cores. There’s a JVM for just
about every operating system and every hardware platform.

  • The JVM is moving forward faster than ever

Java 7 was the start of a new age for the JVM. It brought
invokedynamic, the most important change to the JVM in at least a
decade. Java 8 will bring first-class functions, closures, modularity,
and more. And outside the standard path, developers have implemented
tail calls, continuations, value types, and a lot more.

  • The JVM ecosystem is incomparable

Dozens of languages, tens of thousands of libraries, and millions of
developers. Dozens of tools.

…

I guess most of my reasons for believing the JVM (and therefore JRuby)
is a stronger bet boil down to the fact that we get all the above
basically for free. We don’t have to debug GC problems (or even write
a GC). We don’t have to figure out why threads are deadlocking in the
VM. We don’t have to write a native JIT compiler. We just target the
JVM, with a few tricks here and there, and we’re done.

Other thoughts, anyone?

  • Charlie
3

of attack do you see?
I haven’t looked at Rubinius in ~5 months, but one of its lingering
weaknesses was (and likely still is) a lack of usable Windows support.

At that time I was unable to build-on-Windows-for-Windows, and the
Rubinius VM was architected and built in a way that caused symbol
visibility link failures. I don’t think these issues have been solved,
but in all fairness, I don’t track Rubinius any more.

http://jonforums.github.com/ruby/2011/07/17/building-rubinius-on-windows-1.html
bigdecimal.so link fail when building on Win7 · Issue #1164 · rubinius/rubinius · GitHub

One of the strengths of JRuby is its multi-platform support. This is a
statement of both a technical perspective and a philosophical project
management perspective. I won’t address the technical goodies other
than to say that I find JRuby’s usability and buildability (??)
fantastic on both my Win7 and Arch systems.

With regards to multi-platform support, JRuby’s project management
should be recognized as the competitive advantage it is. For example,
the JRuby team has been consistently providing Windows installers and
Windows-friendly binary archives.

More importantly, multi-platform goodness appears to be part of their
DNA. When I reported a performance regression that impacted usability,
Charles quickly resolved it http://jira.codehaus.org/browse/JRUBY-6201
rather than allowing it to linger for years. When I highlighted a
recent improvement in MRI on Windows, Charles reminded me that I was
Doing it Wrong and JRuby on Windows performance was better than I had
originally documented
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42713 I
single out Charles, but there are other examples involving other JRuby
committers and non-committers.

While there are those that, rightly so, care less about running
{Ruby|JRuby|Rubinius} on Windows, there are others who see the value.

Here’s one example. Say you’ve decided to deploy your_coolness.rb app to
a cloud provider who uses either a Linux or BSD OS as part of their
infrastructure. Who cares about whether their Ruby impl runs on Windows,
right?

But what if your developers use Windows boxes? Would you really be happy
developing locally on MRI or JRuby but deploying to Rubinius? How do you
replicate and quickly solve issues let alone optimize? Who do you go to
for support? How do you regression test when a new Rubinius version is
rolled out? Etc…

This example is a clearly a bit of a stretch, but you get the point as
well as see the potential biz benefits of JRuby in the cloud. If you
happen to be in this scenario, using JRuby is clearly the better
solution.

That said, technically I like, and see huge potential in Rubinius. Their
technically strong group of contributors impresses me. I hope they find
a way to make Rubinius a killer multi-platform Ruby implementation with
Windows support that’s not a kludgy, bolt-on, neglected Quasimodo.

I suspect their key issues include (a) focusing limited resources, and
(b) discovering a way to make Windows support sustainable by figuring
out a biz model that allows them to monetize the Windows support.

All a very wordy way of saying highlight JRuby’s multi-platform
technical and project management goodness in your upcoming discussion :wink:

Jon

Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums

4

Hi Tim

whenever I think about Rubinius I feel kind of the same way that I feel
about Squeak vs Self. In theory, having your language implemented in
itself using only a minimal, optimizing and jitting VM with only 5
bytecodes is a GREAT idea, and I can’t help but love Rubinius for
trying.

But there’s a mismatch between what’s great in theory and what
works in practice. If Rubinius, with its current performance, were
actually implemented mainly in Ruby, I wouldn’t wait a second to
switch. Being able to extend and fix my language and VM in Ruby?
Awesome!

Fact is, however, that they still have a long (long) way to go
before they’re at that point. Until then they implement stuff in Ruby
that may be in the VM on MRI, bit seriously, your Array implementation
doesn’t belong into your VM anyway. And a lot of that Ruby code in
Rubinius’ core classes calls primitives in the VM. I know, lots of that
is for performance reasons, but there has to be another way to do it
than have the Ruby code be a Shim wrapper around your Cpp code (and
there is, as Self and PyPy and Maxine demonstrate, but it takes A LOT
of time and effort). So, until Rubinius bootstraps its VM from Ruby
code, I don’t see how it’s implemented mainly in Ruby. Because it’s
also the VM I want to be able to extend, not just the language.

So, while I do love the motivation behind Rubinius and seriously wish
it success, I believe that at this time, their main selling point (being
written in Ruby) is useless, because lots of stuff is actually still in
C++. And if you want to extend Rubinius, you will see that
code. And if I can do C++, I can do Java just as well, and then I can
just use JRuby.

That’s what I see as the main weakness of Rubinius at this time. The
thing they’re trying to sell, a practical Ruby written in Ruby, doesn’t
exists. Yet :wink:

5

On Fri, Feb 24, 2012 at 1:36 AM, Tim F. [email protected] wrote:

So, while I do love the motivation behind Rubinius and seriously wish
it success, I believe that at this time, their main selling point (being
written in Ruby) is useless, because lots of stuff is actually still in
C++. And if you want to extend Rubinius, you will see that
code. And if I can do C++, I can do Java just as well, and then I can
just use JRuby.

Sadly true. In fact, there’s almost as much C++ in Rubinius as there
is Java in JRuby.

  • Charlie
6

charles,

thanks for your “braindump” regarding jruby strengths – this
is pretty much exactly how i feel about the jvm as well.

i realize this list is probably the wrong place to ask for weak
points in rubinius. i guess i’ll have to lurk a bit on the
rubinius lists instead … :wink:

cheers
tim

On 2012-02-21, at 17:39 , Charles Oliver N. wrote:

platforms and hardware configurations. It’s simply not possible to

tail calls, continuations, value types, and a lot more.
basically for free. We don’t have to debug GC problems (or even write

of attack do you see?

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

–
http://tim.lossen.de

7

On 2012-02-21, at 18:06 , Jon wrote:

I haven’t looked at Rubinius in ~5 months, but one of its lingering weaknesses
was (and likely still is) a lack of usable Windows support.

ok, good to know – i’ll keep that in mind.

thanks
tim

–
http://tim.lossen.de

8

rubinius has a “much worse” community, at least seems to me…like the 2
times I’ve posted on their mailing list I have gotten no (0) responses,
which is why I prefer jruby. No really it is. :slight_smile:

9

On Mar 2, 2012, at 8:31 AM, Roger P. wrote:

rubinius has a “much worse” community, at least seems to me…like the 2
times I’ve posted on their mailing list I have gotten no (0) responses,
which is why I prefer jruby. No really it is. :slight_smile:

All of the Rubinius action takes place on IRC where there are typically
120+ people lurking (similar to the JRuby channel). The mailing list has
been deadly quiet since the beginning and is unlikely to change unless
someone starts posting there and making sure questions get answered.

cr

10

now THAT is a nice angle of attack for me to exploit – thanks, tim!

On 2012-02-24, at 17:03 , Charles Oliver N. wrote:

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

–
http://tim.lossen.de