Duby and Surinx, an Interview With Charles Nutter

Posted by Mirko Stocker on Nov 15, 2009

Community

Java,

Ruby

Topics

JRuby ,

Language Design

Tags

JRuby ,

JSR 292 ,

JVM

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?

1. Back to top

   attractive ideas

   Nov 15, 2009 8:39 PM by Gergely Nagy

   These look like great ideas, especially, that syntactically there are the closest possible to Ruby but semantically the closest possible to JVM.
   Not reinventing the wheel(as some others do), just bridging the gap.
   
   However the Duby Helloworld snippet looks almost pure Ruby - another one that shows type declarations,etc.. could be more useful.

   Reply

2. Back to top

   Re: attractive ideas

   Nov 16, 2009 12:35 AM by Charles Nutter

   Gergely: That's exactly what I'm going for; I want to map Ruby syntax as closely as possible to straight-up JVM constructs, providing a nice syntax and a few syntactically-sugared features without diverging substantially from what works best on the JVM.
   
   As far as better examples, you might take a look at the Duby repository here: github.com/headius/duby/tree/master/examples. There are several other examples that actually have type declarations, field declarations, and so on. Duby is still a bit of a moving target, but a surprising amount of code works already.

   Reply

3. Back to top

   What a Java successor should have

   Nov 18, 2009 10:30 AM by Hermann Schmidt

   I like the terse syntax! Java is too bloated with semicolons and brackets.
   
   I don't know the VM well enough to tell if a Java feature has its origin in the compiler or the VM. So please excuse my ignorance.
   
   Number one of my most hated "features" of Java is the dreaded setter & getter hell. Any successor of Java should get rid of this and have a simplified, yet equally flexible attribute access logic similar to Ruby.
   
   Some comfort features like a more powerful switch-case statement would be nice.
   Closures perhaps? I am really tired of all those looping statements.
   Mixins are a pleasure as well.
   
   Many nuisances in Java are caused by the libraries. java.io is too complicated for 80% of the cases. Strings are clumsy and fragile. I often use the Apache StringUtils and FileUtils instead of desperately trying to plumb stuff together.
   
   JRuby has none of those issues, that's why I love it. So, from my point of view, a breakthrough for any successor language depends on more than syntax and the type system.
   
   And let's not forget about IDE integration, which is a real produvtivity gain. Java has set very high standards there.

   Reply

4. Back to top

   Re: What a Java successor should have

   Nov 23, 2009 1:58 PM by Mirko Stocker

   Hermann: You should definitely take a look at Scala (besides Duby of course :-) ). The syntax to create classes with getters and setters is really simple, and it has pattern matching (switch-case on steroids) and mixins as well.

   Reply

• Older >