Alternative Ruby implementations seem to be on the move throughout the Ruby community. JRuby is the furthest along at this point, so I decided to talk to Charles Nutter and Thomas Enebo, two of the principal programmers on the project. Read on to hear what they have to say about Ruby, JRuby, and the art of re-implementing Ruby.

How did you find your way to Ruby?

Charles Nutter: I had begun to hear more about Ruby from friends in the fall of 2004 and was just starting to learn it. I discovered that RubyConf 2004 would be held only a few miles from Ventera's home office, in Reston VA, so I planned a trip out east to attend. I was excited about the language's potential and loved the enthusiasm and small size of the conference. I wondered to myself whether there might be a Ruby implementation for Java. While sitting at the conference, on day one of my ongoing Ruby experience, I discovered the JRuby project being led at the time by my friend and former co-worker Thomas Enebo. That was the beginning.

Thomas Enebo: I had been using Perl since the early nineties and I was fairly happy in that space. I like looking at new things and I happened across someones web page showing a re-implementation of a Perl script in Ruby (I cannot remember what or where). I was gobsmacked. I immediately ordered Dave Thomas's Pickaxe book and I have been hooked ever since.

What benefits do you think JRuby will bring to the Ruby community?

Charles: Java has been in use for over a decade, and the language, runtimes, and tools have been freely available all that time. The result of this openness is that Java applications and libraries exist for just about every purpose under the sun. Ruby has really only existed in its current form for a few years, even though its full lifespan is older than Java's. Because Ruby has evolved over a long period of time and only recently come under broad public scrutiny, there are not nearly as many libraries or projects written in Ruby. I hear people frequently asking for feature X in Ruby that they've used as library Y in Java. The usual answer from Rubyists is to wrap that library in a web service (on a Java server) or call it over a Ruby-Java bridge. Neither option scales well, however, and they don't address the fact that the Ruby world is very young and is missing many libraries people want. Enabling Ruby developers to call all those same libraries without a bridge and without a web service puts the power of ten years of Java into their hands.

Thomas: The largest benefit is the additional libraries and options that the Java ecosystem brings to a Ruby developer. You need to leverage some library to parse GPS data? You can bet there is a Java library somewhere that does it. Even for Ruby libraries that already solve a particular problem, the Java equivalent may scratch that itch better.

Charles: Ruby also suffers from a slower-than-average implementation. The current version of Ruby proper is written in C and is a pure interpreter; i.e. it does no compilation and little optimization of the incoming code. This has resulted in Ruby running a fair bit slower than comparable languages like Python and Perl and far slower than Java. Meanwhile the JVM is an astounding piece of technology that has enabled Java code to match or exceed compiled C code in some cases. I believe that JRuby could soon become a highly optimized Ruby platform, and that a Ruby-to-bytecode compiler could conceivably make JRuby faster than "C Ruby" for many applications. We hope to match C Ruby's speed first, and then focus on compilation to take Ruby and JRuby to the next level.

Thomas: Another benefit is an easier path to adoption in an "Enterprise" environment. I quote "Enterprise", because I am talking about it in the nebulous "this is a production environment and we need real software for real problems" business mentality that gets married to the term "Enterprise". Java has passed this hurdle. Ruby still has not made it there yet in most places. Deploying Ruby-embedded Java server apps is an easier sell than getting an IT shop to deploy a Rails application. Embedding Ruby in Java also helps raise awareness of Ruby as a language. Over time, I see Ruby embedded Java applications growing the Ruby community. A bigger community will open more doors and gain "Enterprise" acceptance faster.

The last benefit is that by having alternate implementations of the Ruby programming language there will be a stabilizing force on the main C implementation and/or language specification. By saying this, I largely mean that when we implement an aspect of Ruby and get a weird result, then we fling an email asking what the behavior should be. This can help expose strange undiscovered corner cases. For sure, it provides a sanity check to implement the same behavior twice.

What about the Java community?

Charles: Ruby is a beautiful, elegant language. Java is a very utilitarian, practical language, but few would call it beautiful. Folks that prefer Ruby love how easy it is to read and write, and how quickly they can implement even complex code with it. Ruby also provides other language features that are very programmer-friendly like dynamic typing, closures, lightweight threading, and many more that Java does not have. Ruby has often been described as a great language in which to write "glue" code, which in the Unix world often means tying together other scripts and programs. However much of what we do in the Java world is simply gluing together libraries and applications to perform a new function. I believe that Ruby is a perfect language to replace Java in those areas, as the "logic" that makes Java applications go. I also believe that "the Ruby way" of writing software, exemplified by applications like Ruby on Rails, can empower the Java platform to do great things most Javaists may never have thought possible.

