我也说RUBY

好久不来，都荒的长草了。写点关于Ruby的话。

最近看到又有一个新的Script语言Falcon面世了。众多评论中，偶见一条，说“Ruby臻于完美，就是性能不佳”。

首先澄清立场，我是做Ruby处理机（interpreter, processor）开发的，但我本人不太会写Ruby script。

Ruby最大的问题是什么？很多人都会拿speed说事。但其实放在整个系统中，大多数情况下，Ruby并不会成为系统的性能瓶颈，因为有“数据库操作”这个最慢的家伙垫底。

我接触过一些用Ruby做产品的公司，最大的抱怨不是在速度，而是在规模（scalability）上。比如用Ruby写的library所能支持的最大并发连接数。

另外，C Ruby1.9做过一些optimization，但在力度上还差很多。换句好听的，就是潜力很大。但最大的问题是，没人去做。C Ruby的开发是完全依赖社区的，这点不像Python，JRuby，各类的javascript engine。它们虽然也是open source的，但是背后都是有公司支持的，也就是实际上是商业开发。只不过最终通过open source的形式公布出来。

C Ruby的另一个问题是，内部的实现设计不太好 -- C实现和Ruby实现是混在一起的。Ruby1.9虽然也有VM了，但是VM并没有把Ruby和C从实现层面很好的分离开。
这么做的理由有二：
1，用C实现可以获得暂时的性能优势。一个method直接用C实现，当然要比把它编译成bytecode,然后再去执行bytecode要快。
2，和C的mix是Ruby的一大特色。写过Ruby extension 的都知道，你可以从Ruby调用C写的function，也可以从C调用Ruby写的method。

但是，这么设计的代价就是optimization比较难。如果VM很好的把C和Ruby实现分离，虽然最初会比较慢，类似早期的Java，但是只要对VM实行optimization, 基于VM的部分自然就会获得性能的提升。比如JIT对Java性能的提升就很明显。最近Google 的V8，下一代的Firefox的JaegeMonkey都在考虑导入JIT技术。而JIT技术对现在的C Ruby1.9就作用不大。因为Ruby执行的过程，基本都是调用C程序的过程。已经是binary code了，能用JIT的部分很少。换句话说，如果换个C的编译器，倒是对Ruby处理机的性能影响很大。比如C Ruby1.9引入的Fiber，用GCC4.4编译的性能就比GCC4.3编译的好很多。（GCC4.4对Stack size做了优化）

总结一下，从语言处理机的实现角度来说，Ruby并不完美，而是很不美。问题很多，有技术方面的，也有开发管理方面的。老实说，个人对Ruby的未来很是担心。现在没有什么东西是A语言能做B语言做不了的，一门语言的优势很容易被后来的语言所复制。
Ruby是，路漫漫，其修远。