Parallel installable ruby stacks

Guillermo Gómez guillermo.gomez at gmail.com
Fri Jul 29 13:33:36 UTC 2011


On Fri, Jul 29, 2011 at 8:37 AM, Sergio Rubio <rubiojr at frameos.org> wrote:
> 2011/7/29 Guillermo Gómez <guillermo.gomez at gmail.com>:
>>> Tell me why I, as an end user, should care if you application is running
>>> with Ruby 1.8, Ruby 1.9, REE, Rubinius or JRuby?
>>> Tell me why I, as a Fedora package, should care about my gem for more
>>> Ruby implementations/versions?
>>
>> I had to say that from what i know (which is not much), jruby is
>> really special  case here (im just reading about it).
>>
>> Basically jruby is not just another ruby implementation is something
>> really different and powerfull, but hey, im just starting to read
>> about it and correct me if im wrong (does jruby plays well with our
>> java vm?).
>
> That's the case with every ruby implementation out there. All of them
> have special features with their own benefits and drawbacks
> (performance, persistence, concurrency, bridges to other langs and
> frameworks, etc).
>
> Having sane defaults and supporting one ruby implementation makes a
> lot of sense. Discarding other ruby implementation cause user or the
> packager doesn't care does not IMO.

Yes, we should (we must) have one sane default if we want to keep it
simple (packaging/installing/using), but who's saying that the actual
default is the best sane default to deliver in average? Who and how it
is decided?

Point is that jruby apps wont work in our actual ruby default stack
without tweaking, the other way around would  just work as usual
(theoretically). So in this case switching to jruby presents a good
case (im not a big defender here of jruby just yet, im just presenting
the case and giving reasons to why we could consider other defaults or
why to go and further make our stack a more complex setup).

Other implementatios afaik does not present this user case.

-- 
Ing.Guillermo Gomez S.
Fedora Board Member A4
http://gomix.fedora-ve.org
http://www.neotechgw.com


More information about the ruby-sig mailing list