我本来想把全文贴过来的，结果发现我回帖不到 10 个，莫权限发主题贴，正好有人帮贴，省事了。

@OhCoder 我觉得，我们做出选择的原则是务实，如果你还没有，完整的或是良好的开发技巧，所谓的 Full-stack , 那么你最好学习一个框架，并学习透彻，这里我推荐 Rails，因为 Rails 的设计被很多人推崇，许多其它语种都衍生了类 Rails 的框架，向其借鉴与学习，Rails 在一定程度肯定是很成功的， 另一方面，像大牛们讨论的东西，其实与我们并不冲突，只是各有所需，他们需要的是另一方面的东西“运行率效”，这方面的的讨论 (省略一万字)...,在很大程度上 Rails 能满足你的需求，包括性能。

我赞同文章中绝大多数观点，只有 @robbin 的一个个人结论我不太赞同：Rails 过时了？ 我认为 Rails 在其胜任的场景表现依然稳健，虽然提供的功能太过丰富而显得臃肿，但还不是轻易用 Sinatra 就能替换掉的。

个人认为，没有最好的，只有最合适的，就一般场景来说，rails 足以胜任

我的理解是，我们应该把 Rails 更多的看成一个工具，而不是一个锤子。对于@robbin 说的 rails 过时了，应该是针对开发 web service 的场景下，可以有更好的选择。

@robbin 新博客很漂亮啊

#1 楼 @robbin 我赞同原文里所描述的种种事实，但我觉得没必要提什么“去 Rails 化”的说法，特别不应该在前面加一个“社区”。

我认为“社区”的意义分两个层面：第一，是让处于食物链高端的人们有一个交流、进取、突破、创新的场所。这一点应该是所有社区的终极目标之一，然而这一点针对的恰恰是少数人；第二，是让所有的初学者、入门者、感兴趣的人能够体会到社区的各种好处，比如资料丰富，帮助方式多，热情洋溢等等，这个在少数人看来有点浪费精力和时间，但是如果从整个社群来看，你今天为这群人的付出就像是在为这个社区造血。不为他们做点什么的话，将来有一天高端的那一群人将失去伙伴，越来越孤独，将不再有后来者你追我赶，兴兴向荣。

Rails 的性能从来都不是其骄傲的本钱，这一点好多人都说过，好多人都证明过，但你无法否认它对促进新手接触和学习 Ruby 所起到的决定性作用。不管多少言论和人群在说 Rails 的种种缺点，DHH 一个 15 分钟 Blog，就能让一大群初学者趋之若鹜，兴致昂扬。

为什么？因为两个层次的人目标不一致，追求不一致。当你走过这条路的时候，回过头来你会指出哪里走得不好，哪里走了弯路，或者当初选择哪个会更好。可问题是，你若没有走过，你今天能得出这种结论吗？Rails 提供的已然是走这条路的最佳方案（但不是最优方案，因为最优方案对于初学者往往意味着技术难度，理解能力等方面的门槛）。或许有朝一日，会出现一个性能甩出 Rails 一千条大街，又兼具 Rails 其他种种优点的框架，到那一天不用任何人说，Rails 自然会淡出舞台。

说到趋势，移动的确是趋势，Full stack 的框架过渡到 Web service 的框架也是趋势，然而社区的伟大之处就在其包容性，Ruby 社区从来没有分过 Mobile 化的，No-Full stack 化的，或是 Less-Rails 化的社区，无论什么趋势还是经典都可以有立足之地，容身之所，这不是很好吗？难道一定要为了走得更远的人迎合趋势，就要打出把过去的路变窄甚至封闭的旗号吗？

这不禁让我想起了曾经轰轰烈烈的 Web Standards 的争论，没人说过 WS 不对或者不好，也没人否认它是趋势，但任何人，哪怕是 W3C 这样的庞大组织也无法阻止用户或是其他开发者选择用什么浏览器或者工具。其实没必要这么做，如果你认为某样东西或者某种趋势是好的，你只需要正面宣传，大力推广，努力为其贡献产品和工具，自然就会有人跟随而上；反过来看，凡是举一个必要削一个的，即使本意没错，出发点很好，也会遭致很多人的反感和抵触，并非明智之举。

