The primary backend for Duby currently targets the JVM. This page lists how current and future Ruby syntactic structures map to JVM features.

• All Ruby literals map to their equivalents: fixnums can be either int or Integer depending on compiler plugins, strings map to Java strings, regexp will map to Java regular expressions, and so on. Of these, only fixnums and strings are currently implemented in a usable form.
• Method definitions map to Java method definitions, with the obvious difference being that method definitions are statically typed and may be overloaded.
• Methods with optional arguments are expanded to N methods that fill in those optional arguments and call down the chain, similar to how optional-arg methods are "arity split" in JRuby.
• Closures are under consideration. The simplest way to support them would be to use reflective calls, where instantiating a closure simply grabs the java.lang.reflect.Method object for it and passes that along. Enclosing scope then would obviously be difficult. Another possibility to support scope would be to pass an Object[] along that contains a set of values from the containing scope and the target Method object. In general, Closures will be an interesting challenge to implement without introducing a runtime library dependency.
• Modules and mix-in inheritance will be implemented similar to how C# provides extension methods. The complication that arises would be typing constraints; if a module is mixed into multiple incompatible types, its signature would need to accept Object; as a result of accepting Object, it would not be able to bind statically to methods on that object. Obviously, limiting module support to a single input type would work, but greatly limit their utility.
• Open classes are easier than mixins; specifically, any additions to an existing class are added to the list of "known" methods on that class, although not added to the class itself. So class opening would only be visible to code compiled at the same time or with the same set of "openings" present. Alternatively, opening could be limited to a single compilation run, but that would limit its utility.
• Block arguments would be required for any method that expects to receive a closure, or alternatively the presence of "yield" could imply a block argument. Open for discussion.
• eval would probably not be supported, since it would imply a runtime dependency on at least a parser and interpreter.
• Class-body code execution could be supported provided it only did things suitable for static initialization; it would not be possible to conditionally define methods and the like.

Others? Most of these have not been implemented. The early versions of the JVM backend for Duby will most likely focus on feature-parity with Java, which shouldn't be particularly difficult. Adding the "missing" Ruby features on top of that base will then be easier.