（转）国际：Ruby在企业级应用的六大弊端

国际：Ruby在企业级应用的六大弊端  （转自：http://webdev.csdn.net/page/d72576dd-6b79-4c14-82b7-c21af8079926）
2008-03-06 来自：lizhe1985  [收藏到我的网摘]
Zed Shaw ，Mongrel 的开发人，分析了如何依靠项目对语言的适应性来运用包括 Ruby 在内的各种开发语言。针对 Ruby 在企业计算项目的开发，他提出七个有用的做法，并且指出了六个有害的用法。

CIO magazine 已经对 Zed Shaw 所写企业项目需用适用的语言开发这个系列的文章所了连续的报道。如果你关注 Ruby ，你可以查看 You Used Ruby to Write What?! 一文。

Shaw 以 Mongrel (Mongrel是一种快速的针对Ruby的Http 服务器，专门为部署发布rails应用而产生的) 的开发闻名于 Ruby 社区。在采访中，Shaw 针对 Ruby 在企业开发中的运用指出了七个有用的方面和六个有害的做法。

文章的开始，Shaw 指出，有两个问题使得很多项目中选择哪种语言变成了一个越来越技术性的问题，即多语言虚拟计算机和各种语言高效率库的一般利用率：

“当你考虑用哪种语言开发下一个项目时，记住，你最重要的目标并不是独断地，只考虑到执行性或者可测量性等等。而是，你是否能维持一群稳定而且优秀的开发者继续工作下去，直到整个项目获得成功……

“这大概已经远远超越了人们从表面上去鼓吹 Ruby 开发的优点：只要你用 Ruby，或者 Python，或者 Erlang，Haskell，Lisp 等等语言建立了一套软件，年轻人就愿意为你工作。事实上他们学习 Ruby 和其他的语言都是为了兴趣：比如现实一个有趣的想法，比如与朋友们在线冲浪……”

再回到 Ruby ，Shaw 指出了企业开发项目中的七益六害。考虑到 Ruby 在益处方面的介绍已经广为人知，这里只列出他所说的六个有负面作用的地方，想必这也是大家比较感兴趣的：

大量数据碎片

“虽然很无奈，但是不得不承认 Ruby (可用于开发的所有版本，特别是1.9版)已经因为大量垃圾收集器，I/O进程操作等等受到严重冲击。”

图形处理

“我认为很多语言在图形处理这个问题上都没有优势，但是 Ruby 却是在这个问题上显得相当糟糕。Ruby 最初可用于图形处理的库是基于 Image Magick 的，这个库很臃肿，运行速度慢，而且总是需要在各种系统中安装后才可使用。后来，Ruby 又选用了 RMagick ，但是 Magick 又有内存泄漏，很多操作都会产生多余不被发现进程，难以安装（除非你的电脑和笔者的一模一样）等等问题。其它的库就更不要说了。”

繁重的数学计算和处理

“与其他的语言相比，Ruyb 的计算执行率很差。很多时候，开发者必须用 C 或者 Java 重写好几次算法来优化最初的 Ruby 程序。而且这个深度优化算法哪怕是下一个阶段的开发者都很难应用，以至于又不得不重写。”

新语言的发展

“ Ruby 确实可以写出非常漂亮的 DSL (深散射层)，但是在其他语言里都不会指出的 DSL 错误却被 Ruby 指出来了，这个就是很奇怪了。如果你的目的是提供一种可供经济分析家处理日常任务的语言(软件)，那么“undefined local variable 'var' for main:Object”之类的错误毫无益处。在这种情况下，你真正需要的是一个有实际错误检查的剖析器，和一个不依赖 Ruby 的更好的算法。在实际应用中，Ruyb 在这方面可以算是失败了。”

E-mail 处理

“其他任何一种语言的电子邮件处理功能都比 Ruby 要强，用于 Ruby 相关的库只能算是半成品：老旧的 bug ，兼容性不好，速度慢，臃肿……这一切都不能称之为可用。”

服务协议

“ Ruyb 在I/O进程上的问题就是，写一个真正的升级服务简直就是浪费时间。我认识的很多人都放弃了用 Ruby 写服务程序的工作，其它人则是用 Ruby 和 C 混合着写着，要么就直接转向了另一种程序。