这篇原文，给 Ruby 社区的一部分人看是非常非常好的，很有启发意义和带头作用，可是对另外一部分（基数很大）却有可能费力而不讨好，我只能说文章是好文章，道理是好道理，可惜不能代表“社区”，或许换一种做法会更有效，比如像 DHH 等人那样做一个积极的推动者。原文后面介绍了其他几个 Ruby 的框架，Sinatra 还提供了一个模板，这就是很积极的举措，只可惜标题太冲了，我估计很多年轻人看了标题就准备开喷了，那些真正有干货的部分能不能坚持读完都让人存疑啊！

为了更方便开发者，Rails 的确是做足了功课，势必在速度上慢了很多。 说 Rails 过时是不科学的，因为 Rails 本身就适用与快速开发， 供创业公司或者团队迅速实现自己的功能，或许在数据庞大后会换用 node,Go 或者其他，但要论起步时，那 Rails 还是有很多优越性的。

標題黨，文章還好，應當換個題目

在 HN 基本屬於月經討論

赞同文中的不少观点，没有最好的技术，只有合适的技术，合适的技术不仅仅关于出现的地方，也跟时间有关；rails 亦然，同一个应用开始时候使用 rails 是个很好的选择，那么在需要的时候用更好的技术替换 rails 也是一个好的选择。

去 Rails 化个人也在一定程度上赞同，所谓去并不是抛弃不用，而是应该不惟 rails；不可否认 rails 成就了 ruby，但是这也使得很多人惟 rails 化了

Rails 作为一个 full-stack 的的框架，确实不适合做 Web Service，但也不能得出 Ruby 社区应该去 Rails 化了这个观点吧

#2 楼 @hysios 多谢指点，受教了，:)

目测此帖必火，先做好沙发。提高知名度先。

我是故意标题党的，目的是吸引眼球，我希望那些停留在 Rails 舒适区的程序员思路和眼界更开阔一些。

更广义来说，我倒觉得不应该局限于某种框架、某种语言，甚至只局限于开发，产品、运营、运维在某种程度上都需要了解。

#15 楼 @robbin 现在是吹嘘Objective-C的时候了，这样客户端和服务端可以只用一种语言...参考 node.js

框架也早就有了 SOPE...

http://sope.opengroupware.org/en/index.html

#17 楼 @bhuztez 移動端安卓佔大頭吧

#15 楼 @robbin 支持啊，有很多好的 ruby 项目贡献者都很少..

nodejs 反人类有点过吧，虽然很多人受不了那深度的嵌套回调。

正能量啊，哈哈，全文认真读完。

#7 楼 @nightire 标题挺好的

ruby on rails作为一个full-stack的web开发框架，并不适合用来开发Linkedin和Iron.io的后台web服务，从某种意义上来说，属于rails的时代已经过去了

全栈式的 rails 不适合做 web 服务，并不一定代表 rails 的时代过去，顶多属于用错了地方，杀鸡用了牛刀

开发 web 站点，sinatra，goliath 框架太过简单，什么都需要自己去搭，padrino 还没有成熟的有代表性的大型网站，而 rails 久经考验，现成的解决方案和资料齐全，这些不太大众的框架应该还取代不了 rails 的位置

移动时代的发展趋势就是：未来服务器端会更多的使用Web Service而不是Website，这也意味着Rails将越来越不适合时代的发展，我个人的结论就是：rails过时了

这个结论应该是 website 不适合时代的发展，website 过时了，rails 只是开发 website 的一种解决方案，照这个理论，php 也该过时了，它在 web 开发时代占据主要地位

用 ruby 开发 web 服务用 rails 的确不是个好选择，只不过从这些论断中也没看出来 rails 过时的痕迹。不过 ruby 太多局限在 rails 的范畴，不希望最后成也萧何，败也萧何

基本的常识又重新说了一遍。我觉得文章里面的好东西就是给出了 ruby 下高并发的解决方案以及实际使用案例，这样在未来的项目选型的时候可以用来作为支撑材料。

#18 楼 @blacktulip 但问题是，Java 不再是当年那个小清新了，不好吹了...

你应该被社区加个 V 的

#24 楼 @linjunhalida 欢迎都去 EC2 上现原型...

