Rubinius Interview

Update: You can read more at rubinius in the ongoing rubinius serial interview:

• Rubinius Serial Interview: Episode III
• Rubinius Serial Interview: Episode II
• Rubinius Serial Interview: Episode I

Rubinius is a project that's been in a lot of people's sights (and sites) lately. From an article at InfoQ, to a donation from Geoffry Grossenbach, rubinius is making waves. I was able to corner Evan for an interview over email recently. Here's what we talked about.

---

Evan, thanks for agreeing to do this interview. Would you mind starting out by introducing yourself?

Evan: I'm a computer scientist who for the past 3 years has had the pleasure of working on ruby as my full-time job. Currently I work for a small company in Seattle called Lockdown Networks, building network access control appliances.

I began using ruby in 2002 while working as a system administrator. What began as using an elegant language for writing automation scripts became the desire to use ruby for all projects. Before ruby, I used quite a bit of C, Python and Perl.

And what about rubinius?

Evan: rubinius is a ruby implementation built from scratch. It is architected very similar to the original smalltalk-80 virtual machine, but takes a different approach to various things to make it easier for ruby. The idea behind the whole thing is that a simple core engine means a more powerful language. As little of the ruby runtime is implemented by opaque code or data in the engine, exposing even more of the whole runtime to the user to play with. A good example is that there is almost nothing that the user interacts with that are not first-class objects. That includes stack frames used to perform methods (called a MethodContext) to the methods themselves (all methods are instances of CompiledMethod).

You've been involved in the Seattle.rb for quite a while. What value does a strong, local Ruby community have?

Evan: I've found a strong, local ruby community to be indispensable for a few reasons.

1. Personally, it helps me bounce ideas off other ruby programmers and my own skill level increases.
2. Because the community is young, having a vibrant community that puts an emphases of development helps the entire community grow in skill level. That brings more people into the community and the richness of the community grows.

What kinds of things do you do to help foster that community?

Evan: As I said above, having a young community with a focus on development and inclusiveness really makes people feel special and important. It's that feeling that keeps people coming back each week. Each week, everyone is encouraged to bounce ideas off the group and ask for help.

For example, with rubinius, I've had people gather around my laptop as I explain how the internal parts of it work. I believe that that is going to help people get excited about rubinius and hopefully bring them to the project to help.

What sets rubinius apart from the other implementations?

Evan: I think that simplicity is what sets it apart. While it's still not the simplest program in the world, I believe it is vastly simpler than the other implementations. Simple has it's problems too though, there isn't nearly as much optimization, but when there is a simple way to add them, they will get added.

Have you been able to get anyone else hacking on rubinius yet?

Evan: I'm happy to report that I've handed out commit rights to second core developer, Wilson Bilkovich. He's been ramping up and already has made changes to the compiler and runtime. Interest has been growing in the past few weeks and more and more people are coming to me, asking how they can help. It's really quite amazing to see the ruby community all pitch in and help get this project off the ground.

Do you have a set of (fairly) simple tasks for a budding rubinius hacker?

Evan: I'm really working to try and get some simple tasks written up so that people have a place to dive in. With a project like this, it can be hard because a lot of the tasks like things like "Fix GC to allow for resizable memory use." I'm not always the best judge of whats easy for a newcomer either, and thus far it's certainly been a learning experience trying to manage how people can come on to the project.

But for people to dig in and start, all the code can be checked out of subversion (code.fallingsnow.net/svn/rubinius/trunk/) and can be built and tested to get people a feel for the whole thing. Instructions on building and testing are available at blog.fallingsnow.net/rubinius/.

There are 3 things I happily accept from anyone: patches, failing tests, and bug reports. In fact, if they submit all 3, they'll get a prize from me! (not sure what the prizes are yet, but I'll figure something out). All 3 can be submitted via the rubyforge bug tracker

That being said, one task that I'm really looking for is a cheerleader. I'm not the best self promoter as I've got a tendency to put my head down and just code, hoping that people are able to follow along. What I really need is someone who can help me get people excited about the project and help organize the tasks a bit. Anyone who is interested, email me!

What have been your biggest surprises (good and bad) in reimplementing Ruby based on the Smalltalk model?

Evan: I'd say that my biggest surprise is really how close the internal semantics of ruby are to Smalltalk. Before rubinius, I'd never really seen or programmed in smalltalk, just heard about it. But the more I looked into how the original smalltalk-80 interpreter was written, the more it sounded a lot like ruby. It diverges at a lot of places too, but the overall semantics are quite close.

I'm trying to stay pretty positive about the whole experience, making it as fun as I can, so I don't think there is a big, bad surprise. Maybe the bad surprise is how much fun it is and therefore how much my other projects suffer since I want to work on rubinius all the time. :D

During your presentation at RubyConf, you talked about this version being a 'cheating' prototype since you're writing the C by hand. What do you want to get ironed out in this release before you move on to the automatic translation of Ruby to C?

