John Lam如何评价Ruby.NET与IronRuby差异

最近，M. David Peterson在O'Reilly Network发表了一篇名为《Ruby.NET与IronRuby：差别在何处》的文章。这篇文章引起了微软IronRuby项目的领导者——John Lam的注意。John在David文章后面跟贴，阐述了他自己对于IronRuby的一些观点。

David在文章中对Ruby.NET和IronRuby进行了比较。关于IronRuby，David说：

* IronRuby构建于动态语言运行时（DLR）之上。DLR是CLR的一个扩展，致力于支持静态类型语言（如C#）和动态语言（如Ruby）之间的差异。

而对于Ruby.NET来说

* Ruby.NET构建于CLR之上。考虑到DLR是CLR的一个扩展（换句话说，DLR需要CLR), IronRuby和Ruby.NET在能力方面并没有根本性的差别。

John解释了DLR为那些使用它的语言所带来的好处：

• 共享的代码生成引擎。使用我们的代码生成API比Reflection.Emit更加简单，所以这为编译器实现者们节省了时间。这同时也意味着DLR在未来的性能提升会惠及那些基于DLR的语言。
• 公共的宿主接口。我们扮演的是宿主与编程语言之间的中间人的角色。如果你编写的宿主程序面向DLR，那么我们的编程语言（以及那些虽然不是我们编写的，但基于DLR的编程语言）不需要任何特别的努力就可以与你的程序协同工作。而我们的团队正在构建Silverlight和ASP.NET的宿主程序。

另一个随之而来的问题是，如果CLR已经赋予编程人员访问任意与CIL兼容语言的能力，那为什么还需要面向DLR进行工作呢。如果无法回答这个问题，那么很明显应该选择Ruby.NET而不是IronRuby。

对此David提出了一个根本性的问题：

对于编程者来说，需要的到底是CLR所提供的强大语言互操作能力（这也是 Ruby.NET的所长之一），还是DLR所提供的动态语言性能优势（这则是 IronRuby的优点）？

John进行了回复，解释了他的观点：

我不认为使用DLR会失去任何与现有基于CLR的语言族之间的互操作能力。虽然对于我们来说，到现有基于CLR的语言的动态分发机制确实还有很大的改进空间（你应该更愿意用C#或VB.NET调用Office API吧？)，但现在在C#中调用IronRuby library代码应该没有什么障碍。只要你通过我们的宿主接口（hosting interfaces）进行，互操作就可以很好的工作。我不清楚对于像Ruby这样要求上下文环境的语言来说，如何能够在不传递上下文环境的情况下，保证在C#中可以调用任意Ruby.Net代码。

David同时说：

IronRuby动态编译的特性使其更适合那些在编译过程中可预测的部分较少的程序，比如客户端应用。反之，对于服务器端这种可预测部分很多的程序来说，Ruby.NET可能更加适合。

John回复道:

Ruby.NET采用了静态编译模型，其优点之一在于减少了冷启动时间。由于Ruby.NET的装配必须是JIT（Just In Time）的，所以Ruby.NET仍然需要处理CLR的冷启动问题。而IronRuby则采用了生成IL和JIT代码的方法。我想暂时把这一讨论放下而说一点题外话。对于客户端应用来说，冷启动时间至关重要，而这也正是Ruby.NET的优势所在。我们曾经在IronPython中使用过一个AOT编译模型，但已经将其从的DLR 1.0的特性列表中去掉了。关于这一问题，我们会在1.0之后的版本中重新考虑。

David这篇文章的原文已经在John Lam发表看法后进行了修改，不过文章仍然留下了几个没有回答的问题。关于Ruby.NET和IronRuby，Ruby开发者现在想知道的一个问题是什么时候Ruby on Rails可以在这两个平台上运行。据Ruby.NET社区的一名开发者称，在完成Ruby实现中的几个关键构件后，才能考虑在Ruby.NET上运行Ruby on Rails。关于IronRuby是否会支持Ruby on Rails在其上运行，除了John Lam在07年RubyConf的表态外，尚无任何具体信息。而跟据Seo Sanghyeon的说法，融合Ruby 和.NET的最初工作是RubyCLR，由John Lam所创建的一个项目。

当考虑在IronRuby、Ruby.NET和RubyCLR中进行选择时，会涉及许多问题。这些项目目前尚处于初期，因此如果你打算在.NET平台上编写Ruby代码，密切关注这些项目是一个明智之举。

关于IronRuby的更多信息可以通过IronRuby网站和John Lam的个人blog获得。

查看英文原文：John Lam Responds to Ruby.NET vs. IronRuby