过去的两年里，在可选 Ruby 实现方面进展很大：在官方 MRI 及后续的 Ruby 1.9 之后，许多其他 Ruby 实现的项目被启动：基于 JVM 的 JRuby 和 XRuby 、.NET 平台的 Ruby.NET 和 IronRuby 以及一个自托管的虚拟机 Rubinius 。
现在看来一些合并已经发生了：XRuby 的开发已经慢了下来——因为JRuby更大的动力和更广泛的使用，还因为它不能够像 JRuby 的扩展那样在 Java 中支持原生 Ruby 函数（例如：OpenSSL、Oniguruma 正则表达式引擎等等）。
Ruby.NET 的维护者 Wayne Kelly 博士现在看来已经在 Ruby.NET 和 IronRuby 之间做出了个人的决定。他在 Ruby.NET 的邮件列表中宣布：
上周在 Lang.NET 讨论会上，我展示了我们在 Ruby.NET 项目上的工作，同时也有机会了解到 IronRuby 项目的进展以及 DLR 的内部运作（Charles Nutter 也展示了 JRuby 项目）。
我的结论是 DLR 无疑会一直走下去，它甚至已经成为微软平台的一个非常重要的部分。我也深信如果想达到产品级别的质量和性能， Ruby.NET 必须要重新发明（或者采用）某种相当于 DLR 的东西。如果今天我们启动这个项目的话，我们没有理由不用 DLR。尽管 Ruby.NET 起初 比起 IronRuby 项目来有一个很好的开端；在引入 Ruby.NET 的解析器和扫描器以及对充分利用 DLR 以后，我此时相信 IronRuby 作为. NET 平台上的一个产品级别的 Ruby 实现将会更有可能取得成功。我认为在.NET 上没有必要最终存在两个不同的 Ruby 实现。所以，如果 Ruby.NET 不可能是这个最终实现的话，那么我们就没有必要再浪费开发者的努力去徒劳地追求这个目标。
动态语言运行时（DLR）协助创建（动态）语言运行时的库。例如，它禁止开发者直接创建MS IL 指令，而是通过DLR 将开发者创建的 DLR 树转换成 MS IL。
最近这种方法正逐渐被关注，因为它为语言制订人简化了许多工作。来自 Ruby In Steel 团队的 Dermot Hogan 描述了如何通过 Antrl 树语法来生成 DLR 树：
现在，在 Antlr 方面我时常碰到的问题是，已经得到 AST 后接下来该做什么？通过 Antlr 得到一个简单的语法很容易，但是要 通过它做点儿什么可就得需要些神迹了，因为 CLR 代码并不简单。但是，通过树语法将 Antlr 的 AST 和 DLR 连接起来就方面多了——看看上面的代码。就 是编写 DLR 的“适配器”类而已。
部分对 Kelly 博士消息的反应集中在IronRuby是否真的是.NET 平台唯一可行的 Ruby 实现。例如， JRuby 团队的 Ola Bini 说道：
我一点儿也不喜欢这些新闻。在很多时候拥有一个强劲的竞争者将会促进生态系统中的每一个人。现在 IronRuby 即将变成这个领 域唯一的玩家，除非其他人（比如 Ted Neward 和 David Peterson）决定接手 Ruby.NET。我希望有人这样做。这会让.NET 的世界变得更好。 关键问题并不在于我们是否相信 John Lam 关于 IronRuby 的想法，而是在于我们是否相信微软在做正确的事情。我们相信吗？
这里提到了重要的一点：因为 Ruby.NET 是一个开源项目，一个开发者的离开并不意味着项目的结束——其他开发者们可以接手并继续开发。
同时， IronRuby 的 John Lam 就此事说道：
我们将会热烈欢迎 Wayne，并邀请任何希望从事 IronRuby 的朋友加入我们的开源项目。微软研究院资助了部分Ruby.NET 的开发，他们的解析器同时也应用于IronRuby。感谢Wayne 在制作 Gardens Point Parser Generator 上杰出的工作。 […]
在 CLR 只有一个单一的实现在.NET 社区是可以理解的。Ruby 不仅仅是语言，还有运行在其上的程序。我们项目中最难的部分并不是如何让语言正确 工作（尽管这也不容易），而是使得 IronRuby 可以运行 Ruby 的程序。不管 Rails 的反对者们过去都说了什么，Rails 依然是一个重要的程序。
这和之前的帖子相印证，在其中 John 提到当前 IronRuby 的开发策略：
最终，我们谈到了如何才能到达 1.0。当前我们正在向全局驱动开发过程转换。我们的下一个目标是让“gem install hoe”工作起来。Rakefile 中包含一个叫做“gap”的任务，可以让你针对目标应用程序通过 set_trace_proc 解释器钩子来进行 gap 分析。
这和 Kelly 博士支持 Rails 的目标看上去很相似：
我依然觉得我们还有未完成的工作——我们将目标设定为可以在.NET 上运行 Rails，但是我们还没有达到。如果我们能贡献出我们的经验用来帮助 IronRuby 实现它的话，至少我个人对于可以帮助这个任务完成而感到非常满足。
注意：无论 Rails 对于.NET 开发者来说有多么重要——其代码涉及到了 Ruby 的大部分特性，尤其是元编程特性。不凡的 Rails 应用在 IronRuby 上工作正常意味着 Ruby 特性的一大部分已经被正确的实现了。通过在 IronRuby 上运行Rubinius 项目定义的可执行Ruby 规格，将会客观地反映IronRuby 的兼容性究竟如何。
查看英文原文： Ruby.NET future uncertain
评论