

Rubinius 2.0 Preview Release - ichverstehe
http://rubini.us/2011/06/07/inside-rubinius-20-preview/

======
fijal
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.

~~~
headius
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.

~~~
fijal
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).

~~~
headius
Well, I suppose I go by the following guide:

* stdlib is library code, not core VM code. It shouldn't be counted. * Percentage of _functionality_ of Rubinius's core implemented in Ruby is definitely higher than percentage of functionality implemented in C++, at least for the core Ruby classes. Hard to quantify that though. * Rubinius's VM _is_ basically all C++. I will concede that.

------
andrewvc
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.

------
ssmoot
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?

~~~
tptacek
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?

~~~
ssmoot
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?

~~~
mitchty
For my needs, jruby will never suffice as java isn't going to be installed on
the servers I'm on. Nor to be honest would I want it, and JNI for c extensions
is also a nonstarter. We have puppet at work for server deploys, and well,
jruby may suffice for web/app server deploys that just run rails. But not all
ruby users actually give a rats about rails (that's me, don't use it at all at
work), nor do we have a need for java interop. Basically I'm in the exact
opposite of your vantage.

I need c bindings for a few gems I made that need c ffi bindings, I don't
need/care/use any java interop, and personally, I'd rather not have the jvm
running on any of my servers.

I look at rubinius as the eventual YARV for the compiled version as YARV was
to MRI, not as an academic project. But I admit, I seem to be a ruby outlier
ever since rails has been around.

~~~
headius
Your reluctance to install Java on the servers you're on means you're missing
out on one of the best Ruby implementations available. You'd be well served by
putting aside your prejudice and just giving JRuby a try.

That said, there's certainly domains where JRuby is not a great fit. C
extension-heavy systems are one; because C extensions are so crippling to more
modern VMs like the JVM or Rubinius, you're better off using the
implementation the C API was designed for (MRI). Or if Rubinius suits your
needs and C extensions work well enough, I'll recommend Rubinius over JRuby
any day. I hate C extensions, or at least I hate them in the form they exist
in MRI, since they're invasive and damaging to modern VM features like good GC
and concurrent threads.

In any case, it's worth seeing if FFI (the Ruby API that Rubinius pioneered
and JRuby made generally available) serves your purposes, because it works
extremely well in JRuby and requires no C extension support. And I'd suggest
you actually give JRuby a try; it's so much more than "Ruby for Java interop"
and may work better as a "plain old Ruby impl" than you expect.

~~~
tptacek
I just used JRuby FFI to implement a native x86-64 debugger on WinAPI; we had
x86 working for a long time on Win32, Linux, and OSX using MRI, and JRuby was
actually the _only_ way to get around LP64 issues with MRI. JRuby has been a
compat and native code win for us; it is a better platform for accessing C
code than MRI Ruby is.

~~~
abrandoned
Huge fan of FFI (I use it to wrap/test all my shared libraries, mysql ext,
etc..), but the problem of cross platform compilation still exists. I write a
shared library and an FFI interface, but packaging it for use on Windows/*nix
is still a pain (for compilation during install). Is there anything that
solves for compilation across implementations and platforms? (FFI makes the
interface simple after that)

~~~
tptacek
I don't think we should have to sign up for coupling with a specific Ruby's
runtime internals just to get cross-platform compilation of a shared library.
For whatever it's worth, even autoconf can be made to work cross-platform.

------
MartinMond
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)

~~~
headius
Only one way to find out :)

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

