为什么MRI是主流的Ruby解释器，而它表现最差？
看过这个解释器比较图后 ，我想知道MRI主流使用背后的原因，尽管它表现最差。 为什么不更频繁地使用Kiji或Ruby Enterprise Edition ; 缺乏gem支持或其他什么？ 
例如，Ruby Enterprise Edition是由一些最受欢迎的公司选择的，这归功于它的写时复制function ; 我想知道是否有其他解释器实现它。
REE可以轻松地与现有的Ruby解释器并行安装，允许您以最小的麻烦或风险切换到REE。 REE已经出现多年，已经被许多知名网站和组织使用，例如纽约时报 ， Twitter ， Shopify和37signals 。
“我们切换到企业级ruby以获得[copy-on-write]内存特性的全部好处，我们绝对可以确认其他人报告的内存节省30％。 即使按今天的硬件价格，也可以节省数千美元。“
MRI是Matz的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，这对他们来说“足够快”。