Rubinius 3.0 – Part 1: The Rubinius Team(rubini.us)
rubini.us
Rubinius 3.0 – Part 1: The Rubinius Team
http://rubini.us/2014/11/10/rubinius-3-0-part-1-the-rubinius-team/
10 comments
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.
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/
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.
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/
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.
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.
I'm not using rubinius yet either, but I think there is already a compelling case to take a serious look at it.
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
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
"native thread" is just buzz word if the implementation cannot boot rails. On the other hand, if you don't feel like to use real multithread now, it's unlikely you need it in the future.
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.
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!)
Awesome work, Jesse!
Huge fan of rubinius, keep it up.
Best of luck to everyone involved, your work on Rubinius is extremely important to foster competition and improvements in everything Ruby.
Really nice to see Rubinius progressing. Looking forward to 3.0.