Rubinius 2.0 Preview Release

http://rubini.us/2011/06/07/inside-rubinius-20-preview/

by ichverstehe • 15 years ago

100 39 15 years ago

andrewvc2• 15 years ago

Awesome, the great thing about rubinius is playing around with the internals, since they're mostly written in ruby. The C++ core is quite tiny actually.

senthilnayagam• 15 years ago

muti-core support is interesting, installing now on my mbp

ssmoot5• 15 years ago

Obviously great news. It dampens my enthusiasm a bit to know the same company funds development of JRuby however.

EngineYard really should clarify their vision behind maintaining two VMs. Going beyond the obvious "JRuby is for integration with existing J2EE infrastructure" angle would be nice.

Under what circumstances would they actually stand behind Rubinius as the better choice? Is the MRI C extension API compatibility an official feature now? Is it that I could switch from REE to Rubinius without having to worry about finding alternatives for all the libs I'm using that carry C-extension baggage?

tptacek3• 15 years ago

This is confusing. JRuby is a great and important project. It's how a several very large Rails apps ship deployable versions of their product; it's the easy way to get a Rails app deployed in shops where the normal mechanism for getting deployed is "submit a war file", and it's how you get Ruby access to a zillion Java libraries.

Rubinius is a native implementation of Ruby that seems, over the long term, to have a goal of being the best single implementation of the language all other things being equal.

Why would I ever want to penalize a company for funding both of these awesome projects?

ssmoot5• 15 years ago

I didn't say anything about penalizing.

Microsoft clearly differentiates versions of SQL Server. That's all I'm asking for.

If JRuby performance continues to match or exceed Rubinius performance, but JRuby also gives me deployment flexibility and Java OSS integration options Rubinius doesn't, why would I choose Rubinius for my next green-field project?

That's not an accusation. It's a serious question.

I think Evan's answer on the Ruby C API is a pretty compelling reason on it's own. For businesses that don't have an easy JRuby migration path because of dependencies on multiple gems with C-extensions, maybe Rubinius is a much easier way to get into the next JRuby/Rubinius/YARV Ruby performance bracket.

That can be very compelling on it's own. What are some other reasons I might consider Rubinius?

Given the down-votes I guess I'm in the minority, but I think it's a fair question.

I was an early supporter of Rubinius, and put my money where my mouth was on more than one occasion with cash donations to the project.

I get that it's very neat from an academic standpoint. No argument here. Is it something EngineYard is going to stand behind and just as importantly, start marketing so I get a good feel for the practical uses?

sandGorgon• 15 years ago

I'm not sure if what I'm thinking is correct (or even technically possible) - but couldnt it be possible that what they are envisioning is the Rubinius architecture being the one true Ruby and having two backends : C-Rubinius or Java-Rubinius.

What it would mean is that the C-Rubinius and Java-Rubinius releases be simultaneous: you can choose to pick one or the other based on your surrounding stack.

This would mean that they fund both Jruby and Rubinius till they can be merged.

evanphx• 15 years ago

The MRI C extension API compatibility is very much an official feature. Except for a few gems we can't make work (because they tie directly into 1.8's execution model) most work fine. If you have one that doesn't work, please just open an issue and we'll figure it out!

ssmoot5• 15 years ago

Very cool.

Been a long time coming, with a lot of blood sweat and tears on your part, but it looks like Rubinius2 is the project I was lusting after those years ago, back when it looked like Sydney was the fix for what ailed Ruby. ;-)

Congrats on the milestone!

krohrbaugh• 15 years ago

Engine Yard's objective is to drive Ruby adoption as a whole. Everything they are doing with open-source aligns with this.

Their current strategy seems to be based on three observations:

1. There are a lot of Windows users in the world and Ruby sucks on Windows.

2. There are a lot of existing companies using Java still and many are scared of Ruby.

3. Even if people get past 1 & 2 a lot of people are still scared off because "Ruby/Rails Doesn't Scale" (i.e., MRI is slow).

They are executing against all three of these barriers with their various initiatives:

1. Make Ruby a better platform on Windows: Rails Installer, SQL Server ActiveRecord adapter and including Windows as a target platform for their VMs.

2. JRuby as a gateway drug to the Land of Ruby; _could_ end up being VM winner too.

3. Rubinius as a possible MRI replacement, if they can make it technically superior and rally support within the community. (Think Merb -> Rails 3)

With this in mind, it makes perfect sense for them to support both JRuby and Rubinius.

It also makes sense for them to not be too overt about at least some of these goals. (See Merb vs Rails compared to SlimGems vs RubyGems.)

