Well JRuby itself started in about 2001. A guy named Dion Arna Peterson and a couple other folks wanted to see if they could at least come up with a Ruby parser. And once they managed to port the parser over using a Java equivalent to Bison, they figured, okay, well, we've got a parser. We can probably do a Ruby implementation as well. And the project kind of worked its way along for a few years, got some basic things working. In around 2002 or 2003, Tom Enabo, the other co-lead of the project, started working on it. And various other Ruby folks have appeared in the commit logs over the years. I actually came to the project in about 2004. I went to the RubyConf that year, which was in Reston. It was only about 65 people back then. And I only was there because someone recommended the language to me. I'd never actually seen it before. But being a Java guy, I wanted to see if there might be a JRuby project of some kind out there. And it turned out there was. And Tom, a friend of mine who I'd worked with at the university years before, was currently running it. So that's kind of where I got started on it. So you said you were doing Java before and then you learned about this JRuby thing.

Or you said there was a conference. Yeah, it was really RubyConf that kind of got me into it. The thing that I realized was that JRuby, or Ruby the language, was pretty much the first time I'd been to a conference for a language I didn't know. And I recognized all the code. I was able to understand all the examples. And it was, it drew me in. I thought that this would be a great language to learn and play with. But the only way I was ever going to be able to do that as a Java guy or as a Java lead developer was to find a way to run it on the JVM.

Or did you try to use it and find things that it didn't do that you needed and you started contributing that way? Well, I played around with it first a little bit just to try out some Ruby examples. Quickly realized that there were things that I could do with regular Ruby that I couldn't do with JRuby. Even trivial, basic things like at the time IRB didn't work. Rake didn't work. Standard tools and commands that you would run on a standard Ruby implementation didn't run. And so I was interested in trying to contribute and help out with the project. Okay, so you started from where a lot of people start. There's this thing out there, you like it, but it doesn't do X, Y, and Z, and you started to fix that. That's right. Actually, you might need to edit this. I've got a baby monitor that's very loud at the moment. It's okay. From where we left off, it sounds like you came to JRuby the same way a lot of people come to open source projects. That you started using it and it doesn't do X, Y, and Z, so you start to fix that and implement it yourself. And I guess you must have really fallen in love with it at that point. Yeah, well, I never actually thought that I'd be interested in implementing a language, but it turned out that there were so many interesting problems to solve that needed to be done. And I thought the potential of Ruby on the JVM was huge, to be able to use a nicer language, to be able to fall into Java libraries, to have access to all the Ruby world. It's been a labor of love for the past seven or eight years now. And I had actually worked previously on another open source project called LightStep. Again, a project that had kind of gotten quiet, not a lot of people working on it, but I was interested in it. It was a replacement for the Windows Explorer desktop. There were a number of those back in the late '90s that people were working on. And I kind of got involved the same way there. I wanted the project to move forward. I wanted to be able to use it and do more with it. And the code base needed a lot of work. So it seems like one of my favorite projects is to jump into an open source project and start cleaning it up and make it work a little better.

Well, I guess I wouldn't officially have been considered a co-lead for at least a couple years. In 2005, I started getting into the code base a little bit more, trying to figure out how we could speed it up. Did several rewrites of the interpreter. I started doing some profiling, looking for the problems that were slowest, the areas that were the slowest in JRuby. And then into 2006, we started really working in earnest on getting all the standard Ruby libraries to work, IRB, Rake, RubyGems. Started drawing in other folks to work on it. And probably about that point that it kind of became apparent that I was putting in a lot of time. And I was as much in charge or as much invested in the project as Tom. So we kind of decided that we'd be co-leads from now on out. Okay, cool. Jumping fast forwarding to now, there seems to be a lot of concern with the refinements issues. And you've expressed a lot of concerns over that, or at least well retweeted and reblogged concerns. It's kind of an interesting predicament that you're in, having created this, or work, excuse me, working on this project that is tightly coupled to another implementation. And when it changes in order to maintain compatibility within the language, you also have to change.

If it gets to be so onerous to implement these changes, I don't know, obviously, what the actual details are. But if it gets to be so onerous, are there plans maybe to even fork off JRuby and have it be its own dialect in the future?

