这很大程度上与社区有关。Python和Ruby在很大程度上没有企业支持。没有人会因为全职从事Python和Ruby而获得报酬(特别是他们不会因为一直从事CPython或MRI而获得报酬)。另一方面，V8得到了世界上最强大的IT公司的支持。

此外，V8可以更快，因为对V8的人来说唯一重要的事情是解释器——他们没有标准库可以工作，不需要考虑语言设计。他们只编写解释器。就是这样。

这与知识产权法无关。Python也不是由谷歌的人共同开发的(它的创建者和其他一些提交者一起在那里工作，但他们没有为Python工作而获得报酬)。

Python速度的另一个障碍是Python 3。它的采用似乎是语言开发人员最关心的问题——以至于他们冻结了新语言特性的开发，直到其他实现赶上来。

关于技术细节，我不太了解Ruby，但是Python有很多地方可以使用优化(Unladen Swallow，一个谷歌项目，在失败之前就开始实现这些)。这是他们计划的一些优化。如果CPython实现了像PyPy一样的JIT，我可以看到Python在未来达到V8的速度，但这在未来几年似乎不太可能(现在的重点是采用Python 3，而不是JIT)。

许多人还认为Ruby和Python可以从移除它们各自的全局解释器锁中获益良多。

You also have to understand that Python and Ruby are both much heavier languages than JS -- they provide far more in the way of standard library, language features, and structure. The class system of object-orientation alone adds a great deal of weight (in a good way, I think). I almost think of Javascript as a language designed to be embedded, like Lua (and in many ways, they are similar). Ruby and Python have a much richer set of features, and that expressiveness is usually going to come at the cost of speed.

这很大程度上与社区有关。Python和Ruby在很大程度上没有企业支持。没有人会因为全职从事Python和Ruby而获得报酬(特别是他们不会因为一直从事CPython或MRI而获得报酬)。另一方面，V8得到了世界上最强大的IT公司的支持。

此外，V8可以更快，因为对V8的人来说唯一重要的事情是解释器——他们没有标准库可以工作，不需要考虑语言设计。他们只编写解释器。就是这样。

这与知识产权法无关。Python也不是由谷歌的人共同开发的(它的创建者和其他一些提交者一起在那里工作，但他们没有为Python工作而获得报酬)。

Python速度的另一个障碍是Python 3。它的采用似乎是语言开发人员最关心的问题——以至于他们冻结了新语言特性的开发，直到其他实现赶上来。

关于技术细节，我不太了解Ruby，但是Python有很多地方可以使用优化(Unladen Swallow，一个谷歌项目，在失败之前就开始实现这些)。这是他们计划的一些优化。如果CPython实现了像PyPy一样的JIT，我可以看到Python在未来达到V8的速度，但这在未来几年似乎不太可能(现在的重点是采用Python 3，而不是JIT)。

许多人还认为Ruby和Python可以从移除它们各自的全局解释器锁中获益良多。

You also have to understand that Python and Ruby are both much heavier languages than JS -- they provide far more in the way of standard library, language features, and structure. The class system of object-orientation alone adds a great deal of weight (in a good way, I think). I almost think of Javascript as a language designed to be embedded, like Lua (and in many ways, they are similar). Ruby and Python have a much richer set of features, and that expressiveness is usually going to come at the cost of speed.

性能似乎并不是核心Python开发人员的主要关注点，他们似乎觉得“足够快”就足够好了，而且帮助程序员提高工作效率的功能比帮助计算机更快地运行代码的功能更重要。

然而，确实有一个谷歌项目unladen-swallow(现在已被放弃)，目的是生产一个与标准解释器兼容的更快的Python解释器。PyPy是另一个旨在生成更快Python的项目。还有Psyco，它是PyPy的前身，它可以在不更改整个解释器的情况下为许多Python脚本提供性能提升，还有Cython，它允许您使用非常类似于Python语法的东西为Python编写高性能C库。

由于JIT、曲轴、类型推断器和数据优化代码，V8的速度很快。标记指针，双精度对象的nan标记。 当然，它会在中间进行正常的编译器优化。

普通的ruby, python和perl引擎都不做这些，只是做了一些基本的优化。

唯一接近的主流虚拟机是luajit，它甚至不做类型推断、常量折叠、nan标记和整数，但使用类似的小代码和数据结构，不像糟糕的语言那么胖。 我的原型动态语言，potion和p2有和luajit相似的特性，并且性能优于v8。有了可选的类型系统，“渐变类型”，你可以很容易地超越v8，因为你可以绕过曲轴。看到飞镖。

已知的优化后端，如pypy或jruby仍然受到各种过度工程技术的影响。

我相信这是因为不同的设计优先级和用例目标。

一般来说，脚本语言(又称动态语言)的主要目的是在本地函数调用之间充当“粘合剂”。这些原生功能应a)覆盖最关键/最常用的领域b)尽可能有效。

这里有一个例子: jQuery排序导致iOS Safari冻结 那里的冻结是由于过度使用get-by-selector调用造成的。如果get-by-selector可以在本地代码中实现，那么就不会有这样的问题了。

考虑一下V8演示中经常使用的光线跟踪演示。在Python世界中，它可以在本机代码中实现，因为Python为本机扩展提供了所有工具。但在V8领域(客户端沙盒)，除了让VM尽可能高效之外，你没有其他选择。所以唯一的选择是使用脚本代码来实现光线跟踪器。

不同的优先级和动机。

在Sciter中，我做了一个测试，在本地实现了几乎完整的jquery核心。在像ScIDE(由HTML/CSS/Script组成的IDE)这样的实际任务中，我相信这样的解决方案比任何VM优化都要好得多。

因为JavaScript实现不需要关心其绑定的向后兼容性。

Until recently the only users of the JavaScript implementations have been web browsers. Due to security requirements, only the web browser vendors had the privilege to extend the functionality by writing bindings to the runtimes. Thus there was no need keep the C API of the bindings backwards compatible, it was permissible to request the web browser developers update their source code as the JavaScript runtimes evolved; they were working together anyways. Even V8, which was a latecomer to the game, and also lead by a very very experienced developer, have changed the API as it became better.

OTOH Ruby(主要)用于服务器端。许多流行的ruby扩展被编写为C绑定(考虑RDBMS驱动程序)。换句话说，如果不保持兼容性，Ruby就永远不会成功。

今天，这种差异在某种程度上仍然存在。使用node.js的开发人员抱怨很难保持他们的本机扩展向后兼容，因为V8会随着时间改变API(这也是node.js被分叉的原因之一)。IIRC ruby在这方面仍然采取更为保守的方法。