This time around, we're talking about cooperation between JRuby and rubinius developers. It's a timely topic, since Nick Sieger is starting a Serial JRuby Interview. Good times.
Evan wasn't available this time around ... I understand he's in seclusion working on rubinius' Garbage Collection. I'd rather have him get that right than respond to these — I think you'll agree.
I've been really excited to see all the discussion between the JRbuy developers and rubinius developers -- in fact, Nick Sieger (who's been hanging around in #rubinius) is now a committer for the JRuby project. What benefits do you see coming from this kind of cooperation?
Wilson: It's a pretty good time, really. JRuby people share cool optimizations from Hotspot, and Rubinius people scour the net for research papers to steal from. I hope to see the two groups collaborate on RCRs over at http://rcrchive.net I think everyone agrees, for example, that the class variable behavior in Ruby 1.8 is insane. As we get around to implementing 'rough edges' of Ruby, we are going to write up requests to smooth them out. Hopefully Nick will vote for mine, and I'll vote for his. Heh.
Nick: Well, certainly we hope to all mutually benefit and better each others' efforts. I think it's significant to see such a deep level of cooperation and comraderie from two teams with similar goals. We could compete against each other for the title of fastest or most fully-functional ruby implementation, but the friendliness of the Ruby community for one seems to have a big effect on our working together.
If you could get the core Ruby and alternative VM implementers together for a week, what issues would you like to see them focus on?
Nick: Being new to the implementation game, with no examples gained from first-hand pains re-implementing Ruby that need to be improved, I would say the first thing to do would be to just brainstorm and agree upon a top-N list of things that need to be fixed. Several areas of Ruby need whittling back and don't have to be so complicated. Re-examine the most common usage patterns and "say no" to those edge case features that have little value.
If I were to try to name specifics, some of the things going around IRC lately are threading/concurrency (needs to be easier to do right and do well) and language features that are too intertwined with the parser/syntax tree ( e.g., "defined?") that make implementors' lives difficult.
Wilson: I think that week could be profitably spent writing test cases and working on the spec framework. A comprehensive set of executable specs will help everyone.
Alternately, we could all get drunk and read through the JVM Hotspot source code.
The biggest news in Ruby land right now is probably the announcement of a fully merged YARV. What effect does this have on rubinius?
Nick: Well, it's more visible fresh blood, that should be more accessible to Ruby hackers. Hopefully some of the cross-platform compilation and execution issues that exist will go away soon and make it easy for Rubinius and JRuby hackers to steal — umm, incorporate more ideas that might allow for more implementation sharing in the future. For example, a shared or compatible bytecode.
Wilson: I think it means the race is on. Heh.
One tricky aspect is that YARV is targetting 1.9. JRuby is aimed at 1.8, while Rubinius is forming up on something like "1.9 transitional". By that I mean that we sometimes take the 'low road' and implement things in a way that is compatible with existing code, but perhaps not the letter of the ruby1.8.5 law.
An example: the defined? keyword in Rubinius returns true or false. Ruby 1.8.5 returns a string or nil.
That sounds like an incompatibility, but it turns out that every scrap of public Ruby code uses defined? as the condition of an if/unless statement. True or false works fine, and is a lot easier to implement.
I'm not sure if that makes Rubinius an 'Opinionated VM' or not. I know that I'd rather get a feature working and move to the next one than spend a week on all the implementation details from 1.8. We can get our heads together later and decide what the real Ruby Spec is.
This episode is brought to you by: Code Craft
Previous episodes of the Serial Rubinius Interview are available here:
- Episode 1, in which we talk about the rubinius community
- Episode 2, in which we talk about cuby and testing tools
- Episode 3, in which we talk about rubinius documentation
- Episode 1, in which Charles, Thomas, and Ola talk about their plans for JRuby.
No comments:
Post a Comment