For RubyChina's Rubyist, 是时候为 Rails 圈子打打气，Ruby 圈子创新能力依然在，Rails 活力依旧。
本文成因
最近朋友中加入了不少对技术不十分了解的朋友，我希望能够简单有效回复他们 Rails 是干什么的。
是时候抬头看看整个 web 技术圈子发展的情况，总结一下，也顺带打消一些客户对于采用 Rails 的顾虑。
Rails 的起源
Rails 全称为 Ruby on Rails, 是基于 Ruby 编程语言 ( 一种通用的动态编程语言 ) 的 Web 全栈开发框架。可以类比于 j2ee( 基于 java ), 类比 Symfony( 基于 php ), 类比 Django ( 基于 Python ).
Rails 起源只是一次无心的尝试，DHH( Rails 创始人 ) 在开发一个任务管理系统 ( basecamp ) 的时候，感觉 php 写网站太磋了 ( 写过 Rails 的话，你懂的 ), 就在 2003 年时候随带开发了 Rails.
之后，05 年 12 月 Rails 1.0 发布后，成为年度最佳 web 框架。
06 年，由于 Rails 的大获成功，Ruby 从一个默默无闻的语言，成长为在 TIOBE 统计用户使用量排名第十的语言。
之后，中国国内开始后知后觉，第一批创业者像 ITeye 的 robbin 开始使用 Ruby on Rails 作为自己的核心技术竞争优势。
这几年，Ruby 越来越成熟，社区也越来越强大，Rails 在经历了 07-08 年的小低峰后，在 09 年之后到 2015 年的今日，又开始大发光彩。
越来越多的创业公司采用了 Rails
在国外，一大批的创业公司采用 Rails 作为核心技术栈。
广为人知的：
-
Twitter ( 推特：https://twitter.com )
Twitter 从 06 年起便开始将其核心构建在 Rails 之上，之后发展超过 5 年，在 11 年才逐步将其搜索业务与消息队列从 Ruby 分别切换到 Java 与 Scala 上。
随后 12 年之后，技术栈开始慢慢地多元化，并开源了前端框架 Bootstrap( 没错，就是大名鼎鼎的它 )
-
Github ( 找程序员哪里去，Github 等着你：https://github.com )
Github 是程序员事实的社交圈子，它从 09 年开始起家，一直构建于 Rails 技术栈之上。经历过防火长城的恶意攻击，却仍然坚挺。详见：乌云分析
只要有良好的横向扩展能力，Rails 的伸缩性也十分给力。
-
Kickstarter( https://kickstarter.com )
Kickstarter 是全球最著名的众筹平台，09 年创建，目前每天的访问量十分巨大，其核心构建于 Rails.
只是找一些知名的案例，大家肯定不满意，别的平台与框架下也有不少案例，对吧。但接下来就有意思了，越来越多的创业团队开始在使用 Rails.
比如最近的
-
producthunt ( 一个发现新产品的平台，国内有很多赝品了：http://www.producthunt.com/ )
基于 Rails 构建，据说，只花了几天就把原型做好了。
-
hired ( 程序员拍卖网，国内已有类似产品：https://hired.com/ )
基于 Rails 构建。
-
dribbble ( 设计师社交平台：https://dribbble.com )
已经是全球设计师社交圈子事实的标准，基于 Rails 构建。
国内的一些作品：
-
Tower ( 一个项目协作工具：https://tower.im )
完全基于 Rails 构建。
-
36kr ( 创业媒体：http://36kr.com )
基于 Rails 构建。
-
Knewone ( 非常有势头的科技与设计产品社区：https://knewone.com )
完全基于 Rails 构建。
-
100offer ( 另一个程序员拍卖网，用户体验很出色：http://100offer.com )
完全基于 Rails 构建。
为什么创业公司会优先选择 Rails 作为核心技术栈
作为创业公司的创始人，你不必：
- 立刻开始做 APP
- 立刻考虑性能瓶颈
- 立刻考虑大量招人
而创业更容易成功的奥妙与核心在于，以最快的速度打造产品并试水市场
这时，选择 Rails 往往是最佳的：
-
快速迭代的特性
如果说 Rails 的开发效率在所有框架中排名是第二，那么我相信没有框架敢轻易说自己是第一。
无论是 Rails 的 15 分钟开发博客系统中提到的脚手架，还是 CRUD 与 RESTful 整合的天衣无缝，再加上惯例配置，能都让 Rails 的开发效率得到极大的提高。
其杀手级特性：
- 惯例配置，这个特性可以让你的代码写到最少
- 全栈型框架，包含了 web 最佳实践，本来各种前端，后端，运维一堆人的工作，现在一个人都可以非常优雅地完成，例如百度年薪大几十万的前端工程师分享了内部的工作流后，发现本质上就是 Rails 的布署原理：大公司前端都在做什么？
- 数据库迁移，有了它，快速迭代功能是非常非常简单
- 生态，类似于 app store, 一个俱复杂的登录注册功能，在 Rails 中都是 5 行代码的事。
-
快速市场试水与响应能力
Rails 生态的特点就是如何更少更快地写出高可用的代码。一般来说，代码越少，对业务响应能力越强。
simple_formslimscsscoffeescript
类似这样简化业务代码的 gem 非常多，难怪在前几年，就有大神呼吁：超过 3000 行代码的 Rails 就应该拆分了。
除了代码的优化外，还需要极强的自动化测试才能保证我们能够自由地重构业务，调整市场方向，而不致于出现产品 bug 层出不穷的问题。
guardrspecjasminecapybaraselenium-webdriver
这种全自动触发的测试系统在我印象中首创于 Rails, 目前很多框架已经学走了它。但没关系，Rails 仍然是目前生态最为强大的一个。
如果你将自动测试做好，快速迭代能力将是十分可怕的。
-
最拥抱 web 最新标准的框架
永远不担心技术栈过时，这是 Rails 的理想，也是 web 开发者的最终理想。
Rails 的 RESTful 实现，是最接近标准的一个。Rails 早在几年就拥抱 coffeescript, 而 Javascript 最新标准 ECMA6 基本与 coffeescript 类似。
Rails 4 开始直接对 mobile 提供支持。
Rails 5 对 API server 提供直接支持。
快速迭代，市场响应，以及对于移动互联网的支持，都是创业公司核心优势。难怪了很多拥有 Rails 技能的人才一定会选择 Rails 作为公司的核心技术栈，就是快。
如果你有 Rails 方面的人才，不选择 Rails 技术栈岂不浪费？
国内的现状与风险提示
国内的 IT 市场往往落后于国际 2 年之久，Rails 方面的人才十分紧缺。选择 Rails 意味着：
- 招人风险
Rails 招人唯一靠谱的圈子就是 RubyChina, 圈子对于招聘贴有着严格的要求，如果你想招到优秀的人才，不仅要有好的待遇与福利，还需要你的真诚与耐心。
但选择 Rails 的人才会有个极大的优点，是为了快乐而选择的 Rails, 他们一般也不仅仅只会一种技能，他们会更积极去学习，成长与生活。
如果一个高级 Rails 工程师可以顶住两个人的工作量，你是愿意给两倍工资给他，还是招两个新手呢？
我会选择前者。
- 性能风险
Rails 会有性能风险，这是真的，因为 Rails 与 Ruby 一样，设计理念是面向程序员的，而不是机器。所以它们性能方面都不比其他语言好，比如 C, C++, Golang, Java.
但从创业公司的经历看，这个问题现在可以忽略了。其原因有二：
1) 初期，用户才是王道，无关并发性能. 2) 性能往往从 IO 瓶颈开始，而不是语言性能。
总结
我不算是对各种语言与框架都十分熟悉的人，但都是有接触的人，对于 Rails 的优点与缺点，我私以为是十分的中肯，我看好 Rails 在创业公司中的应用，也希望更多的创业公司能够意识到：
选择一个合适的技术栈，产品将是事半功倍的。
这才是公司除了商业模式外成功的核心秘密。
在 web 界，Rails 是创业公司更优的选择。
还是来咱大 ruby-china 看这篇帖子，舒心，，，这篇文章在 v2ex 上发了，，，好多反对意见，，，，竟然还有人说因为 ruby 效率低不适合创业，，，，太逗了。。。
Rails 的成功案例不太多呀。。。大 Django 成功案例：
- Quora
- Disqus
- Onion
- Hulu
- The Boston Globe
- NYTimes
- Telegraph.co.uk
- Bitbucket
- SourceForge
- edX
其实 Rails 就适合快速 Startup，创业公司当然喜欢。 就是不好招人，对综合能力和英语要求高。 三年经验的 Rubyist 就可以做 Co-Founder 了，哪个公司敢培养？
#17 楼 @rei 恩。我发现规律了。报业用 django 的特别多。
还有一些 django 写的网站：
- Rdio
- 部分 mozilla.com 页面
- guardian.co.uk
- Mahalo
- Globo.com
- Washington Post
- LA Times
- curse.com
- rasp.yandex.ru
- Pownce(已挂)
来源 http://stackoverflow.com/questions/886221/does-django-scale
码农周边用 rails 的特别多
#15 楼 @est hulu 不是 Rails 成功案例么，怎么叛变啦？http://www.railshosting.org/the-top-10-sites-built-with-ruby-on-rails
For example, RoR was too slow for HULU so they ended up re-coding lots of stuff in C.
補充一個 Why Stripe 選擇使用 Ruby:
http://www.quora.com/Why-did-Stripe-choose-to-use-Ruby-for-its-backend-language
#22 楼 @juanito 但是居然用的是 Sinatra http://www.quora.com/Does-Stripe-use-Rails
#25 楼 @jimrokliu 性能问题不在 ruby 而是在 rails. rails 为了提供最佳实践用了许多 middleware. 不过等增长到需要面对这些性能坑的时候，多半公司已经成长到相当大的规模了。这时候无论是迁移到其他更轻的 ruby 框架还是迁移到其他语言，都已经有能力应付了。
#28 楼 @jimrokliu 16G&i7&SSD MBP 开发慢成狗，说夸张点，启动一次 rails 和我电脑开机时间差不多，性能早晚会上去是多晚？
Ruby 性能没大家说的那么慢，满足绝大多数场景一点问题没有。而性能的问题会随着 Ruby 的不断改进优化而提升上去的，相反 Ruby 社区的那些优点是其他语言永远无法达到的，因为他们没有 Ruby 这种特别的社区文化。
#27 楼 @iBcker #28 楼 @jimrokliu 有过一次迁往 sinatra, 当时 json api 的负载加重，从 controller 里分离出来. 操作起来要说能轻松迁移确实是不可能做到，尤其是很多 gem 建立在 rails 的基础之上，为了这些东西能继续工作写了很多奇奇怪怪的 helper. 有些 gem 干脆就换了。前后用了大概两周。其实现在想想当初因为拆分 api 的契机而去把框架换掉也不是很值得，当时并没遇到性能瓶颈. 测试/文档这部分东西确实很重要, 最早的时候开发为了快轻视了很多这个，后来发现迭代的时候越来越慢。现在不敢再这么不管了..
#34 楼 @jimrokliu ruby 的速度可以忍受，但是 rails 的速度无法忍受，启动一个 rails s 得 7、8 秒，部署一次得 1 分钟，对一边刷浏览器一边改程序的来说太虐心了。
我觉得用 ruby mine debug 代码速度太慢了，要等 5 分钟，还是 production 模式 真的无法忍受，另外 rails 的性能低是个重要问题，啥时候能解决啊 我觉得开发效率并不一定高，也许我是个新手
#40 楼 @goody9807 试试 development 模式里在需要调试的地方插 byebug 或者 binding.pry. 抛开 IDE 这个东西吧
+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers | 7908 | 6380 | 121 | 745 | 6 | 6 |
| Helpers | 1380 | 1199 | 0 | 136 | 0 | 6 |
| Models | 7231 | 5465 | 68 | 567 | 8 | 7 |
| Mailers | 196 | 155 | 5 | 18 | 3 | 6 |
| Javascripts | 5781 | 4491 | 33 | 749 | 22 | 3 |
| Libraries | 1435 | 1117 | 21 | 98 | 4 | 9 |
| Feature specs | 145 | 120 | 0 | 1 | 0 | 118 |
| Model specs | 480 | 390 | 0 | 0 | 0 | 0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 24556 | 19317 | 248 | 2314 | 9 | 6 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 18807 Test LOC: 510 Code to Test Ratio: 1:0.0
包含电商、SNS、API、CMS 四套大模块，也有一些遗留的孤立代码没清理，大概能删掉 2k 左右
