What's the difference between Duby and Juby and why would I need either of them?

Question

According to Charles Nutter, Duby is

a static-typed language with Ruby's syntax and Java's type system. Duby supports all Ruby's literals, uses local type inference (only argument types must be declared), and runs as fast as Java (because it produces nearly identical bytecode). But with the advent of invokedynamic, Duby needed a playmate.

1. What's invokedynamic and why does Duby "need a playmate"?

Juby, on the other hand, is

intended to be basically like Duby, in that it uses Java's types and Ruby's syntax. But it takes advantage of the new invokedynamic opcode to be 100% dynamic. Juby is a dynamic Duby, or perhaps a dynamic Java with Ruby syntax. It's not hard to comprehend.

Actually it is hard to comprehend.

2. Could someone elaborate a little bit more on what this distinction is about?

3. Why do we need (need!) another Ruby-related language? Or, rather, two more Ruby-related languages?

Answer 1

I'm going to answer the questions out of order, starting with the simplest one:

2. Could someone elaborate a little bit more on what this distinction is about?

Duby is statically typed, Surinx (which is the final name for what was for a short amount of time called Juby) is dynamically typed. That's already all there is to it.

Actually, there is one small detail as a consequence of this: Surinx syntax is a strict subset of Ruby syntax, i.e. every syntactically valid Surinx program is also a syntactically valid Ruby program. Duby OTOH is almost a syntactic subset, except for its mandatory method parameter type annotations:

def foo(bar => Integer, baz => String) => Array
  # ...
end

That's illegal in Ruby.

3. Why do we need (need!) another Ruby-related language?

First off: other than syntactic similarity, these languages are in no way, shape or form related to Ruby.

So, why did Charles Oliver Nutter create Duby? He is the lead developer of the JRuby Ruby implementation, which is an implementation of the Ruby programming language for the JVM. Like most Ruby implementations, it is written in the dominant programming language of the underlying platform: MRI, YARV and tinyrb are implemented 100% in C, MacRuby mostly in C with a bit of Objective-C, Ruby.NET and IronRuby 100% in C#, HotRuby in ECMAScript, Red Sun in ActionScript, Cardinal in PIR and NQP and so on. (The only Ruby implementations that contain a significant amount of Ruby code are Rubinius (about 70% Ruby, 30% C++) and MagLev (unknown amounts of Ruby and Smalltalk).) And naturally, XRuby and JRuby are implemented 100% in Java.

Now, the funny thing is, Charlie came to Ruby, because he didn't like his day job, doing Java development. And now, he still writes Java code all day long! Of course, he doesn't like that, and so he was looking for another programming language in which to implement the core of JRuby. One option would certainly be to just write it all in Ruby, but with metacircular implementations there usually comes a point of diminishing returns, where the implementations degenerates into academic masturbation. It would certainly make sense to rewrite the libraries, the ahead-of-time compiler (actually, that's already being done) and some of the core classes in Ruby, but some parts of the engine core are better written in something closer to the execution model of the JVM itself.

Charlie was looking at the available options: Scala, Groovy, Fan, Clojure, Nice, but all of them had a significant disadvantage: a fairly large language runtime. The size of the JRuby runtime is already a big problem in terms of memory consumption and startup latency (especially compared to MRI or YARV and even more so if you actually include the JVM itself in your measurements), and rewriting it in a language that adds its own runtime to that weight is simply a no-go. Unfortunately, there was no programming language which satisfied the two basic criteria Charlie was looking for: no runtime and compiles to JVM bytecode that is at least as efficient as the equivalent Java.

So, he decided to create his own. The reason why he chose to use a syntax similar to Ruby, is actually quite simple: he didn't need to write a parser for it, Duby just uses JRuby's already existing parser with one minor modification to support method parameter type annotations. (Actually, he also likes Ruby's syntax, that was of course also a factor.)

As you know the syntax is actually the least important part of a programming language. (Its irrelevance isn't always obvious from the amount of arguing about it, but that's just because syntax is the only thing you can argue about without having to actually understand what you are talking about.) Much more important than the syntax is the type system and the evaluation semantics. And here comes the trick: Duby doesn't have either! It only has syntax! It's like a parasite: it simply "borrows" the type system and semantics from its underlying platform. That means that on the JVM, Duby's type system is the Java type system, and Duby's semantics are Java's semantics. To put it another way: Duby isn't a programming language at all, rather it is "just" an alternative syntax for Java.

That means that there is no mapping, no conversion overhead and no speed difference between Duby and Java. And that means that the internals of JRuby could be written in Duby, without losing any features.

So, that's Duby.

In order to explain Surinx, I'll first answer your first question:

1. What's invokedynamic and why does Duby "need a playmate"?

invokedynamic is specifically a new bytecode that is going to be added to the 3rd edition of the JVM specification and that is going to be released in JDK7. However, more generally invokedynamic is usually used as a stand-in to refer to a whole bunch of features, of which the actual invokedynamic bytecode is only one, that are currently being developed under the umbrella of JSR-292 "Supporting Dynamically Typed Languages on the Java Platform". And even more generally, the name invokedynamic is used as a moniker for the general change of strategy both in Sun and in the JCP as a whole to turn the Java platform into a general purpose language platform for all sorts of languages.

The specific purpose of JSR-292 (which is what Charlie alludes to in his blog post), is to make dynamic method dispatch faster – indeed, almost as fast as static dispatch in Java, at least in the best case.

Surinx is a dynamically typed programming language which basically does the same thing as Duby: like Duby, it also has only syntax, like Duby, it also used the Java type system. But unlike Duby, it does not use Java's method invocation semantics, instead it uses invokedynamics method invocation semantics. IOW: it is dynamically typed and uses dynamic dispatch.

So, that's Surinx.

Now, I can answer the second half of your third question:

3. Why do we need (need!) […] two more Ruby-related languages?

I already answered for Duby, here's the answer for Surinx: it's what Groovy should have been – a lightweight (actually, zero-weight) dynamic expressive scripting language for the JVM. Also, it is currently the simplest way to play around with the inner workings of invokedynamic. (The current development snapshots of JRuby 1.4 also support it, but that's a much more complex project.)

---

Two things I left out: Duby actually uses local variable type inference, so, unlike Java, you only have to declare the types of method parameters, but everything inside a method will be type-inferred.

And secondly, both Duby and Surinx are not actually tied to the JVM. Since they just steal their semantics and type systems from the underlying platform, they can be ported almost anywhere, where you have a rough mapping from Ruby syntax to platform concepts. Off the top of my head, I could imagine ports of Duby to C, C++, Objective-C (iPhone, anyone?), D, CLI and ActionScript and ports of Surinx to the DLR, Smalltalk, Parrot, ECMAScript, Python, Perl, PHP and Objectice-C. In fact, there are already the beginnings of a C port of Duby.

Answer 2

Mirah (formerly Duby) exists, because static typing can result in dramatically improved performance with Java/Hotspot. Surinx (formerly Juby) is the same thing, except that it also takes advantage of a new performance feature that is coming in JDK7 to enhance performance even further.

The performance feature is commonly called "invokedynamic", and a good explanation is available on Nutter's blog as well.

Answer 3

Just came across this, straight from Charles himself which partly addresses the question (re: the difference between them):

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.