参考：http://eric.themoritzfamily.com/websocket-demo-results-v2.html

创业阶段不用 Rails 是不对的，创业成功还用 Rails 也是不对的~

#27 楼 @bhuztez 棒

至少目前我自己的站点还不需要关注 Rails 的性能问题。

Rails 调用堆栈过深，URL 请求处理性能很差 我认为有道理！

#5 楼 @xds2000 Rails 不是锤子，我认同！

ruby 社区曾以敢于尝新和学习为亮点，但是现在偶尔也有固步自封的味道，支持 robbin 的整体观点

楼上说的好，谁都不是锤子

很同意 robbin 的观点，现在感觉开发应用都是往 web service 方向靠，移动设备需要访问，网页也大多都靠 ajax loading 了。一直担心 ruby 在这方便的性能问题，所以最近也去关注了 go，贫乏的类库做真实场景的应用开发真的太累了。非常感谢 robbin 在文章中提供的数据。

最近也在反思 AR 甚至是很早就得到认可的充血模型......

好使的时候就砸下去，不行的时候就换个工具顶上

我觉得也应该转移部分注意力到其他方面了

比如 mruby 这边，日本推上天天看到他们放出来各种好玩的玩意。今天看到一个统计各地家用交流电频率的那么结合硬件的东东，感觉思维跟他们不在一个次元上了。。。

虽然这帖子不讨论领域模型问题，不过既然提到了，就大家探讨一下。领域模型的理解问题就是分久必合，合久必分的情况。在一段时间某一种会被认为比较正确的。最早大家 java 刚刚起来，一股脑的搞贫血模型，再堆上 N 个 xx 层。后来慢慢觉得这种做法又太烦了，就出了其他的模型。到了 rails 里刚开始流行 fat model, thin controller，于是乎写 rails 都往 model 里塞代码。又过了一阵子，觉得这样又不行了，model 越来越大，难以维护，于是乎又开始提炼，然后就出现了7 Patterns to Refactor Fat ActiveRecord Models这样的文章，这种情况就会反反复复的发生。

其实这些想多了也就那样，重要的是不被任何一种理论和传统束缚，不要过份设计，也不要过份重构，当然也不能把代码塞在一个地方，合理的组织代码，结构清晰，测试保证，其他的当作浮云吧。

一切都围绕避免浪费，过度的设计都是浪费，什么场景用什么东西，不要唯技术论。。。

去Rails化是说：不要不假思索的接受Rails给你的一切，不要默认Rails推荐的用法在任何场合都是最优解；而应该自己动手，根据实际应用场景挑选最合适的组件。 确实很有道理。

我是一贯主张改良而不是革命的，libv8 不必要的占运行时 20 兆内存，那就想办法去除它，有 gems 有内存泄露就想办法找到出来，之前我还发现过ruby-prof 和 railsexpress 补丁的相容性问题，发现问题就开 Issue，总还是可以一个个解决的。Rails 4 不也开始强调性能了么？ 对于绝大多数人来说，随便抛弃成熟的 rails 而去使用小众的多的其他框架有点不明智，现在可以说是 web service 时代，说不定明年突然 HTML5 又火了呢？这年头变化快啊！

不管是否 rails，ruby 领域还是有很多东西值得涉及和应用的，可以多多讨论。

我倒觉得这种标题很好，能激发更多的人进来讨论。文章没得说的好，读完受益良多，昨晚看完就在想，该清理一下项目中的 middleware，这点以前都没有想过。

Rails 最要还是东西太多了，目前我参与的 Rails 项目跑起来就得要 100m 每个进程的内存占用，有时候一些比较慢的动作需要异步实现，就得上个 Resque 或 Sidekiq 什么的，有来一个进程 100m + ... 资源足够的时候倒是没多大问题，Rails 随便搞搞都能轻松应对大多数大流量的项目。但自己搞的时候就能明显体现出来，浪费内存就是浪费钱...

但是反过来有又一想，其实大多数访问量不是非常巨大的情况，用 Rails 依然是最佳的选择，上手就可以开始搞，什么细节都考虑到了（比如：安全），每次开始新项目的时候都在考虑，要不要用个轻量级的框架来搞，结果最终还是 Rails，主要还是用 Rails 几下就能搞出东西来...

