Rubinius vs JRE

[Glenn Dix]

The architecture for Rubinius looks like an exciting enhancement over
MRI in the areas of concurrency and memory management, but I have two
general questions:

1. Will the Rubinius project exist long-term, or will it be
assimilated into MRI or something else
2. How will Rubinius be better than the JRE, other than for directly
supporting Ruby (e.g. java.lang.NullPointerException, system clock
skewing, incompatibility between minor revisions and patch releases,
weekly high severity vulnerability findings, etc.)

[flebber]

1. Since the MRI is C and Rubinius in Ruby whats to assimilate? Will
it last long term, that ultimately will depend on user base and
contributor base, use and contribute the longer it will last.

2. Better than JRE. The JRE is has evolved and has a lot of mature
libraries written against it. So for Rubinius to be better it will
need to mature and have contributors write and develop libraires. It
would have the potential to be better as the libraries can be written
in Ruby not limiting the user who can contribute libraries ie not
limited to java or c extension writers, now those experienced in Ruby
can contribute to the language they love directly.

Sayth

[Smock Jonathan]

I saw that this didn't get a reply, so I figured I'd take a shot.  I've just started to seriously get interested in contributing, so I may not have all my history/facts straight.

1. Rubinius started as an interest/labor of love by Evan Phoenix.  It's gotten sponsorship from EngineYard in the form of two employed developers (Evan and Brian, I believe) that work on Rubinius full-time.  Predicting the future is hard, but those two factors make me think Rubinius will be around for some time.  Obviously the hope is for even more people to run their programs and apps on Rubinius and contribute back to keep it going.

There has been talk about Rubinius being some kind of replacement for MRI but not by either core team (I could be wrong here).  At very least, my impression is that neither side is really pushing for it, and each core team is content working on their own "branch" as they have different goals, etc.  I personally don't think it will happen, which is fine.  Rubinius offers its own advantages, which are distinct from the advantages of MRI (and JRuby).  That said, Brian Ford was on an EngineYard podcast recently and noted that one of Rubinius' goals is to be a drop-in replacement for MRI in terms of compatibility, C extensions, etc.

2.  It seems you're asking about the Rubinius VM vs. the JVM, and I can't speak to that intelligently.  All I know is the Rubinius VM is small as VMs go and is designed to support the dynamic nature of Ruby.  The JVM is a larger codebase but has a large amount of support to refine and extend it.  The JVM is starting to add things like invoke-dynamic which will better support dynamic languages, but it's being added now not baked in.  Again, this is my extremely coarse understanding of the differences.

--
--- !ruby/object:MailingList
name: rubinius-dev
view: http://groups.google.com/group/rubinius-dev?hl=en
post: rubini...@googlegroups.com
unsubscribe: rubinius-dev...@googlegroups.com

[Dave Newton]

On Sun, Jul 31, 2011 at 9:21 PM, Smock Jonathan <jons...@gmail.com> wrote:
> 2. [...] >  The JVM is starting to add things like invoke-dynamic which will better

> support dynamic languages, but it's being added now not baked in.

It's in now.

Dave

[Dave Newton]

On Fri, Jul 29, 2011 at 3:22 AM, flebber <flebbe...@gmail.com> wrote:
> 2. Better than JRE. The JRE is has evolved and has a lot of mature
> libraries written against it. So for Rubinius to be better it will
> need to mature and have contributors write and develop libraires.

The same could be said for any Ruby VM. Since most Ruby folks aren't
using the JVM, I don't really see that as a strong need for Rubinius
in particular--non-JRuby users are already using Ruby-only libs
anyway.

Dave