Thomas: Java is a decent statically-typed language and the JVM is a great runtime. The Java language really is not a one size fits all solution. Ruby is a very good compliment to Java. It allows you to leverage its open definitions and dynamic-typing to solve some problems very elegantly. Ruby's syntax in particular really helps manipulate the static Java code in much less space. Embedding Ruby into a Java project can dramtically reduce the complexity and size of the project.

Besides embedding, just the ability to script Java and make quick tools has been a boon for me. You can create a little test case in 10-12 lines or make an administrative tool. You can mix and match Ruby and Java libraries. I wrote a simple xslt transformer using Ruby's 'optparse' and Java's built-in XSLT transformer. Use the best of both worlds.

Finally, I think it cannot be understated that the JVM needs to become a friendly multi-lingual virtual machine. Projects like JRuby, Jython, Groovy, and the many others helps to keep the JVM an innovative space. This will end up yielding more specialized tools for Java and more options for Java developers. I believe the future of Java is in it's JVM and less in it's language.

A lot of other folks are working on Ruby implementations, what sets JRuby apart?

Thomas: I believe we are the closest to being a complete alternative to what Ruby is today. We have re-implemented the important C external libraries and have gotten to the point that Rake, Ruby on Rails, WEBrick, and RubyGems are mostly working. This distinction will be lost over time, since I hope the other implementation succeed and provide additional decent Ruby implementations. It is a clear distinction right now though.

Charles: JRuby is by far the furthest along. We have a working interpreter that is very close to "compatible" with C Ruby version 1.8.4. We have a number of popular Ruby applications working under JRuby including IRB, RubyGems, Rake, and Rails. Rails is especially indicative of our progress; it is arguably the most complex Ruby application available today. With our compatibility and "correctness" approaching C Ruby, we are also in a better position to start advancing JRuby's core with a compiler and new optimizations. Because we have no C extensions to support (as does C Ruby) we have the flexibility to make sweeping architecture changes within JRuby to better support the needs of the Ruby language. JRuby has actually followed the same general course C Ruby has; first an interpreter, then various optimizations, then a new VM and compiler. We are now approaching some level of completion on the interpreter and have started into optimization. We have also started looking at what would be required to compile Ruby code into Java bytecode.

Many other of the alternative Ruby implementations have taken the approach of writing a compiler first. This allows them to get a speed boost from the beginning, but also ties them to certain implementation and design decisions that might later prove to be an issue. Then there's the fact that much of Ruby code and libraries are not yet ready for compilation; they expect .rb files to be loose on the filesystem, and frequently go looking for them. Those sorts of issues will bite the early compilers pretty hard, since they will have to contend not only with Ruby's quirkier features but with its own libraries' lack of readiness for next-generation VM and compiler designs.

Thomas: We are also an implementation on the JVM. This allows tight integration with Java and other JVM-backed languages. Living in a single language environment gives a nice sense of purity, but I largely think most developers are realizing this purity is out-moded. Some languages solve some problems really well and others not so much. Plugging into a functional language then giving the result to a Java class that is glued together by Ruby may seem scary; but I look at this as having choices to pick the right tools for the right jobs. An environment that provides you with choices is only a good thing in my eyes. I see the JVM as being this environment.

How do you think the various projects working on Ruby implementations can work together to help improve Ruby as a whole?

Charles: I'd say there's many ways.

• We could work together to start creating more formal specifications of the Ruby language and libraries. The C Ruby folks obviously have the best grasp of what would be in such a spec, but it's mostly wrapped up in their heads and in the C code. We alternative implementations have to glean from Q&A and code inspection what is the intended behavior for various aspects of Ruby in order to correctly implement that behavior. In the process, we could be assembling a specification as we go; but I don't believe any of us are.
• We could work together to create libraries of tests that exercise various aspects of Ruby. Currently available tests for Ruby are rather sparse. There's the Rubicon project, created by the Pragmatic Programmers, but it tests only a small portion of Ruby and has only been partially updated to Ruby 1.8 semantics (having been based originally on Ruby 1.6). There's the test cases within Ruby's own source, but those tests only seem to exercise peculiar edge cases reported as bugs; they come nowhere near a complete unit test suite. There are test cases within various applications like Rails or RubyGems; however, those also are not complete Ruby unit test cases since they test only what is relevant to those applications. The MetaRuby guys claim to have a large library of tests, but they have never been released or made public. There is, however, a renewed interest in creating an extensive suite of test cases being pushed by Dr. Wayne Kelly of Queensland University in Australia, the lead of a Microsoft-funded effort to create a "Ruby.NET" compiler. He, like the rest of us alternative implementers, very much wants to have a complete unit test suite to verify his implementation. Hopefully his efforts will bear fruit.
• We could share pure-ruby implementations of particular libraries. We have taken the approach that if Ruby uses a native library or extension for some functionality, we first implement it in pure Ruby to get things running. Implementing in Ruby goes very fast, and allows us to continue on with other things. We eventually circle back around and reimplement those libraries in Java for performance, but the original pure-Ruby versions could be useful to other projects.
• Documentation, documentation, documentation. We've discovered many quirks about how Ruby works that are not documented anywhere. We should be creating a central store of such facts for all to use.