“我本来想就 Ruby 的执行速度写一份新的协议原型，但是如果我只想用几个操作，就能实现在每秒种内把这分协议原型发送到小几百人的时候，我就得马上转向另一种语言了。Ruby 中确实有解决这个问题的库，但是很多都因为 Ruby 的 I/O 事件循环而变得别扭起来。”

你对于 Shaw 对 Ruby 在企业计算任务中的评论有什么看法呢？

ruby的这些缺点是被抨击的最多的。糟糕的IO层,低效的垃圾回收...
开发ruby平台的人还不成规模，这是这些问题的根源。
ruby不是万能的，也没有必要是万能的。

Ruby的这些缺点都不妨碍我们使用它，特别是在中小的web项目中，它是把利剑。
这些缺点都可以用一些方式得到很好的解决。

回忆一下java刚出来的时候，还不是同样存在着一些问题。
使用的人多了，渐渐就健壮起来了。

题外话,这篇文章是Zed写的
另外You Used XXX to Write What?! 是IDG的一个系列文章

Zed Shaw刚刚高调告别Ruby社区，他的话可信度值得置疑。



Ruby的GC的确很土，不过Java也经历了一个逐渐完善的过程，这是一个时间问题，GC算法本身经过这么多年探索已经很成熟了，就看Ruby核心开发团队什么时候达到了。




图形处理是非常消耗内存的操作，即便是Java，现在也往往采用封装ImageMagick的jmagick，这和Ruby的RMagick没啥本质区别，更何况图形操作不妨直接调用ImageMagick就好了，这并不是啥问题。



好像没听说用Java来进行繁重的数学计算的，那何必要求用ruby来搞这个呢？



这是DSL自己封装的问题吧，和ruby有关系吗？



我怎么感觉比JavaMail好用的多呢？



这种情况其实早就改变了，你看twitter.com的starling就是纯ruby的高性能消息服务器。

这个可以用miniMagick解决嘛~~~~~~~~~~~~~~~~~~~

我补充一点：RoR的大部分plugin一升级就不后项兼容（包括rails本身）。而且plugin的编写多采用hack的方法，再rails升级后根本无法正常运行。

Robbin你应该怪csdn的傻X翻译，原文在这里，You Used Ruby to Write What?
当然，他们是值得同情的，因为误导似乎是从artima开始的。

最后一段才是真正的Ruby在企业应用的弊端

结尾介绍Zed Shaw的时候，他居然还在用Ruby on Rails，让我很高兴。

关于Plugin的问题你要向前看，RoR毕竟也才2.0版本，PHP从4到5也发生了很大改变，或者就是你用的plugin太多了，file-column这么经典的插件在Rails2中还能使用就是一个很好的典范。

我们用了9个plugins……

Zed A. Shaw is currently a vice president at an investment bank leading a gang of smarties building a cutting-edge document management system, using Ruby on Rails. More important, he writes tons of free software that many people doing Ruby on Rails use all day long. After almost two decades of programming in many languages, he finds writing and music to be more fun. He is now an essayist and antipundit with a very vulgar blog, www.zedshaw.com, that you should avoid.

转了Akita的BLOG上的话,不过他的BLOG看不懂,有兴趣的看这里:http://www.akitaonrails.com/2008/3/1/zed-shaw-strikes-back

关于DSL，我觉得是因为Ruby实现DSL的方式决定的，而不能说是缺点。

通常DSL的实现，是通过一个Parser来解释DSL，而用Ruby来实现DSL通常不要特别的DSL，而是直接用Ruby语言解释器本身。这种方式的好处就是DSL的实现特别简单，而功能却可以十分强大和灵活（因为DSL本身就是Ruby代码，可以嵌入ruby code来作特殊处理）。

“缺点”就是当DSL的语法有问题的时候，提示信息会显得和DSL本身相去甚远，会令人莫不着头脑。当然可以通过仔细设计捕捉错误，显示友好信息，但这不是一件轻松的任务（特别是使用了很多eval语句的时候，这在实现DSL时很常见）。

另外一个简单的解决办法是，用Ruby实现一个简单的DSL语法检查器对DSL预处理。实现语法检查器跟实现Parser比起来，还是简单得多。