ssmoot5• 15 years ago

> JRuby as a gateway drug to the Land of Ruby; _could_ end up being VM winner too.

I don't get the "could". JRuby is among the fastest, gives you access to a massive amount of OSS and infrastructure, and fixes Ruby's threading.

It's done these for years at this point.

In my mind the question is more along the lines of "why should I use anything _but_ JRuby on a new project?".

It's blasphemy I'm sure, but I just don't see the point in C-Ruby for new development at this point. It's legacy. JRuby, as the last-man-standing among the major Ruby VM implementations now that IronRuby is dead and everything else is vapor (Maglev) or niche (MacRuby) is the default modern Ruby implementation to my mind.

So let's assume Rubinius is great, and the GIL is clearly a major step forward. Is EngineYard's intent really to supplant YARV with Rubinius?

Because that sounds great to me.

I've never seen EY say that though (they might have and I just missed it). If that's the vision, I'd rather see them come out and say it. Having developers guess, and having any ambiguity at all around the future of these projects and the messaging surrounding them doesn't inspire confidence.

bad_user3• 15 years ago

     Is the MRI C extension API compatibility an official 
     feature now?

Yes, because there's lots of code out there that's targeting that API and you don't want to throw good, stable and tested code away.

    without having to worry about finding alternatives 
    for all the libs I'm using that carry C-extension 
    baggage

It's not really baggage that you don't want. It's only baggage in the sense that backwards-compatibility makes forward progress harder, but if you can come up with a way to maintain compatibility with an emulation layer of some sort, than that's the best of both worlds.

    EngineYard really should clarify their vision behind 
    maintaining two VMs

It's not EngineYard's business to clarify their vision behind these 2 VMs, as both projects were started outside of EngineYard. This company is doing the Ruby community a favor by paying developers for working on these 2 projects, but the projects themselves would go on without EngineYard.

mark_l_watson• 15 years ago

As a Ruby developer, it is important for me to have options on deployment and also support for using large C/C++ libraries (e.g., Redland RDF) or large Java libraries (e.g., machine learning, Sesame RDF, etc., etc.)

Great to have MRI C, Rubinius, and JRuby.

MartinMond• 15 years ago

Is running Rails on Rubinius 2.0 still slower than on MRI 1.9.2? I hope not, but I need MRI 1.9.2 as a baseline (and yes, MRI is itself horribly slow)

headius11• 15 years ago

Only one way to find out :)

fijal2• 15 years ago

According to my very unscientific measurements (I didn't bother looking which files are potentially auto generated), I got:

  182kloc of C (.c files)
  110kloc of c++ (.h + .cpp files)
  558kloc of ruby (.rb files)

That puts C/C++ at roughly 40% of total. Unless proven otherwise I would say "ruby written in ruby" is a bit untrue.

headius11• 15 years ago

Your numbers are odd.

I would discount the .c code. Rubinius's native code (excluding third-party code) is largely C++, so better to focus on .cpp and .hpp files.

The .rb count is way higher than what I got. The line counts I got (on master, not hydra):

vm / {cpp,hpp}: 162kloc

kernel / rb: 31kloc

lib / rb: 145kloc

Oddly enough the total ratio is roughly what you came up with, but I'm not sure where your numbers came from.

It's worth noting that the density of .rb source is considerably higher than that of .cpp source; a few lines of .rb can do what might take dozens or hundreds of lines of .cpp. I wouldn't fault them based on LOC; Rubinius is still implemented more in Ruby than any other implementation out there.

Let's say .rb is conservatively worth 10LOC of C++. That puts them at more like 10% "not Ruby", going by the amount of work they get done in each language. Even if you only consider kernel / rb versus vm / {cpp,hpp}, the 10X ratio means they're less than 1/3 "not Ruby". That's pretty good.

fijal2• 15 years ago

I just counted everything including stdlib and whatnot (all that comes in the checkout). "Rubinius is still implemented more in Ruby than any other implementation out there." well that's probably true, but not really useful. If all ruby implementations had 0 lines of Ruby and Rubinius 1 would you call it "mostly written in ruby"?

10X on LOC count is bogus, just because it's a single number. It does depend on what you do, it might end up being that, being more or being less, essentially [citation needed].

Anyway, even assuming this odd coefficient, I wouldn't say 1/3 "not Ruby" is "pretty good", although "pretty good" is not a precisely defined term, so we're free to agree to disagree on that. Given the same assumptions you can say CPython is written mostly in Python (10x Python-vs-C, including all the library code).

Rubinius 2.0 Preview Release

Related Stories