Evan: Currently, I'm doing a lot of hand written C work on the interpreter called shotgun, which is my hand recoding of the ruby version. I think that it's important that I have running code so that people who get involved with the project has something tangible to play with. So my plans for shotgun are to get all the biggest features that are necessary to make rubinius usable. My current TODO list covers most of them. At that point, rubinius will be running and hopefully quite usable. Then I'll begin the overall process of replacing the shotgun with code that is auto-generate from the existing ruby code.

That being said, I'm actually working on a tool right now I call cuby. It's a dialect of ruby that generates C code directly. It uses the same parser that rubinius does, but has a processor on it that generates C code directly using vastly simpler semantics that normal ruby. My idea is to use cuby to starting writing parts of shotgun in something that sort of looks like ruby. Then when I go back to to get translation, it will be a lot easier because the code will sort of in between C and ruby already.

What can you tell me about cuby?

Evan: The idea behind cuby is to provide a language that feels like ruby, and has a lot of the same semantics, but breaks them where it needs to. I would describe cuby as a 'system language'. The idea is that the code it generates is able to run standalone without any helper libraries to provide core functionality.

I modeled the original idea after pyrex, a tool for python that makes it easy to write python extensions in a python-like language that converts itself to C.

I want to cuby to be able to do the same, provide a simple interface/language for writing rubinius extensions. I for see that parts of the rubinius core will in fact use cuby to simplify development.

How does it compare to Ruby2C?

Evan: It's quite close to Ruby2C in idea, but it's simpler and cheats more. IE, you can hardcode methods to implements in cuby, so that you can say that "whenever someone calls method method 'to_i', I want you to call the C function 'convert_to_int', no matter what the receiver of the method is."

When do you think you'll be able to make a 1.0 release of rubinius?

Evan: It's still too early to tell. My hope is to have a version 1.0 of rubinius out by christmas next year, to coincide with the release of 1.9.1.

What do you think of the budding ruby on strongtalk and ruby on smalltalk efforts?

Evan: I think that they're excellent work and that the ideas and/or code that comes out of them will be useful to all implementations. At a personal level, I see it more as a way for smalltalk programmers to bring ruby libraries and such to their environment, a goal which almost all languages have (being able to interface to code written in other languages). I'll be the first on to admit that ruby shares an huge number of concepts with smalltalk, but it also differs from them in many ways. The current movement is to get the most basic of programs translated to run on smalltalk, but once they get to the more complicated ones, it might get a lot more complicated. That being said, it might be easy, there are some really smart and intrepid programmers out there that might make it work.

What do you think are the two or three most important things that can come out of the Ruby implementers summit/discussions?

Evan: I would say the first and foremost is a healthy dose of mutual respect. We all want our own implementation to succeed, but at the same time, we respect and work with individuals who don't share our exact goal.

Playing off the point on the same goal, we all do have the same, overarching goal, to see ruby succeed. And to that end we've begun to figure out how we can all help each other to achieve that goal.

Concretely, the establishment of the central test repository is big. It's going to mean that as we all move further down our respective roads, we're all able to maintain overall consistence for the users of our implementations. One thing that was brought up over and over again at rubyconf is the danger of fragmentation. I'm not so naive to think that it won't happen, and I'm sure it will. Fragmentation is a side effect of change and forward progress, it happens when one implementor decides that they believe that their way to do things is better than the current way, or that some currently missing feature is needed. By having tests that define the core ruby behavior in the form of tests, we can be help to avoid fragmentation in the core.

What facets of the other alternative Ruby implementations do you envy?

Evan:I envy the jruby developers for not having to debug segfaults, thats a biggy.

What Ruby development tools and libraries are you using as you work on things like rubinius and cuby?

Evan: One of the core libraries that is used is sydparse, a standalone ruby parser that I extract from my work on Sydney. It wraps up the parser from Sydney in an extension and provides a way to view the code as data using a version of ParseTree I got from Ryan Davis and Eric Hodel. It provided the basis for writing the compiler, since I wasn't currently interested in writing a ruby parser, since it's that step that has faltered quite a number of projects like this. In fact, I've extract the parser from sydparse and retrofit it to fit directly into rubinius so that for the time being, we don't have to write our own parser.

RubyInline also formed a big part of the prototype. I used to wrap a number of raw system operations, like allocating memory, read and writing values directly to address, etc. I built all of the objects on these primitives. That way, the prototype behaved a lot like it would when it's translated directly to C.

I understand that you're also using valgrind with rubinius. How are you using it?

Evan: We've started to use valgrind to validate shotgun, the rubinius engine thats in C and standalone from the normal ruby. It's an amazing tool thats provided us with a lot of information about programming errors in C code that could crash the interpreter. I suspect that in the future, we'll integrate valgrind into a daily test run to make sure that the code is continually tested for completeness.

If you weren't working on rubinius, which Ruby projects would you be tempted to get involved in? Why?

Evan: Well, I'm really interested in ruby building up library and tools so that it becomes an attractive platform for all kinds of developers, hobbyist to enterprise developer.

To that end, I've always been interested in DRb and encryption. I've got a partially started project that wraps an awesome C library called libtomcrypt to bring ultra fast, simple encryption to ruby as an alternate to OpenSSL.

If you're interested in making a contribution to rubinius, please paypal the money to PayPal to evan (at) fallingsnow (dot) net.