Thomas: I think multiple implementations of Ruby will end up expanding the visibility of Ruby as a language. Just having reasonable JVM and .NET CLR implementations has great potential to get many new Ruby enthusiasts.

Also hopefully it may clarify multi-platform inconsistencies in the C Ruby implementations and perhaps have an influence on them. The Windows port of Ruby, for example, does not obey the same exact semantics as the linux/unix versions. Dir.glob with backslashes is an example. Java as its own platform needs to behave on both these systems sanely. Java deals with the cross-platform issue by a lowest common denominator approach which I think is bad; and I don't think we want to encourage Ruby in that direction too much. I do think we want to help identify issues and come up with elegant cross-platform ways of doing things. For example, eating output from executed commands is generally some strange application code and platform check to dump to /dev/null or whatever the thing is on windows. What is wrong with this picture? Having more implementations/platforms of Ruby will help highlight issues like this.

I would really like to see multiple implementations of Ruby the language end up generating a consistent definition of Ruby that is not determined by someone changing a line of C code. I give great credit to the C Ruby developers in designing a great language, but the lack of a formal language specification will eventually become a liability. The more implementations hopefully will highlight the need for a formal language specification.

My last comment is a prediction. I predict that alternate implementations will give the main C implementors and language designers new ideas. Perhaps the idea will be architectural/implementation specific. Could even be an idea that creeps in because of some language integration feature from one of the alternate implementations. I think fresh perspectives always improve any creative process.

What are your 5 favorite libraries/frameworks for Ruby (whether in the standard library, or off the 'Net)?

Charles:

• Rails has to be up there somewhere just for pure ingenuity; they've taken the "ruby way" to its logical end and built a more dynamic framework than I've ever seen before.
• RubyGems is a packaging system on par with the best options under Python, Perl, or Linux.
• Rake is a great build tool; I'd like to create tasks for it to allow replacing Ant scripts.
• Mongrel is very intriguing, and I've been trying to think of ways to implement the same under JRuby (Mongrel uses a native C library we can't replicate). It has the potential to really expand Ruby's use as a web platform.
• Our own support for Java integration has to be in my top five as well; it's so seamless and works so well after recent fixes, updates, and optimizations that you truly can write Ruby code calling Java libraries and never feel like you're using Java at all.

Thomas: I also included Ruby applications in this:

• JRuby's 'java' package for java integration. I write Ruby scripts out of Java libraries quite a bit.
• Ruby on Rails. I have been learning Rails at the same time as I have been debugging problems with it in JRuby. I am sure I have a warped view of it. It is very powerful and I like it.
• RubyGems. Pretty slick. Every language needs dependency-based package management for libraries.
• IRB. Interactive debugging is great. I use it alot.
• DRb. I do not use it, but I love stuff like this and I used up a slot because I think it deserves a mention.

What's next for Ruby?

Thomas: I don't work on the C Ruby project, but it seems YARV and Ruby 2.0 is the next big thing. It will be cool to see how it is received and how it ends up performing. It sounds like they have some significant speedups.

It would also be nice for a consistent GUI framework to emerge in the Ruby world. Java taught me that even a single crufty GUI API has a bigger impact that thirty others (think X11 here). I guess this is just a re-iteration of my cross-platform desire for Ruby.

Charles: I have heard folks semi-familiar with Ruby comment that Ruby the language seems to be one of the best, but Ruby the C implementation seems to be one of the worst. I would not go that far; matz and company have done some amazing things with the C implementation. However, I believe Ruby desperately needs to take a leap to the next level, from a simple scripting "glue" language to a real application platform. The potential is there if they can clean up various reliability and performance issues. With the rapid uptake of Ruby on all platforms, it could quickly become the standard among dyntyped languages, moreso than Python or PHP. On the JVM, it could easily surpass all other scripting languages due to its vibrant community and wealth of applications (especially considering many of those applications will actually run in JRuby). We're just now seeing the early upswing in Ruby acceptance...but it's moving very fast.

What's next for JRuby?

