Ruby和Rails的缺点

有人说，robbin你说了那么多RoR的优点，你啥时候说说RoR的缺点阿？你说的缺点肯定比别人说的更客观。没办法，为了表现出来我不是一个RoR粉，只好总结点缺点，以飨RoR黑子们：

Ruby和Rails的一些缺点的总结：

ruby的问题我觉得主要是：

1、ruby本身的性能是比较差的，无法直接做一些计算密集型的任务

比方说大量的分词运算、语料训练什么的，用ruby写是不行的

2、ruby的C扩展很难写

正因为ruby性能差，所以很多情况下要依赖C写的底层库，但是写ruby的扩展C库是很困难的事情。一方面没有特别多的资料介绍，你能参考的只有《Ruby Hacking Guide》，另外一方面Ruby是带有GC的语言，C又是没有GC的，所以如果你对ruby的GC机制没有特别清楚的了解情况下，写C扩展会出现意想不到的问题：比方说你写的程序逻辑没有任何问题，但是和ruby配合起来就会不定期的出现错误，这就是你C程序的某个赋值变量可能会被ruby GC以你意想不到的方式销毁。

3、ruby的C扩展库质量不高，容易出现内存泄漏问题

正因为上面的原因，很多第三方的C扩展库质量不好，很容易出现内存泄漏问题，这是一个很头疼的问题，你很难定位，也很难解决，只能尽量避免使用第三方扩展C库。


Rails的问题我觉得主要是：

1、特别容易出现命名冲突

你自己写的代码里面给类增加的方法，动不动就和Rails给类扩展的方法名称冲突了。这种错误很隐蔽，很难发现。这也是ruby语言动态性带来的一个负面影响

2、Rails每次升级API变动都比较大

Rails升级是不太考虑向下兼容性的，所以每次升级的话，可能你很多代码都要改，更糟糕的是很多Rails插件特别喜欢以hack rails的方式来扩展Rails功能，那么Rails一升级，插件的兼容性几乎肯定是不行的，这个是比较痛苦的事情。

3、Rails的view方面还是比较原始的erb拼接字符串方式，像JSP那样原始，没有一个类似Java的velocity/freemarker那样的页面模版库，所以写helper动不动要用字符串去拼html片断，如果是特别复杂的view需要拼的话，代码就会写的很丑陋。

当然总体来说，RoR还是让我感觉非常满意的，特别适合互联网应用。

评论

21 楼 coolesting 2011-07-04  

现在看这篇文章是不是有点过时了， view用haml可以解决文中所说 ， 而且很多人用sinatra+sequel

20 楼 swachian 2008-06-27  

rails很活跃,也很好,ruby就逊色的多.虽然是ruby造就了rails.
命名冲突比较郁闷,尤其是helper里面的.
说起erb,就让我想到了view.平心而论地说,rails这1-2年间在view层的进步并不大,大部分改进都是和ActiveRecord相关的,比如migration比如引入has_finder等等,而在view层,不管是拼html或者ajax的调用,差不多就是很早以前就达到的水平.各种插件的情况也大致如此,都是绝对加强了model,但对v和c的改进并不大.

19 楼 ye_jian_hui 2008-06-27  

matz也说了他当时做ruby的实现时很大一部份是参考python的实现，从这点上看在C的扩展上跟python像也正常

18 楼 liangshixing 2008-06-27  

为什么不考虑JRuby呢？

17 楼 robbin 2008-06-27  

to yaml:

一些少量的运用的确可以避免用C扩展，比方处理 图片可以直接调用ImageMagick，而不是用RMagick。但是有一些情况是程序需要大量的频繁使用，这种情况就无法回避了。

16 楼 yawl 2008-06-27  

关于nzinfo说

引用

我都怀疑Ruby在代码上抄袭Python了

这点我觉得是褒奖ruby了。在语言设计上，我喜欢ruby远超过python。在实现上，ruby的代码太业余了，python则好很多。matz自己也清楚而且承认这点。

我现在喜欢的和其他语言的库结合方式就是通过命令行，文件或web接口，根本不会碰c extention的方式。正如robbin所说，太麻烦，不值得。

15 楼 nzinfo 2008-06-26  

关于Ruby的扩展，我有话说。:-)
Ruby和Python的接口风格非常像，我都怀疑Ruby在代码上抄袭Python了。
区别在于Python将引用计数的工作交给扩展的开发者了，而Ruby试图自己搞定。
这样，对于开发者的要求就不同了。Ruby的扩展要对语言本身这方面的处理更熟悉。而Python则由开发者控制，在某些情况下，可以牺牲内存来保证稳定性。
我的观点是，开发Ruby的扩展，尽量简洁，可能不是很Ruby Way，但是可以在上层在封装。保证系统的稳定性是第一要务。
如果要我选Web的开发语言，我肯定选Python。至少扩展库方面成熟太多了。

14 楼 koda 2008-06-26  

我是支持字符串拼接写View的，因为这样才简单(概念简单)，易于理解.

13 楼 koda 2008-06-26  

前几天开始学Python，但实在是不太喜欢Py的"__"变量命名方式；昨晚刚想转ROR。结果今天看到大牛你们却开始数落ROR了。我又开始摇摆不定了Orz……

