【IT168 资讯】长时间的等待之后，开发者终于迎来了Rubinius 1.0。项目团队花费了三年半的时间完成1.0版，并且提供了部分承诺的特性。Rubinius极力向开发者宣传它的各种新特性，包括：
1.支持大量的Ruby代码和流行的C插件：Rails 3和2.3.5；Sinatra；sqlite3、mysql、nokogiri和yajl-ruby及数不胜数的其他插件
2.加速Ruby代码运行速度的JIT编译器。
3.新一代的垃圾收集器。
4.集成剖析器。
我们之前曾经报道过Rubinius，例如在RubyConf 2009上采访Evan Phoenix并且询问项目的进展情况。我们也撰写了Ruby标准展望，其中Brian Ford阐述了Rubinius是如何紧紧和标准联系在一起的。时至今日，我们又采访了Brian Ford和Evan Phoenix，就Rubinius 1.0现在和未来交换了意见。
既然Rubinius 1.0已经发布，我们希望知道这个发布版对于Rubinius的现在和未来意味着什么：
我们花费在1.0版的四年时间是非常值得的。你可以看到，在这四年中，我们不仅完成了一个能够和1.8.7兼容的Ruby运行时，而且还应用了加速动态语言的最新研究成果，这些成果包括新一代的垃圾收集器和集成的JIT编译器。我们希望尽可能地使用Ruby来编写代码，即便可能有一些性能损失。这是因为Rubinius是使用ruby来实现方法，而MRI是使用C。但是，我们一直致力于性能的改进，这就是你所看到的Ruby和C在性能上的竞争情况。
和现存的Ruby框架兼容情况：
完全兼容。在以某种方式运行Sinatra程序的时候会出现一个诡异的bug，不过现在我们已经解决了。我们会将用户反馈的任何框架相关的bug的优先级设置为最高，然后在下一版本中解决。
当我们询问Rubinius对现存Ruby gems支持问题的时候，他们说：
如果是纯Ruby gem的话，那么没有兼容性问题。我们也支持大量使用C扩展的gem，例如Nokogiri或Mongrel等等。不仅如此，我们一直将一些并不支持的扩展移植到支持的API上。其实，有些API不能够支持的原因是这些API直接将某些结构体的指针暴露出来了，而这些结构体在MRI中被当做内部类使用。比如。RHASH()支持开发者访问一个‘st’结构体指针，这个结构体被MRI用于实现Hash类。由于我们不用手动使用st来实现Hash，所以不需要暴露这个指针。因此我们重写了API，在提供相同功能的同时也避免了这些情况。
我们也听说strings在Rubinius的性能有下降。考虑到strings在Ruby程序中使用率非常高，我们希望能够知道现在Rubinius能够给我们带来什么，以及它的未来发展会是如何：
说所有的string性能都比1.8.x有下降是不准确的。String的大部分方法性能都至少和1.8相当。仅仅是一部分性能较慢，例如tr、gsub和unpack。我们现在非常积极地改进这些性能缓慢的方法。
性能问题一直是一个值得关注的话题。当InfoQ问到为何Rubinius是比其他Ruby实现，例如MRI 1.8.x/1.9.x和MacRuby更加值得选择的时候，他们回答道：
Rubinius运行Ruby代码的速度极快，如果可以使用纯ruby代码实现的算法做基准测试的话，Rubinius肯定稳居榜首。由于我们独特的JIT技术，我们能够提供比MacRuby更加优异的性能。这项技术能够高效地利用程序剖析信息，从而产生更加快速的机器代码。
开发者看到Rubinius性能较低的时候是因为Rubinius正在运行一些核心类的代码。我诚恳地请求开发者能够在我们的问题跟踪器中发布关于性能缓慢的报告，或者能够直接向#rubinius反馈。每一个发布版都会着重解决性能问题，最终目标是Rubinius的所有核心类方法的性能都要比1.8中的要优秀。
Rubinius是一个开源项目，它的发展和成功得益于活跃社区的贡献。社区给予Rubinius非常大的帮助：
我们非常高兴地看到我们开放的代码库也协助开发者持续为我们的项目做出贡献。并且，系统的绝大部分是使用Ruby实现，我们可以快速地增加和调试功能，然后提供给用户新的特性。
社区最大的好处就是它能够即时帮助我们测试代码以及发出反馈。这将帮助我们快速成长和克服困难。
当问到近期和远期分别可以对这个项目抱有什么期望的时候，他们回答说：
我们已经计划发布下一个bug修复版。1.0.1将会在下周发布(5月24日这周)，并且会修正1.0版中很多bug。
我们另一个高优先级的任务就是第一个新特性版本：1.1，它增加了调试器。我最近将大部分精力放在这个版本上，它很快就会发布。这个版本将调试器紧密集成在一起，我想用户会非常喜欢它的。
查看英文原文：Rubinius Turns 1.0