Yeah, as a compatibility project, which is essentially what we are, we're just, by and large, trying to mimic the standard implementation of Ruby. We are beholden to them as far as new features that come in, things that we need to add or things that we need to update. So there's been a constant catch-up. I mean, we're always slightly behind them as far as getting new features in, getting fixes in. The big change that we had, the big work that we had over the past few years was catching up with Ruby 1. 9 support, which was a massive number of changes. Especially regarding string encodings and, to some extent, some threading details. But we feel like we're kind of at the point now where, by the time Ruby 2. 0 comes out, which is supposed to be February sometime, we will be in a position to maybe do a release soon after that that has all the same features. Mm-hm. Having caught up with the big milestone of 1. 9, changes in 2. 0 aren't too bad. The other issue is if we have problems with the features or if there's an implementation challenge that comes along with them, as there are for some aspects of refinements. There's been a lot of talk about the Ruby design process lately or potentially lack thereof. But for the most part, we've seen that if we raise issues about specific features or aspects of those features to the Ruby core folks and to MOTS himself, they've been very receptive to make improvements, make changes. They also want to be able to optimize the C implementation of Ruby into the future. We are kind of ahead of the curve as far as optimizing Ruby and we know what challenges they might run into. So they've actually been very receptive when we say this aspect of this feature is very difficult to optimize or you're going to run into trouble down the road. So for the most part, it's been a very communicative relationship with the Ruby core folks. So they understand that we have our own challenges implementing Ruby and that we've met some challenges that they might have in the future. Is there been any talk though of -- actually, I'm not going to go down that path. I was going to ask instead -- with regards to the future of JRuby -- sorry. I was going to ask a question about forking off the language again, but that's -- I'm going to edit this. Sorry. I was going to ask a question about forking off the language, but instead I'm going to focus back on the community. So when you were talking about working with Matts on trying to make sure that they know some of the things that you've already experienced so that way when they're making their optimizations, it'll also be a little bit easier for JRuby to implement those as well and also avoid some of those same pitfalls inside of CRuby. It was kind of funny when you were talking about the process that the Ruby team goes through. The other day I was listening to Ruby Rogues with Aaron Patterson and he was comparing the Rails release process to the Ruby core process for releasing. And he was saying that the Rails process is so loosey-goosey compared to the Ruby. And it sounds like you're saying that, from your experience, the Ruby process seems to be a little bit something to be desired in the way decisions are made.

There is a process. There is a fairly clear process that the Ruby core folks follow. The problem is that it's also bound up with bug fixes that are really CRuby specific. So for other implementers trying to track what's actually going on as far as feature design, new features, specification changes, we have to sort through all of the MRI seg faults or memory leaks or whatever else, which are the bulk of traffic on the Ruby core mailing list and the bulk of traffic in the bug tracker as well. So there is a process that's kind of buried within MRI's day-to-day development process. It takes a little bit of work to sort that out. And we're actually going to try and work with Aaron and some of the other Ruby core folks to separate the parts of the process that are interesting to other implementations away from what's specific to MRI's code base. Now I have to ask, have you had to learn how to read Japanese in order to more effectively contribute? There will probably be a big help. There are a few English speaking folks in the Ruby development, Ruby implementation community like Aaron that do know some Japanese. And it definitely greases the wheels of talking about issues. But to their credit, the Ruby core folks have also made a major effort to try to do all of their bug discussion on the standard tracker in English. Try to do most of the discussions about features on the English Ruby core list in English. There are Japanese folks who are not as strong in English and sometimes we have to sort that out or that don't know English and sometimes we need a translator. But in general, communication is steadily improved even though most of the core team is Japanese.

And you know, you've also, you're giving some advice back to the CRuby implementation, but you've also had an interesting article talking to the Clojure community. Basically, I can't remember the exact title, but it was, it was some optimization or invoke dynamic if you want, you want it if you want Clojure to be awesome or something along those lines.

Oh yeah, absolutely. I've been keeping track of all the key JVM languages and new and upcoming ones. My other role is kind of some sort of JVM expert. And so I'm keeping track of invoke dynamic, especially for JRuby and dynamic languages, who's using those features, upcoming features in Java 7, 8, 9. And really the role that we've moved into now that we're at Red Hat is part of a general JVM polyglot group. So it's not reasonable to think that as JRuby 1. 7 settles down, as we get a couple maintenance releases out, that I or we may turn our attentions to helping do some of the same things for other languages. See if we can help with invoke dynamic stuff in Clojure, see if we can get Jython up to date as far as performance and competitive with JRuby and with CPython. Little bits and pieces of different language implementations that could all be improved based on what we've learned from JRuby.

And, you know, there's one other kind of pillar in this that you have to deal with because like JRuby is an implementation or you said it was an implementation language that was based on Ruby. So it's dependent upon what Ruby is doing, but you're also a little bit dependent upon what the, well, I was going to say Sun, but Oracle is doing with Java. But is that kind of a red herring now that there's OpenJDK and it's, it's pretty stable and well, well supported? Yeah, I've, I was skeptical at the beginning, like most people when Oracle took over Sun, but cautiously optimistic. I knew that there was a large, very open source oriented team on the OpenJDK side that was going into Oracle and that they were not going to be, they were not going to compromise their ideals for open source. The OpenJDK community has continued to grow under Oracle and actually a lot of issues under Sun have been cleaned up. Uh, we've been very happy with the direction that Oracle's taken with OpenJDK, at least as far as what features they're working on, what they find important. Uh, part of the evidence is that they have a whole team of folks working on a JavaScript implementation, NASHORN. And that team is considered part of the hotspot VM group because they want both the fast JavaScript implementation and they want to make changes at the JVM level for languages like JavaScript. Oh, okay. So they've prioritized polyglot and multiple languages, perhaps even more than Sun did. Oh, wow. So yeah, so the future is bright for, for developing on the, on the JDK. Yeah, I think so. They, they seem to have the priorities in the right place. Okay, great. Um, now focusing a little bit more on what you do, uh, teaching and, and going and speaking. Uh, obviously there's the JRubyConf.

