看过这个解释器比较图后，我想知道 MRI 的主流使用背后的原因，尽管它的表现最差。为什么没有更频繁地使用Kiji或Ruby Enterprise Edition ？缺乏宝石支持或其他什么？
例如，Ruby Enterprise Edition 被一些最受欢迎的公司选择，这要归功于它的写时复制功能；我想知道是否有其他解释器实现它。
REE 可以轻松地与您现有的 Ruby 解释器并行安装，让您以最小的麻烦或风险切换到 REE。REE 已经问世好几年了，并且已经被许多知名网站和组织使用，例如 纽约时报、Twitter、Shopify和 37signals。
“我们切换到企业级 ruby 以充分利用 [copy-on-write] 内存特性，我们绝对可以确认其他人报告的内存节省 30%。即使以今天的硬件价格计算，这也节省了数千美元。”</p>
MRI 是Matz's Ruby Interpreter 的缩写。Matz 是Yukihiro Matsumoto的缩写，它是 Ruby 的发明者和主要作者的名字。这就是它是主要实现的原因：它是原始实现，所有其他实现都是后来出现的。MRI仍然是参考，所有其他都需要与MRI兼容。但是 Matz 试图使开发更加规范驱动而不是实现驱动，AFAIK。
为什么没有更频繁地使用 Kiji 或 Ruby Enterprise Edition？
你为什么认为他们不是？我们是一家 Rails 商店，在 REE 上托管我们的应用程序，我个人认识的大多数其他使用 Rails 的公司也是如此。我们也有 JRuby 和 Rubinius 的分支，我们偶尔会对其进行变基，以便我们可以选择最终切换解释器。
使用 MRI 的一个原因是它是语言创建者自己的规范 Ruby 实现，这基本上是 RubySpec 出现之前唯一的“官方”语言规范：
您提到的性能图测试了 MRI 版本。1.8. 当前基于 YARV 的“官方”Ruby 实现 1.9.2 比 Rubinius 或 JRuby 快很多，而且通常更快。因此，这些结论不再有效，尽管许多站点和其他部署使用对他们来说“足够快”的 MRI 1.8。