是什么阻碍了Ruby、Python达到JavaScript V8的速度？
有没有什么Ruby或Python的特性，让V8引擎的优化（比如内联缓存）无法实现呢？
Python是由谷歌的人共同开发的，所以不应该受到软件专利的限制。
或者说，这其实是谷歌在V8项目上投入的资源问题。
11 个回答
这其中很大一部分跟社区有关。Python和Ruby大多数时候没有公司支持。没有人会全职为Python和Ruby工作（尤其是CPython或MRI这两个版本）。而V8则得到了全球最强大的IT公司的支持。
此外，V8可能会更快，因为V8团队只关注解释器——他们不需要处理标准库，也不需要担心语言设计。他们只需要编写解释器，仅此而已。
这和知识产权法没有关系。Python也不是由谷歌的人共同开发的（它的创造者在谷歌工作，还有一些其他的贡献者，但他们并不是为了Python而拿工资）。
另一个影响Python速度的障碍是Python 3。语言开发者似乎主要关注的是Python 3的普及——以至于他们已经暂停了新语言特性的开发，直到其他实现跟上。
说到技术细节，我对Ruby了解不多，但Python有很多地方可以进行优化（谷歌的一个项目Unladen Swallow就开始实现这些优化，但最后没能成功）。这里是他们计划的一些优化。如果未来为CPython实现类似PyPy的JIT（即时编译器），我可以看到Python的速度赶上V8，但在接下来的几年里，这似乎不太可能（目前的重点是Python 3的普及，而不是JIT）。
很多人也认为，Ruby和Python如果去掉各自的全局解释器锁，会受益匪浅。
你还得明白，Python和Ruby都是比JavaScript重得多的语言——它们提供了更多的标准库、语言特性和结构。仅仅是面向对象的类系统就增加了很多“重量”（我认为这是好事）。我几乎把JavaScript看作是一种为了嵌入而设计的语言，像Lua一样（在很多方面，它们是相似的）。Ruby和Python有更丰富的特性，而这种表达能力通常会以速度为代价。
JavaScript的解释器需要被高度优化，这就是为什么Mozilla、Google和Microsoft在这方面投入了大量资源的原因。JavaScript需要在用户等待的同时被下载、解析、编译并运行。用户通常是比较着急的，所以它必须在用户与之互动的过程中实时运行。而且，它是在一个不受控制的客户端环境中运行，这个环境可能是电脑、手机，甚至是烤面包机。因此，为了在这些条件下有效运行，JavaScript必须非常高效。
相比之下，Python和Ruby是在开发者或部署者控制的环境中运行的。通常是在性能较强的服务器或桌面系统上，这里的限制因素主要是内存或磁盘输入输出，而不是执行时间。或者可以利用一些非工程优化的手段，比如缓存。因此，对于这些语言来说，关注语言和库的功能特性可能比速度优化更有意义。
这样做的一个额外好处是，我们拥有两个优秀的高性能开源JavaScript引擎，这些引擎可以被重新用于各种应用，比如Node.js。
是什么让Ruby和Python无法达到JavaScript V8的速度呢？
其实没有什么。
好吧，确实有：钱。（还有时间、人员、资源，但如果你有钱，就可以买到这些。）
V8背后有一支非常聪明、专业且经验丰富的团队在努力工作，他们的工资也很高。这些工程师在为动态面向对象语言创建高性能执行引擎方面有几十年的经验（单个工程师的经验加起来可能有几个世纪那么多）。他们基本上就是当年开发Sun HotSpot JVM的那些人（还有很多其他项目）。
V8的首席开发者Lars Bak已经在虚拟机领域工作了25年（而且所有这些虚拟机最终都指向了V8），这几乎是他整个职业生涯的时间。而一些编写Ruby虚拟机的人甚至还不到25岁。
Ruby或Python有没有什么特性阻碍了V8引擎的优化实现（比如内联缓存）？
考虑到至少IronRuby、JRuby、MagLev、MacRuby和Rubinius都实现了单态（IronRuby）或多态内联缓存，答案显然是否定的。
现代的Ruby实现已经做了很多优化。例如，在某些操作中，Rubinius的Hash类比YARV的要快。听起来可能不太令人兴奋，但你要知道Rubinius的Hash类是用100%纯Ruby实现的，而YARV的是用100%手动优化的C实现的。
所以，至少在某些情况下，Rubinius生成的代码比GCC还要好！
或者说，这更多是Google在V8项目上投入的资源问题。
没错。不仅仅是Google。V8的源代码已经有25年的历史了。参与V8开发的人还曾创建过Self VM（至今为止最快的动态面向对象语言执行引擎之一）、Animorphic Smalltalk VM（至今为止最快的Smalltalk执行引擎之一）、HotSpot JVM（最快的JVM，可能也是最快的虚拟机）和OOVM（最有效率的Smalltalk虚拟机之一）。
事实上，V8的首席开发者Lars Bak参与了每一个这些项目，还有其他一些。