

Rubinius 3.0 – Part 1: The Rubinius Team - jc00ke
http://rubini.us/2014/11/10/rubinius-3-0-part-1-the-rubinius-team/

======
LogicWolfe
I've been using HN regularly for 5 years and this is the first time I've ever
felt inspired to comment. I am incredibly impressed with this approach to
community building. I think we need to see a lot more things like it in both
the open source community and the tech sector in general. Thank you.

------
pmontra
Prompted by this post I tried to run my latest Rails 4.1 app with Rubinius.
It's been a long time since I wished to give it a try.

I had to comment out some gems which don't work with Rubinius, all stuff I use
only in development (byebug, binding_of_caller, did_you_mean). There is a
Rubinius debugger but I didn't try it
[http://rubini.us/doc/en/tools/debugger/](http://rubini.us/doc/en/tools/debugger/)

I had to remove the space after the arrow in lamba definitions like -> ()

Then I run rake spec. I bumped into a few show stoppers here.

One is due to some compatibility issues with the mail gem. There is an open
issue on GitHub about that and it should be fixed in the gem. In general, if
gems don't support Rubinius reliably we can't use it. And if we can't use it
many gems won't have an incentive of testing against it.

The second one is that I got an overall feeling that Rubinius is slow. The
examples include many integration tests with capybara and the js driver.
Rubinius runs them in 7 minutes and 13 seconds (with spring) without the ones
that failed. RMI 2.1.4 runs them in 1' 54" (all examples green). Maybe it's
slow only for this kind of workload but such a difference in testing is hardly
bearable. Too bad.

~~~
dasil003
On the other hand Rubinius implements native threads, which means for
parallelizable workloads you get a potentially equivalent performance gain to
the regression you are talking about. Currently the only way you can get this
is JRuby (which of course comes with own its own JVM pros/cons).

I'm not using rubinius yet either, but I think there is already a compelling
case to take a serious look at it.

~~~
pmontra
That's also what I was thinking but I'm a little wary of using something in
production which I don't use in day by day development and I run tests against
it only a few times. It seems a recipe for letting bugs slip into deploys.

By the way, I googled a little and removing simplecov shaved a couple of
minutes out of the rake spec times. Still too slow and very inconvenient, even
if I can still use simplecov with MRI thanks to conditionals like if
RUBY_ENGINE == "ruby" ... end

------
ioddly
Good to see rubinius is still chugging along and doing things its own way. A
while back the IRC channel was the place for a lot of interesting PLDI
discussion.

------
lizzard
What a great post. Not only the open commit policy but the comments on
diversity and merit. Thanks for writing that (and for practicing what you
preach!)

------
oms1005
Awesome work, Jesse! Huge fan of rubinius, keep it up.

------
VeejayRampay
Best of luck to everyone involved, your work on Rubinius is extremely
important to foster competition and improvements in everything Ruby.

------
zaid_brilliant
Really nice to see Rubinius progressing. Looking forward to 3.0.

