Rubinius团队刚刚宣布,Rubinius 2.0发布。Rubinius的上一个版本(1.2.4)已经发布两年多了,支持Ruby 1.8.7。其后,Ruby 1.8被弃用,Ruby开发人员强烈要求从1.9升级到2.0。
\按照计划,Rubinius 2.0完全支持即将到来的Ruby 2.1,其发行公告中有如下说明:
\\\在2.0中,Rubinius重新恢复了对Ruby未来版本的重点支持。Rubinius 2.0预期兼容Ruby 2.1。而MRI尚未发布Ruby 2.1,Rubinius只能随其更多特性的最终完成而不断改善自身的兼容性。
\
从今往后,Rubinius的版本发布周期将大大缩短。新版本计划每周发布一次:
\\\我们转而采用这一发布过程是为了把更新尽快地传递到开发人员手中。不管我们做了多少工作,总有更多的工作要做。一个新版本看上去似乎永远不会完成。每个版本都要经历痛苦的纠正过程。因此,我们遵从了下面的建议,“如果某件事是痛苦的,那么把它推到前面,并通过工作来减少疼痛。” Rubinius 2.0对Ruby 2.1的兼容可能会有Bug。[……]
\我们的目标是,从3.0开始构建Rubinius内核的语义版本。在从2.x向3.0过渡的过程中,在引入破坏性更改时,我们会非常小心,但如果那样做的好处超过风险,我们就会去做。
\
Rubinius 2.0在多线程支持方面取得了很大的进展。它带来了一个虚拟机,用于运行由编译器生成的字节码。它还实现了一个即时(JIT)编译器,以获得更快的速度(目前速度提升了2到4倍,但他们希望进一步提高)。因为Rubinius不受全局解释器锁(GIL)的限制,而且实现了原生线程,所以Ruby代码能够利用多个内核和CPU。这也有利于垃圾收集器,它可以部分地运行,而且可以与正在执行的代码并行。关于这一点,Rubinius的Brian Shirai在接受Jesse Storimer采访时详细描述了更多的细节。
\InfoQ获得了与Brian谈论这一新版本的机会。Rubinius 2.0承诺兼容Ruby 2.1,而后者尚未最终完成。你们已经实现了Ruby 2.1的哪些内容?
\\\我们正设法跟踪MRI为推出MRI 2.1所进行的开发工作。MRI团队已经多次承诺,Rubinius 2.0本质上向后兼容2.0和2.1。我们大量翻阅了2.0的规范,从中基本上可以看出,与1.9相比,2.0的行为没有发生很大的改变,但也有若干行为发生了变化的情况。
\简而言之,我们打算在2.1发布的时候尽可能多地支持2.1。在此期间,如果有严重的冲突,我们将继续2.0的行为,直到2.1发布。
\
InfoQ:Rubinius 2.0支持Windows吗?
\\\Windows肯定在我们想要支持的清单上。但是,我们需要先看看,如果有人迫切需要这种支持,我们才会对此投入稀缺的资源。
\
InfoQ:现有应用程序和框架可以很好地与Rubinius一起工作吗?例如,Rails 4能够运行在Rubinius上吗?
\\\关于Rails 4,有一句广为人知的话,它“喜欢”Ruby 2.0。我们预计Rails 4能够在Rubinius上运行。如果不能,那很可能是Rubinius的Bug(但也可能是Rails的Bug)。
\
Rubinius 2.0可以从rubini.us上下载。我们很乐意听到开发人员的使用体验!
\