Yes. We just announced that we are doing our RC1 release, 1.0 RC1, so we are really excited we are finally at this point where Rubinius is complete enough, it's fast enough, that we really feel that people should start playing around with it and using it in their test environments and migrating hopefully to production.
2. How does the performance of Rubinius compare to the major platforms?
That is sort of the big thing we are working on. In a lot of cases it's sort of "hit or miss" depending on what the operations are. There is a lot of cases where Rubinius is a lot faster, there are some cases that it's a little slower and there are some cases that it's a lot slower. The idea is probably we are sort of building up our own benchmark suite that we are trying to get sort of on parity with 1.8, at least, before the big things, things like Rails benchmarks and all that kind of stuff. We are trying to hit at least the 1.8 performance, that is the general idea.
Yes. We haven't done a lot of socket optimizations, lot of IO optimizations which obviously you are going to hit a lot during stuff inside rack. From the other side in terms of things that we do better that Rails can use, we spent a lot of time doing a lot of String optimizations so that Rails are doing a lot in order to generate responses and all that kind of things. So just the dynamic features of Rails of the times can get in the way of some optimizations, but for the most part it's been pretty getting it complete enough for all the nooks and crannies that Rails happens to use.
4. There is this thing called RVM, does Rubinius play nicely with that?
Yes, Wayne has kind of been cranking on it and he showed up in the Rubinius irc channel in one day and said: "Why don't I make it work with Rubinius?" and we've been working kind of closely with him the last couple of weeks.
5. So that is close, but not quite there?
Yes. You can do that right now. He's got it in the release, it's out right now , you can do RVM install Rubinius, and right now the JIT isn't compiled in by default, but it's on by default if it's compiled in. So you have to do RVM install Rubinius --jit to actually compile the JIT in.
6. What is a JIT for some that might not know?
The JIT is basically a way of taking the Ruby code and compiling it down to machine code, at the runtime when you actually need to run it. So normally inside a high level language like Ruby you'd implement an interpreter which is just 'read operations and perform them'. The JIT allows us to read those operations sort of statically, compile them out to machine code and then run that machine code right away. It's a way of taking the performance of Ruby to the next plateau.
It puts us probably ahead of Python; Python doesn't really have any kind of JIT research that goes on right now. They've had one sort of stalled; they have one right now that is called Unladen Swallow that is sort of similar to Rubinius. They are working with LLVM to make a JIT for Python. Other dynamic languages, like Smalltalk, is right up there in terms of the evolution that the way they went. Smalltalk JITs just have existed for 10-15 years, at least, and this is sort of the path they all take. In terms of the performance of Ruby with the JIT versus other languages I would expect it to be right up there now with the JIT turned on, but that is something that we have to look at specifically.
8. Is Rubinius a feature of the Ruby platform as far as you're concerned?
I hope it's a vital player in it. We are doing a lot of things that a lot of people have talked about doing for a long time that we are finally sort of bringing to fruition. I definitely see there is a lot of potential for the direction that we are taking it.
Yes, that is one big thing that we've had since the beginning of the project. We wanted to write as much of it in Ruby and therefore make as much of it expressible to the user. The bytecode compiler for Rubinius is all written in Ruby; the user can actually go in and add to it or kind of tweak it to do whatever they need to do.
11. So what's in the immediate future, in a couple of months, as RC 1 is released?
RC1 comes out next week [Note: this was taped at RubyConf 2009] and then we are planning on doing RC releases every month as we sort of stamp down 1.0, getting closer to that 1.8 performance goal and getting as close as we can to the full release 1.0. We have some specific applications that we are trying to make sure run smoothly for RC 1 and all the other RCs and then the idea of an RC1 is to tell people: "Hey, it's ok now to basically file bugs that my gem doesn't work". I really hope that our ticket load goes sort of through the roof, because that tells us now: "Before we've had 50 tickets, now we have 500; how do we want to subdivide these, we need to categorize them and then basically break them up by RC". In my opinion that is a lot of work but that is really the best case scenario, because that lets us know what the community needs us to do.
I don't know, time will tell. The nice thing with the tickets in the system is that if we have those tickets 'I try to do XYZ and it doesn't work', we've got a pretty big developer community that I sort of encourage them at any time if someone found that's something real trivial, fix it, commit it, be done with it, let's go on.
Yes. We intend that for 99% of all C extension gems to work. We've got specific edge cases that we are avoiding. There are sort of 2 camps for extensions, there are certain features that we don't yet support, we will support if a lot of gems use them, but we haven't yet seen them. There is another class of features that we can't support. Almost no gems use them; they are things that are really the lowest level parts of 1.8, things like Ruby frame and that kind of thing that are how that specific interpreter works.