没想到 Rails 多线程如此不给力，但还是忍不住想去尝试...

#44 楼 @huacnlee 什么细节都考虑到了（比如：安全）

好久没见 @robbin 发帖了

#46 楼 @bhuztez 我的意思是相对于那些轻量级框架，或不用框架来说，他们没被出漏洞是因为用的人少，漏洞没被发现而已

大家讨论还是那个观点，Rails 快是它的强项，不用考虑太多的东西，例如：对于一个月要搞定的新项目，这种事对于 Java 来说是不可能的（有过亲身体会），但用 python + Djiango，4 个人，需求都有，数据库有设计，20 多天搞定（不是最简约的功能）；不知道 ROR 是不是比 python + Djiango 更快？

#49 楼 @garychang 之前的 Study 表明，即便不算 Admin，用 Django 开发实际代码量略小于 Rails...不过是老版本了，现在 Rails 和 Django 大部分都很接近了，除了 Rails 大致上要多占一倍内存以外。

http://www.slideshare.net/itisreal/rails-vs-django-study-presentation

可以组织个 Rails 4.0 vs Django 1.5 Study 么

每每都觉得大牛们讨论这些什么XX已死这类的话题都会有种由衷的景仰。 微感慨，到了不好用的时候自然会被遗弃的，无所谓在现在高呼着未来。

#50 楼 @bhuztez 2010 年的对比图？ 真想看现在的比较。

我觉得说的挺好，不是说 rails 不好，只是用在不同的方面，“我一直觉得 Ruby 社区的很多开发者长期以来待在 Rails 的舒适区里面，完全丧失了探索和尝试其他东西的勇气，其实在 Rails 的世界之外，Ruby 社区的好东西还有很多很多”，这句话说的非常好

我一直觉得 Ruby 社区的很多开发者长期以来待在 Rails 的舒适区里面，完全丧失了探索和尝试其他东西的勇气，其实在 Rails 的世界之外，Ruby 社区的好东西还有很多很多

中枪！

libv8 只出现在 group :assets，生产环境下应该不会占内存

回归正题：对于绝大多数开发者来说 Rails 舒适区是最好的，需要跳出去的早跳了。这个标题反而容易误导普通开发者，毕竟大多数还是在做桌面版网站。

#55 楼 @swordray 我也这样觉得

#51 楼 @hsming 人家也没说已死啊

启发很大，躺在 rails 的温床太久了...一些性能敏感的模块或许不适合使用 rails 实现吧，毕竟并发模型放在那里，适合 WEB 项目，不是 WebService 项目

刚入行的新手看得好心凉～

#60 楼 @eva 怎么会，你可能没注意到，我这前发的内容 Rails 还是有非常重要的意义的

# POST /posts # POST /posts.json def create @post = Post.new(params[:post])

respond_to do |format| if @post.save format.html { redirect_to @post, notice: 'Post was successfully created.' } format.json { render json: @post, status: :created, location: @post } else format.html { render action: "new" } format.json { render json: @post.errors, status: :unprocessable_entity } end end end status: :unprocessable_entity 这是什么语法？

#62 楼 @luoie 你是不能发帖，所以搭车提问嘛？答案在这里。

#58 楼 @search 我知道。我是说这类的断言

走自己的路，让别人去说吧，喜欢 rails

我在其他平台混迹了这么久，刚来 rails 就遇到这种文章也很沮丧

#52 楼 @zhangjingqiang 这是什么，不知道唉

选择什么样的框架主要还是要看面对怎样的环境和解决什么样的问题

#67 楼 @aisensiy #50 楼分享的 slide 中的数据，有些旧了。

我觉得高并发不是网站开发的唯一问题，很多网站并不需要很高的并发能力。框架也不是只为解决高并发而生的，解决高并发还有其他很多途径。

只有长连接需要高并发，特别是聊天或者游戏服务器的场景，而且都有相应的解决方案... 大部分网页都是一下就搞定的并发有个鬼用...

@zhangjingqiang @bhuztez 写页面绝对是 django 比较慢，那个模板略蛋疼啊... 一个 admin 搞这么久是他们不对，都不会查一下各种 admin 的 gem...

