相比于 Django、Pylon 等 Python 框架，Ruby on Rails 是否有很大的技术优势？
程序员文章站
2022-04-27 09:50:03
...
如果有优势，主要的技术优势是什么呢？
大概是这样的原因，豆瓣至今还在用 Quixote，因为除了路由分发，其他部分任何框架都已经提供不了太大的帮助。框架提供的是框架的工作模式。
所以我觉得对于一般的应用来说，如果能从框架中得到效率优势，那么 Ruby on Rails 也好，Django 也罢，谁多一点谁少一点关系并不很大。反而文档质量、社区活跃程度、有质量的用户数量（就是在 * 或者邮件列表有中能真正解决问题的用户数量），这些非技术因素影响会更大。 框架和框架之间当然有区别和优势。
比如 Spring 的事务管理。比如 Rails 的快速原型。另外，“轻型框架 Quixote，Sinatra，node 的一些框架”，甚至“没有框架”，也是一种框架。
而选择框架，应该说不是技术人员考虑的问题（现代语言上的差异，有时候小到根本不值得一提）。架构师才需要考虑这些。
考虑 Scalability 下的成本，用 Spring 的服务器集群来管理事物，是否要比上 Oracla 集群便宜？
考虑快速原型，用 Rails 是否能在一个月内拿出个可用的东西给 VC 看？
考虑用户有邮件模版编辑和自动分发的需求，因为 PHP 有现成的产品，是否优先选择他？
考虑系统涉及大量个人数据，基于安全性的考虑是否选择 Java 的框架？
当需求更多样化的时候，还可能需要混合多个框架。
Spring 的 API ＋ Rails ？
如果有简单事物的大量并发，是否考虑加入 Node？
如果有大量数据的简单索引，是否考虑 NoSQL 数据库？
为了多种语言下的不同的库都很重要，是否考虑用 Python 做粘合剂？
今天混合框架已经很常见了。今后，语言和框架恐怕也难以出现大统一。既然大家各占擅场，根据需求组合才是明智的选择。 ruby不像别的社区那么分裂 个人感受
ruby在DSL上有很大的优势。用来测试的rspec非常好用。 自动化的测试非常重要，没有测试，很多东西根本就没办法做。
元编程。python的程序员似乎很排斥这个，ruby则觉得这东西很好。
django的源代码很长，越长就越不好读。老大要我在many to many表中加个method，我记得我至少改动了3，4个地方才把这个method改过来（不排除我的方法有问题）。觉得理想状态是只要更改一个地方就好。
Berkeley讲开发选择了rails，而且在berkeley此前的课程完全没有ruby。而且berkeley的cs61a，人工智能，都是学python的。
We want students to understand that in the real world, programmers are rewarded not for the number of lines of code written or for how quickly they can “bash out” a feature, but for functionality delivered with high assurance of stability and while keeping the codebase beautiful andmaintainablefor continued growth. To many students, especially “hotshot” coders who come into a software engineering course with nontrivial programming experience, the methodologies and techniques we use to do this—design patterns, refactoring, test-first development, behavior-driven design—seem a strange and a dubious use of time.
We have found that students are more likely to gradually embrace these practices if given the best possible tools to support the practices. The Rails community has created by far the most seamless, elegant, and comprehensive tool set to support Agile and XP, and the idea of constantly refining and inventing tools that support testing as well as helping produce beautiful application code is a distinguishing characteristic of the Ruby developer ecosystem. While learning Ruby and Rails will be new to most students, juniors and seniors seem to learn it without difficulty, and far superior tools outweigh the learning costs.
A common counterargument in academia is “Our curriculum already teaches language X, so upper-division courses should leverage that knowledge.” We believe this approach optimizes for the wrong thing. First, software professionals are routinely expected to learn new languages by applying concepts from languages they already know, so “learning how to learn” new languages is a good skill to cultivate in class. Second, a language that makes it difficult to write and test beautiful and concise code is a poor vehicle for teaching those techniques, so the only investment being “leveraged” is syntactic knowledge, a hurdle surmounted with relative ease. Thus, even if our students never use Ruby again, they will have learned how to reduce to practice such important ideas as metaprogramming, higher-order programming, functional programming, and use of closures in the service of higher productivity and more maintainable code. We believe these skills will transfer to new languages, framework, and programming systems. Our survey of alumni of the course that led to this book (see Chapter 13) suggests that our belief is well founded. 从一个软件生命周期来看， 一点优势都没， 只是前期开发效率快点， 软件后期的优化， 性能的提升， 那做什么还得做什么， 那点工作量跑不了。 Rails在web开发效率上（这里只说web），我个人觉得要比Python的web framework有优势，具体都优势大概有三个方面：
语言上
虽然Ruby和Python在许多方面很像，但是也有不少差别，总体来说Ruby要比Python灵活（特别是meta programming），所以Ruby更容易创造出expressive的框架，框架也更容易把更多的overhead解决掉。
设计上
Rails是典型的C2C，convention可以很大的加快开发效率（当然也有种种弊端），而Python崇尚explicit，所以要写的代码会多一些，也没那么多的magic，但是学习起来容易些，不会不小心犯错误。
生态系统上
Ruby几乎整个社区都着重在web development上，而且集中在Rails，所以许多新的idea被创造出来（Cucumber, Capybara, Sprocket, Capistrano/Mina），而且gem/bundler让package management更容易，生态系统更发达。而Python的话，Django自己一套生态系统，但是业有许多其他的框架，资源分散，而且其他框架很难成气候，加上Python另一大应用实在科学计算上，所以感觉在web开发的生态系统不如Ruby发达。 在开发中小网站时rails是最快的 rails可以在一分钟内就可以自动生成原型 这是其他框架做不到的 rails的集成方案封装很全 是社会化编程的典范 插件和扩展远超其他的框架 解决方案和资料都跟很丰富 ruby具备其他语言羡慕的完善的元编程机制 会注定它的智能性比其他框架较高
缺点也很明显 集成度过高会导致臃肿和性能降低 网站规模过大需要依赖架构 ruby社区也在解决这个问题 开发了好几个精简和高性能框架 比如sinatra railsapi等 其他的语言也都在学习和模仿rails 差距已经不大了
另外一个缺点是国内的云平台基本都不支持ruby的 历史原因导致的 随着国内php的不断扩张和nodejs的兴起 rails在国内已经错过了最佳发展期了 至于未来rails能否再度火起 就看37signal公司和社区如何面对新的html5浪潮了 我更倾向于Python.灵活. 优势很大。rails可以快速做出产品上线，rails提供一个完整的框架和最佳实践。这是python框架没法比的。 有一点我感觉很好用，就是数据库迁移(migration)功能，Rails是自带的，而其他Python框架都是通过插件去实现的（Django在1.7版才在核心功能中实现migration，目前还在开发中 Migrations | Django documentation )
回复内容：
我实习时候的指导老师（纯洁的白羊座 @清风 ）在给实习生上第一节课的时候说过这个问题，大概的意思是：你的应用做的越大，框架能提供给你的东西就越少。新型框架在一开始开发的时候会带来很大的效率提升，但是往后发展的时候，这种帮助会越来越少，自己的设计会越来越多。大概是这样的原因，豆瓣至今还在用 Quixote，因为除了路由分发，其他部分任何框架都已经提供不了太大的帮助。框架提供的是框架的工作模式。
所以我觉得对于一般的应用来说，如果能从框架中得到效率优势，那么 Ruby on Rails 也好，Django 也罢，谁多一点谁少一点关系并不很大。反而文档质量、社区活跃程度、有质量的用户数量（就是在 * 或者邮件列表有中能真正解决问题的用户数量），这些非技术因素影响会更大。 框架和框架之间当然有区别和优势。
比如 Spring 的事务管理。比如 Rails 的快速原型。另外，“轻型框架 Quixote，Sinatra，node 的一些框架”，甚至“没有框架”，也是一种框架。
而选择框架，应该说不是技术人员考虑的问题（现代语言上的差异，有时候小到根本不值得一提）。架构师才需要考虑这些。
考虑 Scalability 下的成本，用 Spring 的服务器集群来管理事物，是否要比上 Oracla 集群便宜？
考虑快速原型，用 Rails 是否能在一个月内拿出个可用的东西给 VC 看？
考虑用户有邮件模版编辑和自动分发的需求，因为 PHP 有现成的产品，是否优先选择他？
考虑系统涉及大量个人数据，基于安全性的考虑是否选择 Java 的框架？
当需求更多样化的时候，还可能需要混合多个框架。
Spring 的 API ＋ Rails ？
如果有简单事物的大量并发，是否考虑加入 Node？
如果有大量数据的简单索引，是否考虑 NoSQL 数据库？
为了多种语言下的不同的库都很重要，是否考虑用 Python 做粘合剂？
今天混合框架已经很常见了。今后，语言和框架恐怕也难以出现大统一。既然大家各占擅场，根据需求组合才是明智的选择。 ruby不像别的社区那么分裂 个人感受
ruby在DSL上有很大的优势。用来测试的rspec非常好用。 自动化的测试非常重要，没有测试，很多东西根本就没办法做。
元编程。python的程序员似乎很排斥这个，ruby则觉得这东西很好。
django的源代码很长，越长就越不好读。老大要我在many to many表中加个method，我记得我至少改动了3，4个地方才把这个method改过来（不排除我的方法有问题）。觉得理想状态是只要更改一个地方就好。
Berkeley讲开发选择了rails，而且在berkeley此前的课程完全没有ruby。而且berkeley的cs61a，人工智能，都是学python的。
Berkeley在software as a service这门课程的书中说
Why Ruby and Rails? Why Not Java, C++, Python, or Scala?
We want students to understand that in the real world, programmers are rewarded not for the number of lines of code written or for how quickly they can “bash out” a feature, but for functionality delivered with high assurance of stability and while keeping the codebase beautiful andmaintainablefor continued growth. To many students, especially “hotshot” coders who come into a software engineering course with nontrivial programming experience, the methodologies and techniques we use to do this—design patterns, refactoring, test-first development, behavior-driven design—seem a strange and a dubious use of time.
We have found that students are more likely to gradually embrace these practices if given the best possible tools to support the practices. The Rails community has created by far the most seamless, elegant, and comprehensive tool set to support Agile and XP, and the idea of constantly refining and inventing tools that support testing as well as helping produce beautiful application code is a distinguishing characteristic of the Ruby developer ecosystem. While learning Ruby and Rails will be new to most students, juniors and seniors seem to learn it without difficulty, and far superior tools outweigh the learning costs.
A common counterargument in academia is “Our curriculum already teaches language X, so upper-division courses should leverage that knowledge.” We believe this approach optimizes for the wrong thing. First, software professionals are routinely expected to learn new languages by applying concepts from languages they already know, so “learning how to learn” new languages is a good skill to cultivate in class. Second, a language that makes it difficult to write and test beautiful and concise code is a poor vehicle for teaching those techniques, so the only investment being “leveraged” is syntactic knowledge, a hurdle surmounted with relative ease. Thus, even if our students never use Ruby again, they will have learned how to reduce to practice such important ideas as metaprogramming, higher-order programming, functional programming, and use of closures in the service of higher productivity and more maintainable code. We believe these skills will transfer to new languages, framework, and programming systems. Our survey of alumni of the course that led to this book (see Chapter 13) suggests that our belief is well founded. 从一个软件生命周期来看， 一点优势都没， 只是前期开发效率快点， 软件后期的优化， 性能的提升， 那做什么还得做什么， 那点工作量跑不了。 Rails在web开发效率上（这里只说web），我个人觉得要比Python的web framework有优势，具体都优势大概有三个方面：
语言上
虽然Ruby和Python在许多方面很像，但是也有不少差别，总体来说Ruby要比Python灵活（特别是meta programming），所以Ruby更容易创造出expressive的框架，框架也更容易把更多的overhead解决掉。
设计上
Rails是典型的C2C，convention可以很大的加快开发效率（当然也有种种弊端），而Python崇尚explicit，所以要写的代码会多一些，也没那么多的magic，但是学习起来容易些，不会不小心犯错误。
生态系统上
Ruby几乎整个社区都着重在web development上，而且集中在Rails，所以许多新的idea被创造出来（Cucumber, Capybara, Sprocket, Capistrano/Mina），而且gem/bundler让package management更容易，生态系统更发达。而Python的话，Django自己一套生态系统，但是业有许多其他的框架，资源分散，而且其他框架很难成气候，加上Python另一大应用实在科学计算上，所以感觉在web开发的生态系统不如Ruby发达。 在开发中小网站时rails是最快的 rails可以在一分钟内就可以自动生成原型 这是其他框架做不到的 rails的集成方案封装很全 是社会化编程的典范 插件和扩展远超其他的框架 解决方案和资料都跟很丰富 ruby具备其他语言羡慕的完善的元编程机制 会注定它的智能性比其他框架较高
缺点也很明显 集成度过高会导致臃肿和性能降低 网站规模过大需要依赖架构 ruby社区也在解决这个问题 开发了好几个精简和高性能框架 比如sinatra railsapi等 其他的语言也都在学习和模仿rails 差距已经不大了
另外一个缺点是国内的云平台基本都不支持ruby的 历史原因导致的 随着国内php的不断扩张和nodejs的兴起 rails在国内已经错过了最佳发展期了 至于未来rails能否再度火起 就看37signal公司和社区如何面对新的html5浪潮了 我更倾向于Python.灵活. 优势很大。rails可以快速做出产品上线，rails提供一个完整的框架和最佳实践。这是python框架没法比的。 有一点我感觉很好用，就是数据库迁移(migration)功能，Rails是自带的，而其他Python框架都是通过插件去实现的（Django在1.7版才在核心功能中实现migration，目前还在开发中 Migrations | Django documentation )
下一篇： python能开发单片机吗