Re: [ANN] duby 0.0.1 Released

On Tue, Oct 27, 2009 at 8:01 PM, David A. Black <[e-mail]> wrote:
> It seems like in this project, the notion of type as being synonymous
> with class "wins", so to speak, over the non-class-bound concept of
> type. I'm curious whether this is because doing it that way meshes
> better with other languages that might be involved, or because the
> concept of type as object capability at a given point in runtime is
> (as I think it might be) almost impossible to capture statically at
> all. I'm thinking of module inclusion as well as singleton-level
> operations.

Yes, it was definitely a conscious decision to both use Java's type
system (which is immutable, or at least immutable enough that me as a
language implementer can just tell the JVM the class and method I want
to call at compile time), and explicit static typing (also a
requirement to be able to statically produce direct calls to specific
types and methods). The same could be mapped into any other backends
that have a notion of immutable types that are present at compile-time
rather than at runtime. In this case, it turns out that Ruby's syntax
presents at least the basic requirements necessary to produce JVM
bytecode for class and method structures like Java's types. Duby is
not yet able to replace Java, since it's missing many additional
features (field access from outside a class, annotations, generics,
enums, etc), but it is at least a fairly capable language in itself
that can call any Java type with no performance impact of any kind. In
essence, it's just a Ruby-lookalike for Java, but a Java somewhere pre
1.0. My plan is to have at least a Java 1.0 featureset for Duby 1.0.

The other goal with Duby is to produce a compiler that is extremely
pluggable. Most of the "keywords" like "implements" or "import" are
not hardcoded anywhere in the system; they are plugins loaded by the
compiler. Additional keywords can easily be added, or existing ones
could be removed. The language is fairly mutable.

The philosophy of Duby is simple. I wanted a language had the
syntactic elegance of Ruby, but the performance of and tight
integration with Java. At the same time, I didn't want to give up
metaprogramming-like capabilities, which is where the plugin system
comes from. You can do a surprising amount of metaprogramming just by
having a way to extend the compiler. And then you pay no runtime cost
for any of it.

Duby is certainly not intended to be a replacement for Ruby. There are
many things it will never support, like "eval", or interpreted
execution. It also will never ship with its own runtime
libraries...whatever the compiler produces needs to be "it", and you
are in control of what library dependencies you explicitly introduce
into your code. Writing a line of code should not suddenly force you
to ship a 2 or 4 or 20MB runtime library with your application.

I should also say it's fairly early days for Duby. The codebase needs
a lot of cleanup, the plugin system is fairly limited and cumbersome,
and error handling is not spectacular. And of course there are a lot
of Java/JVM features it can't support yet. But other than the parser
(JRubyParser) and the bytecode-generating backend (bitescript, which
wraps the Java ASM library), it's all written in Ruby. Hopefully folks
on this list will be interested in hacking on it.

FWIW, I'll be giving a talk on Duby at RubyConf (the "Ruby Mutants" talk).

- Charlie