关于这个问题，我的看法是：选择一门语言和框架，要看它是否存在致命的硬伤，如果某个部分的缺陷能迂回解决，就可以接受。

12 楼 koda 2008-06-26  

关于Ruby的性能，是否能从Ruby解释器上下功夫？

11 楼 404 2008-06-26  

引用

你自己写的代码里面给类增加的方法，动不动就和Rails给类扩展的方法名称冲突了。这种错误很隐蔽，很难发现。这也是ruby语言动态性带来的一个负面影响

这个问题太严重了。经常一个错误弄半天，最后才发现是冲突了。

如果是使用Netbeans编辑器的话，在你定义个方法或类时，可以选中方法名或者类名，然后 Ctrl + B 直接跳转到类和方法的源代码，如果不用跳到别的文件里边去，就说明你定义的方法名或者类名是不冲突的。

10 楼 hatedance 2008-06-26  

出个馊主意。
命名冲突可以参考db里字段名跟sql关键词冲突的办法：加前缀。

9 楼 liusong1111 2008-06-26  

传闻lua的C扩展很好吧，还好我做web开发，一般也不用C扩展。
命名冲突会碰上，我的情况是不常碰到，也只好通过跟踪stack trace、查看源码来发现它了。
helper里拼html是不好的模式，楼上几位提到的partial也是我们应对的方案。实在不行，我们就拿ERB.new(tempate_string).result(binding)死抗

我对rails的view方案很有意见，它跟rails塑造的品味不在一个档次，虽然比JSP好很多。
Java的velocity/freemarker我也不喜欢，又一套表达方式，个人看法，还不如ERB呢。
解决方案rails应该向flex的方式看齐。

haml也是另一套语法表达，而且有python痕迹，不喜欢。

malline还不错，只是成熟度有待考查，我们产品不敢贸然引入。
markaby不再维护了？请消息灵通的朋友帮忙证实一下。
malline的地址：
http://www.malline.org/
扩展性不错。
性能方面以前看到个贴说很差，但今天看它的页面里说：

引用

About performance
by Riku, 8 months ago

I have done some preliminary benchmarking between ERB and Malline. I used the templates from Beast to make the compare - rewrote the layout template, too.

Some of the tests are still in progress, but it seems that Malline is about as fast as ERB, maybe a little bit slower on some situations. The latest test tells that overall time taken on 500 page renders was 3% more with Malline than with ERB.

When the benchmarks are ready, I will publish the results here. However, I can already say that Malline is fast enough for production use.

如果能达到这样就很不错了。

bug应该少不了吧。
值得玩一玩。

8 楼 tipfoo 2008-06-26  

前几天开始学Python，但实在是不太喜欢Py的"__"变量命名方式；昨晚刚想转ROR。结果今天看到大牛你们却开始数落ROR了。我又开始摇摆不定了Orz……

前两天见过个测评，说Ruby1.9快1.8.x三四倍?
http://antoniocangiano.com/2007/12/03/the-great-ruby-shootout/
看看上面这个，可信度多少?

7 楼 CaiDeHen 2008-06-26  

你自己写的代码里面给类增加的方法，动不动就和Rails给类扩展的方法名称冲突了。这种错误很隐蔽，很难发现。这也是ruby语言动态性带来的一个负面影响

这个问题太严重了。经常一个错误弄半天，最后才发现是冲突了。

6 楼 dazuiba 2008-06-26  

其他基本赞同，只有一点。我很不理解robbin对rails view的批评。

rsu 说了一个观点。
我这里，针对你说的"helper里进行html拼接"，说一下我的看法：
你完全可以在helper里面使用render :partial。
把html的渲染交给rhtml

相比其他的显示层技术(php,jsp) 我认为rails的view技术是非常先进的。
如果能和helper结合好，会写出非常容易维护的rhtml代码！

5 楼 shaka 2008-06-26  

rails命名冲突确实存在，不知道DHH对此是什么态度。
不过既然用rails，就该遵循它的原则，再说每种语言都有关键字，用错了不一样有冲突么。

不向下兼容，这点不能算缺点吧，感觉只能算是一种态度。DHH也可以让rails兼容，不过那样恐怕又会有新的瑕疵出来。

至于Ruby的性能，现在确实是硬伤，以后会不会解决掉，就要看Ruby的造化了

4 楼 ozzzzzz 2008-06-26  

对于rails的非议现在已经很多了，希望robbin好好总结一下这个方面的内容。
就ruby这个语言的问题，我是十分不喜欢，因为跟我的哲学思想不同。我认同python的哲学。
而就c扩展来说，ruby这个方面比python要有很大差距，毕竟社区的规模与人员的素质摆在那里，不可能很快解决。

3 楼 rsu 2008-06-26  

最后一个关于view的，我不同意。

使用最原始的html concat，才能达到最高的灵活性，而且，helper method也可以写得非常漂亮，如果你使用capture的话，你可以参考一个block_to_partial的现成例子，只要规划的好，可以做到：

<% content_box :background => :white do %>
<%= content %>
<% end %>

这样就比较好看。

另外，为了让view美化，你可以参考haml，请google HAML。

2 楼 haiyang 2008-06-26  

对于命名冲突，不知道javaeye是怎样处理的？