I've, I've been pretty hands off. Uh, it's, organizing real world things has never really been a drawn suit for me. So I, there, there are other folks who would do better jobs of, of organizing conferences, but we will do things like, uh, try and get keynote speakers. Try to look for interesting talks, uh, review talk submissions, uh, help, or, you know, arrange, or help, uh, decide on arrangements, places we want to do the talks, or where we want to do the conference, so on. Uh, but for the most part, we've been hands off with that. We have tried to, uh, provide some baseline support, and try to arrange some monetary support from folks who are friendly to the JRuby Project, to whoever ends up organizing the conference. Um, so, yeah, for the most part, it's kind of a go and hang out thing, but a little bit of upfront planning.

Do you mostly go and work and say, "Okay, this is what I've been working on, so I know this inside and out," or do you do slides and things like that?

Well, I have slides, but I almost always prepare, like, the day or two before I talk. It's all stuff that I know. I know JRuby pretty much inside and out. Uh, I have dozens of different demonstrations that I can do. Usually what I'm doing, as far as presenting JRuby, is trying to figure out the audience, which makes it easier if I haven't prepared the slides already. Figure out the audience, what they would be interested in hearing about JRuby. Uh, standard Ruby groups would be different from a standard Java group. It would be different from a general development group. And then tailor the talk to features or aspects of JRuby that they would find interesting, and that would help maybe make them more interested in running JRuby. And, so, and you're also, uh, spanning two communities. The Java community, which has its own kind of style for conferences and groups and community, its own definition of community. And then, and the, and the Ruby community, which has its own, um, definitions. Uh, has there been any, I don't want to say, do you like going to one better than the other? But, uh, you know, if you, if you were to answer that question, I would, I would be okay with that.

When you're going to present, um, at a Java community or, uh, events or, versus a Ruby, is there, is there any like discernible difference between going to those two different, uh, types of, of, of events? Oh, absolutely. Um, I, I will say, and I've, I've said it before, I do like going to Ruby events better, mostly because the folks that are at Ruby events are looking for something new. Uh, in almost every case, they're, they're looking for a new way to scale their app or a new way to, uh, implement some service. But they're, they're looking for change. They're looking for something different than what they've done. You go to Java events, people are, are much less interested in trying something brand new, trying some new feature, new language, uh, as they are just, like, plain productivity.

Uh, more, more business oriented, more money oriented. Use JRuby. Yeah, exactly. And that's, that's the thing. When we go and talk to, uh, a Java conference, the, the challenge for us is showing how you can build your apps quicker using Ruby. Mm-hm. It's not really a JRuby talk as much as it is trying to sell people on Ruby and Rails and other libraries in the Ruby world. Obviously, that's totally unnecessary. At a Ruby conference, they're already sold on those things. Mm-hm. So, we're selling the JVM. We're selling JRuby. Uh, we're trying to show them how this is going to make your Ruby applications better. Faster, more fun, and so on. So, completely different approaches. And we, we do have very different decks of slides that we use for the two different communities. And, and for people who might be interested in contributing, or trying to help out, or at least get into JRuby, maybe understand the internals a little bit better. Is, is, is there any advice you have for people who are looking at JRuby and saying, "Oh, how can I get involved? " Well, we do have some articles on the wiki that talk about how JRuby is structured internally, the basic design. Uh, some articles on specific subsystems, like how the compiler works, how the embedding API works, uh, to kind of get people bootstrapped on that. I am also hoping to do, sometime this month, a couple of blog posts on how to get your foot in the door, where all the pieces are, uh, for somebody who's never looked at this kind of project, how to contribute, how to get involved in it. Uh, it's, it's, it's a large project, but it is fairly well broken down into subsystems. So, if we have somebody who's interested in compilers, they can do this section. If there's somebody who's interested in crypto, we have the whole crypto subsystem. So, just, uh, the easiest way for folks to get involved now would probably be looking for easy bugs, or looking for refactoring opportunities. Uh, pieces of code that look like they could use some cleanup. Uh, it's how I've gotten into other projects, including LightStep, is basically just doing some cleanup and rewrite, so that the code is easier to manage. Which, at the same time, you kind of learn how it's laid out and what it does. Cool.