Charles Oliver Nutter
Transcript
Hi, it’s Mike again with Uketastic. I’m sitting down today with Charles Nutter. You might know him as Hedius on Twitter and his blog, and you might also know him as the leader of the JRuby Project. Hi Charles, thanks for taking the time to sit down. So, you run the JRuby Project. Maybe we could start from the origins. You know, it’s a big project that spans the globe and it has a lot of impact for individual developers and big corporations. How did JRuby get started? Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, JRuby itself started in about 2001. A guy named Jan Arne Pedersen and a couple other folks wanted to see if they could at least come up with a way to get started. Well, 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 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. And so you just immediately jumped in and started using it or committing to it? And so you just immediately jumped in and started using it or committing to it? Or did you try to use it and find things that it didn’t do that you needed and you started contributing that way? 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. That’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 start 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’d 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. And so how did it end up with you being into a leadership position on the project then? How did that evolve? 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. I did several rewrites of the interpreter. I started doing some profiling, looking for 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 then 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 worked, 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. How do you reconcile that? 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? Right. 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. 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 themselves, 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. For the most part, it’s been a very communicative relationship with the Ruby core folks. They understand that we have our own challenges implementing Ruby and that we’ve met some challenges they might have in the future. Has there been any talk, though, of… Actually, I’m not going to go down that path. I’m 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. 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 Matt 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 Eric. 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. Is that inaccurate? There is a process. There is a fairly clear 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. The bulk of the Ruby core mailing list and the bulk of traffic in the bug tracker as well. So there is a process, but it’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. 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. Trying 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. Okay, and you know you’ve also, you’ve given 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 some optimization, or invoke dynamic if you want it, if you want Clojure to be awesome, or something along those lines. Are you looking at Clojure or other languages? Are those influencing JRuby? 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 am keeping track of invoke dynamic, especially for JRuby and dynamic languages, who is using those features, upcoming features in Java 7, 8, and 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 unreasonable 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. Okay, and there’s one other kind of pillar in this that you have to deal with, because 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, 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 pretty stable and well supported? Yeah, 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. 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. Part of the evidence is that they have a whole team of folks working on a JavaScript implementation, Nazhorn, and that team is considered part of the hotspot VM group because they want both a fast JavaScript implementation and they want to make changes at the JVM level for languages like JavaScript. Oh, okay. They’ve prioritized polyglot and multiple languages perhaps even more than Sun did. Oh, wow. So, yeah, so the future is bright for developing on the JDK. Yeah, I think so. They seem to have the priorities in the right place. Okay, great. I’m focusing a little bit more on what you do, teaching and going and speaking. Obviously, there’s the JRubyConf. How involved with organizing the JRubyConf are you, or mostly do you go and speak and hang out? I’ve been pretty hands-off. It’s organizing real-world things has never really been a strong suit for me, so there are other folks who do better jobs of organizing conferences, but we will do things like try and get keynote speakers, try to look for interesting talks, review talk submissions, help decide on arrangements, places we want to do the talks, where we want to do the conference, so on. But for the most part, we’ve been hands-off with that. We have tried to 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 it. So, yeah, for the most part, it’s kind of a go-and-hang-out thing, but a little bit of upfront planning. Now, when you go and present, how do you prepare for a presentation? 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? Do you practice? 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. I have dozens of different demonstrations that I 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 and what they would be interested in hearing about JRuby. 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 you’re also 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 the Ruby community, which has its own definitions. Has there been any – I don’t want to say, “Do you like going to one better than the other?” But if you were to answer that question, I would be okay with that. But do you have to do anything different, though, when you’re going to present at a Java community or event versus a Ruby? Is there any discernible difference between going to those two different types of events? Oh, absolutely. I will say, and 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. In almost every case, they’re looking for a new way to scale their app or a new way to implement some service, but they’re looking for change. They’re looking for something different than what they’ve done. You go to Java events, people are much less interested in trying something brand new, trying some new feature, new language, as they are just, like, plain productivity. How can they get their app out the door more quickly, more business-oriented, more money-oriented? Use JRuby. Yeah, that’s the thing. When we go and talk to a Java conference, the challenge for us is showing how you can build your apps quicker using Ruby. 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, we’ve already sold on those things. So we’re selling the JVM. We’re selling JRuby. 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 do have very different decks of slides that we use for the two different communities. 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 there any advice you have for people who are looking at JRuby 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, some articles on specific subsystems like how the compiler works, how the embedding API works to kind of get people bootstrapped on that. I am also hoping to do, sometime this month, a couple blog posts on how to get your foot in the door, where all the pieces are, for somebody who has never looked at this kind of project, how to contribute, how to get involved in it. 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. Lots of places. The easiest way for folks to get involved now is to be looking for easy bugs or looking for refactoring opportunities, pieces of code that look like they could use some cleanup. 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. Well, thank you very much for taking the time to sit down with me, Charles. Yeah, thanks a lot for the talk.