Charles: Performance, performance, performance. JRuby is still far slower than we'd like it to be and quite a bit slower than C Ruby. There's no reason that we couldn't match or exceed Ruby 1.8's performance, and with a compiler we should be able to exceed it. There are still compatibility issues to be worked out, but that may always be the case. With so many great apps already starting to work in JRuby, improving performance has become my main priority.

Other than performance, I want to make Ruby apps work better within a Java world. For example, Rake could be an excellent replacement for Ant. By building Rake tasks that can call javac, etc, like Ant does, Rake would easily replace Ant for many, many builds. I'm looking forward to the day I can replace my 5000-line Ant script with a far shorter Rake script and have everything work like it does today. Another example is Rails...we already have an ActiveRecord to JDBC adapter, but it's not complete yet. It should enable total database independence, but that will take a bit more work. We'd also like to be able to use ActiveRecord as a facade for entity beans or other persistence frameworks like Hibernate. Continuing to evolve and adapt Ruby frameworks to take advantage of Java under JRuby will be very important over the next several months.

Thomas: Where to start:

• Performance. Charlie is determined to make JRuby fly without wings or rocket fuel. We want things fast enough where people can consider it for Ruby on Rails work.
• Correctness. We still have bugs and we have been rapidly fixing them. It is an ongoing task that hopefully will start to diminish more soon.
• Java integration. I really want to be able to extend Java concrete class and abstract classes from within Ruby and have Java consumers see that behavior. Right now we only support extending(implementing) Java interfaces. In addition to this, I want to create a type-mapping system so that JRubyists can define their own type conversion mapping between the Java/Ruby boundary.
• Domain Helpers. If you look at packages like Spring or Groovy they provide a lot of domain specific helpers to make a developers life simpler. I think we will be starting and encouraging projects in that spirit. Antbuilder on Rubyforge is an example of this.
• JEE web container support for Ruby on Rails. We will be making a Servlet capable of running Rails that integrates well. This will yield tons of interesting side projects like calling EJBs or integration with other persistence libraries. Use whatever part of Rails you want with whatever Java part you want.

What's next for you two?

Thomas: JRuby is consuming alot of my spare-time. I have a day job and that is work making Java web applications. We will continue to improve JRuby and probably write a book. We will even evangelize more and do another conference (we got the opportunity to talk at JavaOne this year and it was great to meet people interested in JRuby) at some point this year.

Charles: Well, we're obviously neck-deep in this JRuby thing! I want to continue working to improve JRuby, but also to start expanding into Ruby apps and how they work within the Java world as mentioned above. There's also going to be a need for support and development services around JRuby. In fact, I believe there's enough momentum behind Ruby and JRuby to warrant full-time resources on these projects. C Ruby has matz full-time plus a number of other folks that are probably half-time or better. JRuby only has Tom and me working off-hours and weekends, and that includes work outside the core interpreter like Rails, RubyGems, Rake, and so on. It would greatly increase JRuby's progress if we had dedicated, full-time resources. Considering what we've done part-time over the past six months, imagine what could be possible!

At any rate, Tom and I plan to start working on a JRuby book around the end of this summer, depending on how the JRuby 1.0 release goes. We've had many people ask about a book, and we know there's a mass of Java developers out there that really want or need Ruby in their lives. JRuby the book will help make that possible.

I am also interested in helping the other Ruby implementations in any way I can. I want to see Ruby succeed everywhere, and I'd be happy as a clam dedicating all my waking hours to making that happen. The Ruby.NET project could certainly use a few extra hands, and the Cardinal project (Ruby on Parrot) seems to have stalled recently. Ruby is a hard language to implement, but the rewards are great; I like hard problems, so I'll do everything I can to move Ruby forward.

---

Charles Nutter has been a Java developer since 1996, recently working as the senior Java architect at Ventera Corp. He led the open-source LiteStep project in the late 90s and came to Ruby in the fall of 2004. Since then he has been a member of the JRuby team, helping to make it a true alternative Ruby platform. Charles presented JRuby at RubyConf 2005 and co-presented at JavaOne 2006 with Thomas Enebo. He hopes to co-write a JRuby book this fall with Thomas to follow up a planned JRuby 1.0 release. Charles currently works on a Ventera contract for the USDA's Food and Nutrition Service at their office in Minneapolis. Charles blogs on Ruby and Java at headius.blogspot.com

Thomas Enebo is project manager and a developer of the open source project JRuby. He is a developer at the University of Minnesota and a consultant with Aandtech Inc. Tom has been using Java in some fashion since its first public beta release. He became interested in Ruby after seeing an elegant re-implementation of some Perl code. Tom joined the JRuby project some time in late 2002. He blogs about JRuby at www.bloglines.com/blog/ThomasEEnebo

A couple of pieces were trimmed from this article, and can be found at: on-ruby.blogspot.com.