Ruby 评论 Why I wouldn’ t use rails for a new company
Scribd 在全球所有使用 Rails 网站中，做到了流量排行第三，最近该网站的创始人 Jared Friedman 写了一篇文章，告诫所有初创公司为什么他不会在选择 Rails:
Why I wouldn’t use rails for a new company
作为国内最早的一批 Ruby 程序员，RubyChina 社区的管理员，目前仍然靠写 Ruby/Rails 代码混饭吃的人，当我看到这篇文章，内心其实是拒绝的。但是静下来想了想，文章中的观点并非不可接受，这取决于你选取的角度。对方站在自己的角度表达了观点，想法，看这个技术世界的样子，那么如果不能尝试理解对方思考的角度，就自燃无法接受对方的观点了。
我试着不带有价值判断的眼光，去尝试理解 Jared 的角度，然后在作出自己对事实的判断。Scribe 创建于 2006 年，基于 Rails 0.7 创建。2006 年的 Rails 远远没有现在的成熟度，在当时选择 Rails 意味着：
- 这不是一个安全的选择，而是一种赌博
- 团队是否能跟随框架和技术的脚步共同成长
- 会不会持续有人会转而使用这项技术，于是将来能招聘到足够的工程师
Jared 认为这三点中，第三点是最重要，之后的结果是：
- Rails 一度成为了硅谷湾区初创公司的 Default Web Application Stack
- Scribd 的技术团队伴随着 Rails 的发展，已经成长为流量第三大的 Rails 网站
- 大批有天赋的 Java，PHP，ASP.NET 程序员在早期看到了 Rails 的趋势，因为 Scribd 作为早期提供 Rails 工作机会的公司，在招聘中处于优势，于是持续招募到了不少优秀的人
Jared 在 2006 年选择站在技术的风口浪尖，作了个赌博，于是才有今天这样一个多赢的结果。所以作者角度是从赌博出发，建议初创的技术型公司把眼光放长远，不要去选择今天看起来很安全的技术，应该选择未来三年可能会成长起来，且会有大量有天赋的开发者未来三年内会选择并切换过去的技术，在这个过程中，你要保证团队能够跟随技术发展同步成长即可。
我觉得这个观点挺开脑洞的，不能说没有道理，但是我所了解的大多数技术公司通常不会从这个角度去做决策，可能也不是没有，比如七牛云存储的老大许式伟一直就是国内最主要的 Golang 布道者之一，Strikingly 的 CTO 郭达峰，一直活跃在国内推广 React.JS 的一线。这就要看你信什么了，不管你信奉乔帮主，还是其它什么人，能做成一家公司从来都不是那么简单的事，所以有信念很重要，还是得选择信奉一些什么。
作者的建议
其实并没有明确的建议。Jared 提出了三个 Ruby／Rails 的问题：1) 语言的运行效率很慢 2) 框架发展到了瓶颈期，优势不再 3) 对开发者的吸引力下降。然后通过 Google Trends 展示出一些新语言，以及工作职位的趋势，
从当前的数据和趋势看 Node.JS 目前正处于领导位置，可是选择 Node.JS 或者 Golang 或者其他新兴的语言框架，就如同 2006 年的时候选择 Ruby／Rails 么？这里提到的每一个，其实都不是。
作为一个 Rubyist，我怎么看文中提到的问题
关于 Ruby/Rails 的性能问题
Jared 在文章中说的其实都是对的，这些都是事实，必须要承认。Ruby is slow，Jared 知道，我知道，你知道，所有的 Rubyist 都知道，问题是性能真的那么重要么？
抛开具体的场景谈问题，都是耍流氓！如果你要处理的是 CPU Intensive 的问题，那么你应该用 C 语言（或者 C＋＋）。如果你面对的问题是 I/O Intensive 的话，那么语言的性能并不是问题的关键，编程范式和架构才是。在 Web 应用的场景下，大家其实应该关心的问题是如何把 HTTP 请求处理的平均时间优化到 200ms 以内，如果你对 Rails 处理 HTTP 请求的过程非常熟悉的话，你还会仅仅纠结于 Ruby 语言的性能么？如果你已经充分优化了架构，缓存，数据库访问后，仍然对 Ruby 的性能感到沮丧的话，我真的要恭喜你，你已经成功了！此时你的项目应该已经 C 轮了吧，赶紧用钱去砸，不要纠结。
Scribd 在 2006 年用的 Ruby 比现在的版本要慢得多，那个时候的 Scribd 看重 Ruby／Rails 的到底是什么？我猜答案应该是 Just Enough -- 在平衡性能的同时，给了你极佳的开发效率，完整的生态系统，帮助你实现各种可能性，以期应对快速的发展和变化。这本质是一种 Tradeoff，是一种折衷，优先确保开发层面上的效率，而后才是性能。那么用性能换开发效率是不是一个最优决策？答案是看场景，在场景合适的情况下，这就是最佳策略。当时间推移，场景变迁后，是否还应该继续坚持这个策略，答案当然是 NO！
当业务发展需时，其他语言或者框架更加符合场景的话，Go for it！
关于 Rails 框架发展到了瓶颈期，优势不再
当年 Rails 升级到 3.0 的时候，我们称其为 The Great Rails Refactor ，这一次升级的改变幅度巨大，以至于 Rails 3.0 发布后很久，大量的项目都无法及时跟进。在这之后的 Rails 每一个版本更新依然保持废弃掉一些老旧功能并同时带来新的东西，但是向后兼容问题已经大幅改善了：
- 3.1 (August 2011) - Asset Pipeline, jQuery, CoffeeScript, Sass, reversible migrations,
- 3.2 (January 2012) - faster development mode, ARel explain queries
- 4.0 (June 2013) - Turbolinks, Russian Doll Caching
- 4.1 (April 2014) - Spring, Action Mailer previews, enums
- 4.2 (December 2014) - Active Job, asynchronous email delivery, web console
- 5.0 (No Timeline) - Turbolinks 3, Rails API, ActionCable
高速发展的事物其本身都承载着一种叫做 growing pains 的东西，我们姑且称之为成长期阵痛。这是一个好东西，如果一个事物的这种 pains 在削减，那么我们会认为它变得成熟。受到这种成长期阵痛影响最典型的可能是 Github，直到 2014 年底，Rails 3 发布四年后，Github 终于把项目代码从 2.3 升级到了 4.1，整个升级过程耗时 6 个月。
有一种观点认为像 Gihtub，Twitter，或者 Scribd 等都不是 Rails 应用的典型项目，这些项目体量巨大，为了满足自身需要，对 Rails 本身做了大量的扩展与二次开发，导致因为无法跟随一些 Rails 开发的最佳实践，于是每次当考虑升级的时候，发现升级所耗费的成本远远高于新版本所带来的好处。我认同这个观点，这本质仍然是一个 Tradeoff，是一种折衷。选择始终遵循 Rails 的一整套最佳实践，会给你的项目带了较好的向后兼容性，降低升级的成本。为了解决具体场景下的问题作一些特化处理，从而增加升级的成本。Rails 给出的建议是选择前者。
选择对的框架去解决对的问题就不会错。Rails 仍然是流行的 Web 开发框架之一，作为一个现象级的框架，被其他框架争相模仿，这些框架不仅仅克隆了 Rails 的功能，还克隆了 Rails 框架背后的思想，经过经年累月的发展，这些框架相对于 Rails 的差距在缩小，因为后发优势的原因，在 API 向后兼容方面做得比 Rails 更出色。
如果另外一种框架比 Rails 更稳定，优秀，且更符合你的需求的话，Go for it！
对开发者的吸引力下降
Ruby/Rails 一度能成为硅谷湾区初创公司的 Default Web Application Stack 其实并不仅仅是因为技术本身，语言框架背后的设计思想和哲学给开发者带来的影响其实更大。
Ruby somehow enables programmers in a special kind of way that is so hard to explain to the ‘unwashed masses’.
体验过 Rails 开发的人，特别是从其他语言转过来的开发者，比如 Java，ASP.NET，甚至 Python 开发者，在学习 Ruby/Rails 的第一感受往往是能感受到某种快乐。感到快乐非常重要，这种快乐来自语法层面赋予开发者最大限度的自由和灵活，以及 Rails 框架深层的 DNA 中包含的对代码品质优雅的追求，以及想方设法集成大量的最佳实践，让开发者在使用框架过程中感受到方便快捷，和无微不至的实用主义。于是很多开发者尝试过 Ruby，写过 Rails 之后发现再也回不去了。
有人说 Ruby／Rails 自带鸡汤，效果肯定不会长久，兴趣和偏好必须能经受市场考验。话没错，那就不撒鸡汤，回归现实。对于每一个开发者来说，拥有，维持自己的核心竞争力很重要，先掌握一技之长，然后最大限度的发展自己的技能树之外，另外一件重要的事情就是能有效的把握市场需求，Rails 虽然已经不是当下最热门的技术，但是其市场需求依然非常旺盛，掌握良好的 Ruby 编程经验和技巧依然可以确保你衣食无忧。接受并认可 Ruby/Rails 背后的哲学思想的价值，并不妨碍你学习新的东西，所以为了维持自己的核心价值，应该不断发掘并学习你感兴趣的新东西。
当另外一种语言更加能激发你的兴趣，并让你相信值得为之投入的话，Go for it!
Ruby 语言的未来
其实 Ruby 是一门非常保守的语言，近些年 Ruby 最大的变化来自于从 1.8 升级到 1.9 这一版升级，包括重写了底层虚拟机，系统原生线程支持，新的字符 Coding 处理，更好的 GC，以及一些向后不兼容的语法变化等等，这一步 Ruby 用了五年，相对于 Perl 5 到 Perl 6 用了 15 年，Python 2.7 到 Python 3.x 目前看来仍然遥遥无期。
1.9 之后的节奏是小步快速迭代，并尽可能向后兼容，尽可能不引入任何破坏性的变化，所以整个社区都推荐直接用最新的 Ruby 稳定版，不纠结。目测 Ruby 未来仍然会坚持把满足语法设计作为第一优先级，其次才是性能。从过往的经验看，这个策略是 Ruby 成功的要素，所以 Matz 才会一直坚持 20 年不动摇。
现在市场上很难买到单核 CPU，连手机都进入了 8 核时代，人们比以往任何时候都更加关心 Ruby 的 Concurrency 能力。回到 2012 年 Ruby 2.0 正式发布的时候，大家欢欣雀跃因为 Ruby 抛弃了多年的 Green Thread，取而代之的是直接使用操作系统原生线程，似乎原生多线程编程的威力终于要被释放了，当时 Matz 被问到何时能去掉 GIL 时，Matz 很腼腆的回答 I don't consider myself as the threading guy。就是否移除 GIL 这个问题到现在已经三年过去了，Ruby 的核心团队已经明确的表示不会移除，于是人们批评核心团队在 GIL 问题上太过保守，可是核心团队决定保留 GIL 其实是为了最大限度的保护程序员，保护程序代码的安全。
Ruby 会继续打磨并引入新的语法，性能会持续得到优化，但是在 Concurrency 这个方向上何去何从呢？Matz 最新的公开演讲提到，会引入更多的抽象并发模型，可能会尝试性的把 Actor model / Event-driven loop 引入到语言核心中，也可能会引入 Ownership model 以确保并发中的共享内存安全问题，Matz 的新语言 Stream 则在尝试通过管道的方式实现并发，会支持更多的 immutable 类型的对象，但是这一切都仍然处于试验中，核心团队不承诺任何东西，我们只能拭目以待。
如果你为了追求更好的 Concurrency 编程选择其他语言，Go for it!
Jared Friedman 的文章今天好红。
成熟的东西（像现在的 Rails），虽然汇聚了很多最佳实践，稳定可靠又能平滑演进，却再也找不到眼前一亮的特性了（实验特性引入成熟框架会破坏稳定性），所以，追求 Different 的人们开始唱衰它是一定的。
上一个类似的案例是 SQL => NoSQL，然而多年以后 
以前个公司也换到 Go，用 Rails 时每月要给 AWS 交 8000 多美金！可惜我只会写 Ruby 只好换公司。
看公司做什么也很重要。反正合适你 (公司) 的就好。
语言太慢绝对是瓶颈。Rails 的杀手锏，开发效率被追的优势剩下的不多，运行效率却依然很不怎么样。
拿 06 年和 15 年的 java web 开发对比，那时候 rails 的开发效率可能是 java 框架的 10 倍，但 java 的运行速度也可以是 ruby 的 10 倍。只是大部分网站也确实用不到这种性能优势。而 9 年过去后，java 的 web 框架经过多年努力和投入，rails 的开发效率尽管还可以甩 spring 一大截，但肯定没有一倍那么多了。然而 ruby 的运算效率差距依然在 5 倍以上。
Why is ruby so slow? Some people will point to language design characteristics, which are part of the story, but I think the deeper reason is that ruby does not have a serious corporate sponsor.
#7 楼 @rubyu2 Matz 现在受雇于 Heroku（Salesforce 旗下），领导 Matz Team，这个团队用于专心开发推广 Ruby。所以 Ruby 有一个严肃的企业赞助商 Salesforce。
https://www.new-bamboo.co.uk/blog/2011/07/12/translation-of-matz-q-a-article-after-joining-heroku/
Mr Matsumoto (Matz going forward): When I last met Mr Marc Benioff (CEO of Salesforce.com) he asked me how he could support the development of Ruby.
So I told him that I want to improve the situation which the majority of Ruby Core developers face, that they are either doing their work in their own spare time or they worry about their job security.
He said he could provide us some support and that’s why I decided to join Salesforce.com through Heroku (Note: Several members of Ruby Core are currently under negotiation to join Heroku).
https://ruby-china.org/topics/27492
Points 1 and 2 are unarguably correct. Rails isn't hot any more and is not evolving at the pace it used to be. But this isn't a bad thing. It's a sign that Rails has matured, it's now an adult framework and not the spotty teenager who grows taller by an inch every month.
http://www.bootstrap.me.uk/bootstrapped-blog/why-you-should-use-rails-for-your-new-company
文章后面的讨论更有意思些。
Paweł Nowak9
I think you are agreeing with Jared even if you don't know it. The main point in Jared's blog post is that being a hotness, being the first, was everything that Rails had going for it. The performance issues always existed with Ruby, the architectural issues in Rails have been extensively discussed for years at this point. The only thing that kept Rails ahead of everyone else was the fact there was nothing quite like it, it was literally years ahead of everything else. However, times are changing. There are many alternatives out there as good as Rails, others innovating more than Rails, and many of them in better VMs and runtimes than Ruby (disclaimer: I don't consider Node.JS better than Ruby). Seriously, in the last 10 years, things changed dramatically, from the number of CPUs to web development itself. Ruby is horribly delayed in the concurrency game. Rails is playing catch up with Action Cable, APIs, ES6 and others when compared to alternatives in Clojure, Go and Elixir, like Phoenix. So when you agree Rails is becoming stable, you are agreeing that Rails lost its main competitive advantage. At this point, you should be considering and evaluating other alternatives. It doesn't mean you'll necessarily replace Rails, but for your own sake, you should be looking at them.
Fred Heath
Hi Pawel. Yes, there are many alternatives out there as good as Rails, or may be even better. But Jared's first argument is that we should switch because these frameworks have more rising mind-share and will cover our needs better in 3 years time. My argument is that if you're a start-up and you worry about which tech you should be using 3 years down the line then you're either extremely confident or extremely naive and neither is a good thing. Rails is a proven start-up bootstrapper and until something comes that blows it out of the water, switching would be an un-necessary risk. Jared's second argument is that we should switch because Ruby is slow. I have hopefully shown that this is largely irrelevant. In most Rails apps I've worked on, latency is 90% of the time caused by some db transaction or some external service call, not by Ruby itself. If you need something like parallel processing of massive data sets then you wouldn't be using Rails in the first place, so I find this to be a moot point. Same with concurrency. I am very familiar with concurrency and its issues, but since I've been using Ruby I never had to worry about it because I didn't need to. For web apps I let the web/app server stress about it. For non-web apps I get by with forking processes and avoiding shared resources or using Redis or a queue. It's seriously never been an issue. For the record, I am evaluating other alternatives, namely Elixir and Phoenix. But these are a complement to Rails, not a replacement. Rails will be my default choice for building something quickly, unless there is a specific need for elixir's performance. YAGNI.
赞同 LZ, 十字螺丝钉用十字螺丝刀，一字的就用一字的。
从个人倾向来说，如果一件事 几个语言包括 Ruby 都能干，那肯定选 Ruby. 因为它趁手，用着舒服，写着快乐
Rails 就像是自行车，这个问题就像是家里是不是要买辆，有经济实力的，一开始就奔驰宝马没问题
但钱少的，还是先买个自行车好了。甚至你说自行车不能跑长途怎么办？需要的时候再买个好车呗
Rails 其实上解决了没有钱买奔驰宝马但又要近距离出行的问题
For me and my team, Ruby/Rails just works. That's enough. 喷 Ruby 过气的，根本不考虑 PHPer 的感受，人家怎么也是”世界上最好的语言“啊
#4 楼 @swachian "语言太慢绝对是瓶颈" 非常赞同。
正常情况下在 8 时 -22 时配置合理的硬件系统可以运行良好，但在某些情景下比如秒杀、比如群发或推送后的 10 分钟内流量洪峰来的时候，”语言的性能“就成为巨大的瓶颈了。由于语言的限制即使做了极致的优化，可能效果还是不如一个新手用性能更好的语言做实现的。
硬件可能很便宜，云服务器扩展也很方便，对于大公司来说可能有无数的解决方案（比如 kaminari 作者所在公司那种动态启停几百个节点的做法），但对于很多小公司来说可能并不便宜，实现也并不简单；对于很多客户来说并不愿意为了你的实现多投入那么多的资源。
最开始看到 15 分钟写 Weblog 实现的时候惊艳我的是 scaffold(代码生成）以及 ActiveRecord，后来是语言的特性和活跃的社区（丰富的插件）。现在我仍然喜爱，我们有的产品也还 完全 在用 Ruby/Rails，也更明白了其实无论什么语言和框架，最终以合适的代价创造出有价值的 东西 才是最重要的。
#21 楼 @billy 你说对了，看我的 Blog 文章标题：http://lvguoning.com/2015/09/27/php-is-the-best-programing-language/
如果你为了追求更好的 Concurrency 编程选择其他语言……快来试试 Elixir……
https://soundcloud.com/elixirfountain/elixir-fountain-2015-09-25-dave-thomas
- 脱离了场景，直接谈语言的性能，基本就是耍流氓了。在某些场景下，C 都不是最佳选择，更别说什么 Go，Rust... 等一堆所谓的性能好的语言。
- 将某种语言用于它不合适的场景中，要么是不熟悉场景及所使用的语音，要么就真是在耍流氓了。
- 相同场景下，至少在主流的动态语言中，Ruby 的性能还可以。
- 用 Ruby / Rails 创业成功后，然后技术转型，写一篇“我为什么用 XXX 而放弃 Ruby / Rails”等类似的文章，这也是在耍流氓了。当初，如果不是 Ruby / Rails 的快速开发能力，他连写这篇文章的机会估计都没有。当初如果直接使用 XXX，大概率的被对手拍死在沙滩上。
性能是重要的，但不是最重要的，更不是全部。它只是雷达图的一项。
Scribd 这种文章基本可以忽视了。
当然，文章描述的也是客观现状。现今，对于创业公司来说，除了 Rails 之外，确实多了不少新的选择：Node.js、elixir、go、scala 等。如果时间再回到 2006 年，我就不信 Jared 还会说，我不会用 Rails 去创业，因为他没得选。
当年 Ruby 之父 Matz，通过摩尔定律看到，未来硬件成本必然很低廉，所以创造了以人为本的 Ruby，但是他没有看到的是 CPU 的发展瓶颈，没有预料到多核时代，更没有预料到互联网的飞速发展，所以性能是 Ruby 与生俱来的缺陷。所以，那些不用 Ruby 的人的理由也很简单也很唯一：性能不行。但是你用天生并发的语言做的应用就没有性能问题了吗？
今天看到一句话「你用了号称最先进、最新潮的语言，你也做不出一个 Whatsapp 这样被$190 亿收购的公司啊！」，深感认同！语言只是工具，要做一个伟大的公司，跟你用什么语言关系不大。
我们是程序员，快速掌握任何一门语言去谋生是我们的职业天赋。其他人用不用 Ruby 无所谓，没有公司用 Ruby 也无所谓，因为我们是 Rubyist，不管用其他什么语言，Ruby 这位程序员最好的朋友都一直在我们心中，影响着我们。
P.S 看完 Matz 对 Ruby3.0 的公开演讲，感觉 Ruby 的未来还是有很多可能性的。
从今年开始就再也没有碰过 Rails 了，感觉 Rails 已经老了，该退休了。十年前 REST http request/response 的模式看起来那么美，但是现在时实时应用的时代了，大家可以了解一下 meteor 的 data on the wire 的概念。
如果 https://github.com/peatio/peatio 项目中使用 pusher 实现的那部分功能，用 meteor 实现是不是会很简单呢？
#32 楼 @blackanger 视频也看过了，多线程的处理也是很难的，完全解决会是个漫长的过程。不过就语言发展来看，近几年来 Ruby 更新速度还是非常乐观的。
skandhas :plus1: 技术是为了推动产品和服务产品的；合适的场景要选择和适合的工具，我认为语言也是一个工具，使用那种语言应该基于你要做什么东西，而不是选择语言来作某个东西。
#35 楼 @lgn21st 对这个是完全赞同的，但是“实时性”的部分应该是内嵌到一个框架的最深处的，成为框架的默认的。所以，过时的不仅仅是 Rails，还有 Ajax/Pjax/turbolink 等这些所有基于非实时框架做成的实时 Hack。
世界变了，最大的一个特点是网速变了。十年前，当我们请求一个页面等个三五秒认为是正常的时代，Rails 默认的这种 Http 请求模式显然是没有问题的，因为最大的痛在于等待时间而非页面刷新。但是到了今天，web 应用应该是”无刷新为默认“的，也就是”类原生应用为默认“，道理很简单：网速上来了，用户体验要在平滑性上来拼了。Rails 从基本架构上不是为这个时代而生，所以改进也没有必要了，慢慢淡出娱乐圈才是正道。
说起”编程快乐“，这个依然是最重要的。但是用用 meteor 就会发现，Rails 输掉的同时是两个极端：易用性和强大性。
很中肯的一篇文章，给楼主点赞。
- 我 99 年开始编程，但是接触 rails 不久，却受益匪浅，并且会作为爱好一直实践下去。
- rails 吸引我的，其实是背后的 web 最佳实践的设计哲学。脱离道的层面谈术是没有意义的，何况语言都会不断的发展，喜欢就好，适合就好。
- 从哲学层面上看，世间的事没有最的（不限定范围的话），我们很多时候都是在“比较适合”中随机选择解决方案；从商业角度上来说，选择什么技术真的无所谓，能赚钱或者省钱就好。
觉得现在的技术环境真好，有这么多可选项，很幸福了哈哈；喜欢且适合，就上呗。
他说的很有道理啊。现在用 Rails 已经不能吸引 Hipster 了，当然不划算啦。
流行的东西就是这样，每过一段时间就会有一些老掉牙的东西被当作新时尚。
我赌 2016 年流行的 Web 框架采用的是 PHP 语法，在 BEAM 上运行
html css 等 为基础的 web 技术设计的时候显然没考虑平滑性。要体验好，平滑，Flash 是首选。从网速更快，体验更好来看，也应该是 Flash 最佳，那么问题来了，为何现实不是这样呢？
因为现实需要妥协，
越是新的技术，比如 golang，实际使用肯定需要比成熟技术更多的妥协。坑不仅仅是技术上的。
极端，如果追求成熟，坑少，人好招，那么 rails 显然不是首选。
新公司到底用还是不用 rails？
即，新公司如何面对：1) 语言的运行效率很慢 2) 框架发展到了瓶颈期，优势不再 3) 对开发者的吸引力下降。
新公司面对的问题是生死，如果这三点足以要命，还是不要用的好。
Jared Friedman 的 Scribd 流量是 rails 第三，我真不好理解这意味着神马，我也有点 rss 新闻订阅，但没怎么听说 JF 和 Scribd，也懒的查查，
一般牛掰的人说手里的家伙，都是往 low 里说，比如我们用小米和步枪的架构，或 php java python 都用一些。
JF 这哥们让别人也不用 rails 真是牛逼吹大了！！！
你们感受一下：
xi：小札，你们这网站打不开，还做上市，用的是神马技术？
小札：回主席，我们用 php，坊间说 php 是世界上最好的语言，不过您可别用，因为有三，
- 效率慢
- 发展卡住了
- 不是世界潮流
xi: 蛤蛤蛤蛤，好的狠，欢迎来华，来走我们社会
注意道路，原因有三
- 我们体制效率高
- 我们有世纪梦想
- 我们有七个信心
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝over＝＝继续哄娃睡觉
Ruby 已然错过了最好的发展时期，开发者社区未来只可能是缓慢下降了。
为啥会错过？因为移动互联网起来之后，服务端编程变轻了，对页面模板的要求变低，导致 Web 快速开发框架的门槛越来越低，很多其他语言 Web 框架足够用了，同时对高并发的要求一下变得很迫切。而 Ruby 近年来最大的问题就是：没有解决 Web 应用中高并发的需求。导致了从 Rails 起家的创业项目，后期不得不面临成本巨高，同时异常痛苦的系统架构和编程语言的迁移。
如果做新的项目，开发效率上，其他语言框架已然接近 Ruby，但是后期性能扩展却可以持续跟上，不会面临需要整个迁移平台的风险，那么任何理智的技术决策人员都不会再采用 Rails 开始做项目了。
我是认同原文作者的观点，这个结论挺残酷的，但是得承认它。从整个技术发展未来看，Ruby 仅适合作为程序员的第二语言，不适合作为第一编程语言了。
BTW：从谋生角度来说，第一编程语言是 Java 或者 JavaScript。客户端编程未来看，JS 大概是要一统江湖了，服务端主要还是 Java，此外 Golang 也可以看看 (PHP 是个奇葩，在此不提)。
PHP 是比较纯粹的 Web 模板语言，不是一个 full-stack 的 web 框架，使用 PHP 的项目，往往被迫在早期架构扩展的时候就引入了后端编程语言，逐渐就迁移过去了，PHP 只做模板了，所以不太存在可扩展性的问题。
Python 和 Ruby 都一样，可以做 full-stack，可以支撑相当长一段时间的架构扩展，代码逐渐积累到庞大的规模。而一旦发展到大规模应用，需要更高的可扩展性的时候，迁移还是不迁移，都会变得异常痛苦。
Python 比 Ruby 好的地方是应用领域更加广泛，Web 不行还可以干点别的，Ruby 就尴尬了，除了 homebrew，puppet，大概找不到太多其他领域广泛应用。
太捍卫一门语言，不灵活，属于大多程序员的死穴。 Swift 的出现就正实了，近期人性化语言的发展要远远高于前几年。 Go，react, swift,.... 都属于年轻的活跃，有后台的支持的语言。 走向也不定。 相比，ruby 和 rails 比较老了。活跃量也在下降。 突然间发现自己的表达能力太差了。
没必要一刀切，要么用要么不用，别忘了 Rails 中的部件是可以拿出来单独用的。例如用 ActiveRecord 开发一个 microservice 就是一种别的语言都难以望其项背的愉快体验。
这哥们刚刚创立 Scribd 的时候，连 iPhone 都没出来，mobile app 根本都没成为主流，web application 作为应用的载体地位比今天要重要一些。而 Rails 恰好是一个全栈的 web 框架，选择它当然是顺理成章的事情。
但放到今天，Scribd 或者其他的任何一个公司，开发一个应用首先都必须考虑 mobile app 的问题，也就是相对于全栈的 web application，首先需要考虑设计一个所有端都能使用的 API service，性能问题/响应速度在这个场景下相对 2006 年更重要，因为重点变成了返回轻量的 JSON 数据而不是渲染一整个页面，界面的工作是丢给客户端来做的。Rails 和 Ruby 在这个场景下并不比新生的各种工具更有优势。ES6 标准出来之后，解决了 Javascript 语言原生的一些劣势，加上各种前端框架的火爆，可以预见整个 JS 的生态环境会更加的欣欣向荣，可以比较好的应对并发问题的 Node 在这些前提下的确大有可能会得到更广泛的应用。
其实作者的分析是非常有道理的，他并没有说他回到 2006 年不会选择 Rails，而是现在他再成立一家公司不会选择 Rails。如果我对 Node, Ruby, Go 的熟悉程度差不多，而我今天需要从头起一个主要作 service 为移动端服务的 API，我也不会选择 Ruby/Rails。
北京某公司招聘 ruby 工程师 3 名，2 年以上工作经验，大专以上学历，坐标北京朝阳，年薪 15 万左右，有意者发简历至 [email protected]
Ruby on Rails 新手，看了那篇文章以及上面的一些评论。起初还是有些难受。 作为一个从零开始的 Web 开发者，直接入手 Ruby on Rails, 不敢对其他框架和语言作评论， 但是 Ruby 以及 Ruby on Rails 给了我继续编程的信心， I Love her.
