The right Ruby runtime [was Re: Notifications between Aeolus components]

Mo Morsi mmorsi at redhat.com
Wed Jan 23 18:02:25 UTC 2013


On 01/22/2013 12:42 PM, David Lutterkort wrote:
> On Tue, 2013-01-22 at 09:57 -0500, Scott Seago wrote:
>> On 01/22/2013 08:01 AM, Michal Fojtik wrote:
>>> On 01/08, Hugh Brock wrote:
>>>
>>> Maybe a crazy idea, but Torquebox already includes messaging, background
>>> jobs, services and all other things mentioned in the original email.
>>>
>>> I have PoC of running Conductor inside Torquebox (using jRuby). I
>>> understand it might be a big step but definitely worth to at least
>>> investigate as an option :-)
>>>
>>> Just my .20cents.
>>>
>>>    -- Michal
>>>
>> We've talked about using torquebox on-and-off over the last couple 
>> years. The growing consensus there seems to be that we do want to be 
>> able to run on it, but not at the expense of getting locked in to using 
>> _only_ torquebox.
> One of the things that makes Ruby so thorny is the endless number of
> runtime/deployment options: starting with the interpreter, through to
> the app server, there's lots and lots of variations, most of which suck
> in one way or another.
>
> We are using MRI basically because it is the default, and thought to be
> widely adopted. Especially MRI 1.8 had little redeeming features beyond
> that - we'll see how 1.9 will blow up differently.
>
> It might be a good exercise to agree on a set of requirements for our
> Ruby env, and then try to figure out which of the options best fits our
> needs. It would be great if we could close the door on 'you can
> develop/deploy in these 10 ways' and just settle on one environment. 
>
> The fact that lots of 'stuff' is available in Torquebox right off the
> bat makes it very attractive - though there may be other reasons why
> it's a no go.
>
> So here's my list of runtime requirements:
>       * Ease of setting up a dev environment on important platforms
>         (Fedora, RHEL, OSX, maybe Windows) and of using it
>       * Ease of production deployment
>       * Stability for production (anything that's not stable in dev
>         isn't worth considering)
>       * Availability of gems/libraries/addon functionality
>
> David
>
>
>
>


Performance can vary greatly between ruby runtimes.

Also relating to production deployment, how easy it is to 'sell' the
platform, eg JRuby might be an easier sell in shops that have already
deployed Java, though MRI is seemingly the most popular Ruby interpreter
overall (though this is hard to gauge / quantify).

  -Mo



More information about the aeolus-devel mailing list