Duby and Surinx, an Interview With Charles Nutter

Charles Oliver Nutter is well known for his work on JRuby, but he also created two languages of his own: Duby and Surinx. InfoQ interviewed Charles to learn why he created Duby and Surinx and what their future will look like.

Charles, you have just released Duby 0.0.1. Why have you created Duby and where is it going?

Duby started as a toy project, driven by my desire to have something other than Java with which we could implement JRuby. At the time, I also hoped Duby could support other backends like C or .NET. Only the JVM support has moved forward, but it has moved forward very quickly in recent months.

I would define Duby as a language with Ruby syntax and a pluggable compiler and type system. I believe that in order to really replace Java, a language needs three characteristics: it must perform exactly as well as Java; it must be able to support all current Java features and be easily adaptable to new features; and it must have no external runtime dependencies other than what ships in the JDK. These criteria spring from my own needs. I want a language that can replace javac in producing free-standing Java .class files. I want a language that has no larger a semantic gap than Java has today. I want a language that works everywhere Java works, from the smallest embedded devices to the largest enterprise systems. If a language can not support these features, as Duby does, it will never completely replace Java.

There are two possible futures for Duby, and I would love to see one or both come true. In one future, Duby becomes a widely-used, general-purpose replacement for Java and javac. This is starting to feel more likely, since it already supports a large subset of Java features and more are being added every week. In the other future, someone else designs a language which is as clean and elegant as Duby and which also fulfills my three requirements. If that language was beautiful enough, I probably wouldn't have any reason to continue working on Duby...which would free up time for something else :)

A nice example for Duby is the following Swing Hello World Demo:

import javax.swing.JFrame
import javax.swing.JButton
import java.awt.event.ActionListener
 
frame = JFrame.new "Welcome to Duby"
frame.setSize 300, 300
frame.setVisible true
 
button = JButton.new "Press me"
frame.add button
frame.show
 
class AL; implements ActionListener
  def initialize; end
  def actionPerformed(event)
    JButton(event.getSource).setText "Duby Rocks!"
  end
end
 
button.addActionListener AL.new

You said that Duby was started to implement JRuby in it, how is that coming along?

That was certainly the original motivation, and it's definitely an attractive side goal. But I have started to see that Duby could eventually be contender for the Java crown, and even in its early, simple form today there has been a lot of interest in it. A few additional features would have to be addressed for Duby to become the implementation language for JRuby: we would need tool support like IDEs and ant tasks; and it would have to be compelling enough to do a rewrite (or we would need to implement a Java-to-Duby converter), since a lateral rewrite would require a lot of resources for no performance or compatibility gain in JRuby. It may be more likely we would use Duby to implement new code and extensions, and provide examples to help Rubyists to do the same.

It is worth mentioning that thanks to Ryan Brown of Google (who has made a ton of contributions to Duby lately), we do have a compiler mode that can output .java source files. If we had a .java to .duby converter, we'd have the first fully round-trippable alternative JVM language too. That's an exciting thought.

Besides Duby, you've also created Surinx, Duby's dynamic cousin. Someone on Stackoverflow wrote that "Surinx [is] what Groovy should have been". What were the reasons to start Surinx?

Groovy, JRuby, Jython, and other dynamic languages suffer from two diseases. We have to work on JVMs that don't have invokedynamic, so we carry around a lot of cruft and overhead to make dynamic dispatch work well. We also have to deal with either off-platform features (as in JRuby and Jython) that are hard to implement on the JVM or well-intended but ill-fated features from early versions (as Groovy does in some cases). Surinx represents a clean break from the past, using only JVM types and JVM dispatch mechanisms (like invokedynamic) to function. Indeed, Surinx is very much the dynamic cousin of Duby, and could be thought of as a "simplest possible" JVM dynamic language.

It's important to note that while it is a dynamic-typed language, Surinx does not provide a lot of features the others do like open classes, method_missing, or metaprogramming capabilities. The reason is simple: Java's type system doesn't support such things, and Surinx does not introduce a new type system. However, some of them could eventually come via compiler plugins and transforms or new JVM features like hotswapping, so who knows what the future may bring.

Which brings me to the future of Surinx. It's even simpler than the future of Duby: the two will merge. As I have worked on both Surinx and Duby, it has become apparent to me that they're essentially the same language with different dispatch mechanisms and type declaration requirements. And since Duby could easily treat untyped or dynamic-typed expressions as requiring dynamic invocation, there's no reason Surinx shouldn't just be assimilated as a feature of Duby.

Charles also wrote a great introduction to invokedynamic.

Duby is hosted on GitHub and on Kenai.

What do you think, could Duby become one of Java's successors?