Sun公司收编JRuby

9月初，Sun公司雇佣了JRuby开源项目的两个核心开发人员Charles Nutter和Thomas Enebo，专职从事JRuby开源项目的开发工作。从Charles Nutter和Thomas Enebo的私人博客的字里行间，我们可以感受到他们对Sun公司对于JRuby项目认可，以及对JRuby项目提供了大力支持而无比振奋。

这是Charles的blog
http://headius.blogspot.com/2006/09/jruby-steps-into-sun.html

单纯从web项目的开发效率上衡量，Java已经无法和ruby on rails相提并论，但有趣的是Java并非完全站在ruby on rails的竞争对立面。由于ruby的第三方库远远无法和Java相提并论，其运行效率也无法和成熟的JVM相比，而我们知道，JVM从理论上来说，也并非可以仅仅支持Java一种语言。因而将ruby移植到JVM上面来，结合ruby的开发效率优势和Java丰富类库支持，强大Java运行平台优势就是顺理成章的事情了，JRuby正是实现这一目标的框架。而Sun对于JRuby提供的强力支持，更加表达了Java与ruby携手的决心。

当前JRuby还仅仅只是使用Java来解析执行ruby程序，目前已经可以支持ruby1.8.4，而且可以把ruby on rails的简单应用跑起来了。但是由于不是bytecode级别的解析，因而执行效率很低。JRuby team未来则期望能够直接在Java平台上面把ruby程序编译为bytec ode执行，以达到本地Java代码的效率。不管怎样，JRuby项目的前景都是值得我们期待的。

我现在对这类动态语言的非本质实现抱很大的怀疑态度。
最近除了这个新闻以外，IronPyton(python的.net版本)1.0也发布了。但看了一下，感觉虽然不是特别差，也是差得可以。也许这是给那些熟悉.net同时又想找一个动态语言的人一个选择？
两个语法相同但是标准库有差异(jruby可能语法上也略有差异)，支持库有重大差异的语言，还能算是一个语言吗？
当年不论出于什么原因，Sun对于MS污染java的行为举起了大棒，现在这几个开源社区的动态语言，却纷纷搞出这么些方言来，不好说阿。

IronPython和JRuby可能还是不太一样的。dotnet平台实际上提供了自己统一的dotnet fraemwork类库，所谓不同的编程语言支持，更像是一种语法糖衣而已。但是JRuby其实实现了大部分ruby自己的库，用JRuby并非仅仅用一个ruby语法而已，关键是ruby本身的方便的库和rails框架，至于Java库的支持，只是辅助了。

Sun对JRuby的支持表明了一种态度，这种态度是承认ruby在企业快速开发方面的优势，而对ruby提供更好的支持。而Microsoft支持的IronPython更像是用python语法写C#程序那种感觉，换汤不换药。

IronPython也实现了绝大部分的python标准库。
关键的问题是社区资源的共享，或者说双向兼容性。首先是原生脚本移植到其它VM平台版本的问题，理想情况是任何的标准脚本，只要是 python/ruby的，那么不论跑在哪个VM版本上，就应该能够顺利跑起来。但是因为一些依赖关系，某些特殊的语法缺失，以及大量第三方lib特别是那些用C/C++编写的lib的移植问题，使得这几乎成为一个奢望。最近jruby为了让rails顺利跑起来作了很多工作，但是现在还不能算是大功告成。如果移植的代价小，或者有便利的工具可用(就像现在开始编写的经典python程序向python3000的移植工具)，这个还是可能执行的任务，但是对社区而言，浪费了太多的重复劳动
另一个方向是从VM版本的脚本程序向标准版本的移植。实际上，如果使用IronPython或者JRuby，肯定是想在.net或者jvm上作一些平台相关的动作,不论是从界面或者性能方面来考虑。这样，这种移植实际上是不可能的。
将来很可能是有一个主流的标准版本(不论这个版本是不是目前的C/C++版)，和一堆支流，这些支流或者各有特色，但从发展上来看，总是很难跟上主版本的步伐(这次IronPython是个例外，号称实现了2.5的特性)，而且其延续存在性很大程度上决定于少数几个关键开发者的兴趣(比如jython自从创始人去搞ironpython之后，几乎陷于停顿)

你说的有道理，不过移植VM这件事有利有弊，还是让‘市场需求’来决定吧。本来python和ruby对移植性都是比较宽松的，何况不同的项目对移植性和功能实现有不同的诉求。

IronPyton 是将 python 程序编译成 .net 的 IL 代码，执行速度已经比 CPython 要快了。
我想不管是 IconPython , 还是 JRuby，它们都不是给python或ruby程序员用的，而是给 .net/java 程序员用的。

发现这不是Sun的第一次，前一个是TCL，不过现在已经离开了
http://blog.csdn.net/ganxingming/archive/2006/09/11/1210067.aspx

huangyi，ironpython编译成什么样的IL代码？因为jython虽然编译成字节码但实际还是内嵌一个python解释器，所以虽然有VM提供JIT但速度和cpython还是在仲伯之间。C#编译出的IL代码速度一般是cpython的10－20倍左右，ironpython有cpython的5倍就非常不得了。

我记得原文说是很多情况下ironpython性能优于cpython，这个很多就很难界定了。就和前段时间有帖子说python写的程序比C写的快一样
如果是计算密集型，还是shootout的结果比较客观一点，毕竟大家都是python语法，就不存在是不是贴切实现的问题了
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=python&lang2=iron
至于典型情况下如何，谁也说不清楚。除非用这两种实现对所有的标准库和知名的第三方库和软件进行benchmark，这个就不太可能了

http://www.infoq.com/presentations/JRuby