#71 楼 @luikore 估计是框架 vs 框架不准用第三方的吧，不然就没底线了...

#72 楼 @bhuztez -_- 不然读者就能看出这个比较没实用意义了

有几家网站可以达到 LinkedIn 的规模，一般的网站，Rails 足够了。 一开始的 Startup 目标是效率和生存，选择 Rails 是有原因滴，性能等问题等做大了，有资源了，到时候自然会解决滴

#46 楼 @bhuztez django 其实去年也改了 yaml 的安全漏洞... 用比较老的 django 也会有和比较老的 rails 一样的安全问题... 但是老版本已经没有讨论意义了，关注 CVE 搞 0day 爆破才有效益...

饱汉不知饿汉饥啊

#75 楼 @luikore 是有相同的安全问题，但是攻击界面不一样。Django 就没提供处理 YAML 输入的 util...YAML 只是用在 fixture 而已。

但是老版本已经没有讨论意义了

难道你觉得用 Rails 的都已经升级到 4.0 了...

#73 楼 @luikore 不然连比较的基础都没了...于是就等于没可比性了，但显然还是可以比的嘛

昨天试了一下 Padrino, 生成 Admin 确实很快很好用，但还是觉得还是应该从 Rails 学起，也许正是像@robbin 所言，Padrino 是高度模仿 Rails 的，另外非常赞同的是@robbin 说的未来 webservice 的方式会成为主流

#77 楼 @bhuztez

用相同的开发流程比较，就容易 bias 到自己熟悉的那边... 实际用法区别巨大，用各自特色的功能就比较不起来了...

攻击者也不好混啊，有攻击价值的站不多，vurcurex 还是开发人员没订阅更新，在周二被 1day 的

#80 楼 @luikore 可以先找两个框架都没听说过的人来写个 spec...之后比总时间就是了。再说了，Rails 4.0 和 Django 1.5，基本上没啥区别了...

攻击者也不好混啊，有攻击价值的站不多，vurcurex 还是开发人员没订阅更新，在周二被 1day 的

所以还是冒充是 PHP 写的好？

#81 楼 @bhuztez 我拼错了... https://vircurex.com/

其实 ruby 在并发问题上是比较弱一些（或是做的不漂亮），因为并发模型并没有内建于语言之中（像 Erlang, Scala 的 actor），又一直没有一个很漂亮的并发库。matz 也承认这一点（为没有在语言中内建并发模型感到后悔）。

这是我近年来看到的，ruby 方面最精彩的文章。

当年看了下 rails，被 ActiveRecord 迷倒了，因为没写过 MVC，不觉得 MC 有啥厉害的。 后来看来这个： http://raganwald.com/2006/05/how-to-make-programming-hard-for.html

再去看了 ActiveRecord 的源码，才了解到原来 ruby 是这么用的。 不过这个大哥的文章，比我了解的深入太多了。

知其然，知其所以然。才能用好，用对。 用信仰和喜爱程度、使用人数选择要用什么的，这个太幼稚了。

用了 mongoid 不用 AR 了，前端全部交给 backbone 了，感觉去 rails 是挺适合我的

搭车求助：有没有好的 ruby 编辑工具啊，比较输入一个类自动就提示类的方法了

#86 楼 @93327715 rubymine 吧...

@lgn21st ， status: :unprocessable_entity ---- 最新 RAILS 代码 :status => :unprocessable_entity 这两个功能一样吗？

#88 楼 @luoie 这是 Ruby 1.9 的新的 Hash 语法呀，这两个写法在 Ruby 1.9 以后是一样的。

hash = { :name => "David", :age => 49 }
hash = { name: "David", age: 49 }

@lgn21st 我是搞驱动的。准备学习 rails。咋不能发贴？

#90 楼 @luoie http://ruby-china.org/topics/9650

#92 楼 @NonTwitter 更新 ruby tmbundle 即可

@luikore 嗯，发完突然想起来可以升级的，蛋疼了，话说删除回复的滞后好厉害啊，我清空了浏览数据，再刷新了 N 次都还在

我一般都只用 rails-api 或者 sinatra，不用 rails

现在推荐 grape，直接用 rake...

@zeeler grape，不知道会不会带来性能瓶颈的问题

