Interview: Charles Nutter
What are your goals for FOSDEM?
I would like to show how JRuby became probably the most advanced Ruby implementation yet available, while also showing that it would not have been possible without community involvement. I'd like to spur people to make contributions to other projects, since it's obvious to me no project can survive without those contributions.
How is life at Sun?
Sun has been great for me and for the project. I have access to experts on a vast range of software topics who are excited to work on new things. Our managers at Sun have also given us the freedom we need to keep JRuby moving forward and to cultivate a community. And I've learned from the inside how the "new" Sun under Schwartz really "gets it" about Open Source. I'm proud to work here.
How do you see Java-the-language and JRuby coexist in the future?
I want to make Ruby a first-class language on the JVM, with full integration with Java code, classes, tools, and libraries. We're not quite there yet, but we're very close now. I'd also like to see JRuby as a testbed for features and platform enhancements that will make it easier to implement high-performance dynamic languages on the JVM. That process has already started.
Is performance the main focus of JRuby 1.1?
That's the official word, yes. Since performance was one of the only real complaints about JRuby 1.0 and Ruby itself, we focused very heavily on JRuby 1.1's performance since last spring. And as a result, JRuby is faster than the stable Ruby 1.8.6 on almost all benchmarks, and faster or comparable to the development Ruby 1.9 in most. But there's a story behind the story. JRuby 1.1's compatibility has improved tremendously since JRuby 1.0, and we recommend everyone use the release candidates now. More work has been put into JRuby 1.1 than into several releases up to and including JRuby 1.0, and the performance and compatibility show that.
What are the longer-term goals? Are you already looking at Ruby 2.0?
Ruby 1.9 is the current development version of Ruby, and it has incorporated several new features. We've already implemented several of them in JRuby 1.1, and will add the rest post-release. We're going to continue tracking the main Ruby core development, while we also keep improving JRuby's runtime and Java integration capabilities. There's more work to do, but I think we'll be able to show another set of excellent enhancements for JavaOne, including full Ruby 1.9 feature support. Beyond that, beyond what may be "JRuby 2.0"...I think I'll move my focus toward improving the state of language support on the JVM platform in general, taking the same community focus to a broader scope.
The .NET equivalent of JRuby is called IronRuby. Do you follow their progress? Any comments about the .NET CLR versus the Java VM as a platform?
Well there's both IronPython and IronRuby. IronPython is pretty far along, but I don't know much about. IronRuby is still in its early days, and we'll probably not see IronRuby on Rails for quite some time. I talk with John Lam (lead developer of IronRuby) occasionally, but I don't track either project closely. In general, what I hear from friends of friends is that although some features of the CLR (.NET Common Language Runtime, ed.) make it attractive for language developers, both the IronPython and IronRuby teams have had to solve the same problems we've tackled on the JVM (Jave Virtual Machine, ed.). Based on my limited exposure, I'd be surprised if any CLR features made it vastly simpler to implement alternative languages... especially dynamic languages.
Do you cooperate a lot with the Ruby team?
Yes, more and more. I've actually talked with Matz (creator of Ruby) on several occasions about core Ruby features, and recently convinced him to remove a feature that I and others considered to be dangerous and counter-intuitive. And Matz has been completely open about the Ruby source and standard libraries, allowing JRuby and other Ruby implementations to borrow anything they need. Sun and Tokyo University will also be collaborating on upcoming research to add Multi-VM capabilities to Ruby, with the intent that all implementations should have a consistent interface for such features. I'm looking forward to working more closely with the Ruby core team.
Are there any ideas or improvements you feel the Ruby core developers should consider to copy from JRuby?
Most of the basic techniques we've used could apply directly to both
Ruby 1.8 and Ruby 1.9, so I think there's a lot of benefit to be had.
Beyond that, the core Ruby implementation suffers in areas where we just
lean on the JVM: JIT (Just-In-Time, ed.) compilation to native code, world-class GC (Garbage Collector, ed.),
platform independence, and so on. Those are areas where JRuby's going to
have more and more of an edge. I hope we can help the core implementation
keep up.