#97 楼 @naitnix 看怎么用了，cache 要利用好，数据持久化部分也有好多技术可以优化

@zeeler ，我这边是用 grape 做的基于地理位置的搜索，给定坐标搜索基于该坐标的附近建筑，类似这种，貌似是不能用 cache 吧，我觉得瓶颈问题应该是在并发上，路由解析上，其他的应该是业务逻辑的问题了

#99 楼 @naitnix 可以 cache，只不过命中率可能比较低；这种场合 cache 不是最主要的，搜索本身是可以优化的，不知道你用什么方式做的搜索，这里可优化的地方很多

#89 楼 @lgn21st 你忘记引号了

#101 楼 @zzWinD 谢谢，已经修正。

用 rails 开发还是很爽的

@zeeler 如你所言，这种搜索用 cache 确实不适用，搜索用的是 elasticsearch

ruby 效率问题应该不大，rails 的确是有些过于臃肿，但是开发起来很爽。ruby 很多 web 框架，就好像 python 也有很多框架一般。 如果只是一个普通的站点，你从来不用考虑过多的性能问题，你什么时候见到 ruby china 抱怨过 rails 巨慢，垃圾的要死呢。 经常出现的问题就是一个逻辑占用的资源远远比 rails 大，普通的站点瓶颈一般不会出现在框架上。

不过话说回来，ruby 社区的确是应该去 rails 化了。我不敢说 rails 过时，而且很多新手就是冲着 rails 来的。但是等他们弄完 rails，他们在社区里应该更加关注 ruby 本身的东西，同时为 ruby 发展做出更多贡献，而不是需要问问题的时候跑来问一下 rails 的问题，然后匿了。

#105 楼 @vincenttone 我记得好像以前看 ruby china 有个帖子说网站曾经跑在 Linode 上，启动了两个 Thin 进程和一个后台 resque，然后内存就不够用了，网站并发访问一高就很慢，似乎是抱怨过 Rails 的吧。

我个人网站：robbin 个人网站 跑在 Linode512 上，用 rainbows 跑了两个进程，每个进程跑 32 个线程，每个 workder 进程稳定使用 70MB 内存。调大 GC 参数以后，每个 workder 进程稳定在 110MB 物理内存，可以轻松支撑很大的并发访问量。

RUBY_HEAP_MIN_SLOTS=600000 RUBY_FREE_MIN=200000 RUBY_GC_MALLOC_LIMIT=60000000 export RUBY_HEAP_MIN_SLOTS RUBY_FREE_MIN RUBY_GC_MALLOC_LIMIT

前个项目也是去 rails 做的，和 robbin 思路一致。结果现在找不到工作，ruby 公司大多用 rails

#107 楼 @gyg22 可以来 CSDN 试试，我们现在还是很缺 Ruby 程序员的，可将简历发给我：fankai AT gmail DOT com

@robbin 好的好的，这就去发了

谢谢分享。

我的想法是用 Rails 起步快速开发，在商业模式和规模逐渐提高的时候通过监控找出瓶颈迅速剥离成 service, 分开 scale。剥离的模块会功能比较单一而且数据核心，用 Sinatra / Grape 比较合适。这会是个比较好的折衷 / 兼顾。我看到的太早考虑 service 架构的往往都变的 YAGNI，而且开发成本太高

Padrino 起步这条路还一直没有机会用，可以尝试一下。

@robbin 你用的 linode 机房是哪里的？

#20 楼 @Tim_Lang nodejs 回调机制加 async 库，非常爽的 我开始也是看到一大堆嵌套就怕了，直到看到了 async 库

新手，，，

#111 楼 @mobiwolf 东京机房

#112 楼 @danielking async, nodeproxy，wind.js 等等，只是把嵌套换了一种表现形式而已，没有从根本上消除复杂度。

rails 适合敏捷，其他几个框架之前还真没听过，惭愧

#110 楼 @knwang 恩，我现在也是这个想法，不过实践中还没机会落实过

#105 楼 @vincenttone 说的真好，这才是社区的精神！

危言耸听

ruby 这么好的语言，的确不能之用来挖 rails

本来 ruby 就不是只有 rails 的啊，支持

@mvj3