最近在 HN 上有一篇很火的文章，有兴趣的可以去看看。原文链接：Is Rails still relevant in 2018 ?
题记：最近因为组织Ruby Summit China 2018 大会的缘故，接触了一些之前一直在用 Rails 的公司的技术负责人（或 Leader，程序员），有几个比较大的公司或者说“我们已经转其他语言了”，或者说“我们正在转向其他语言”，然后我想结合我自己的实际经验，谈谈公司使用 Rails 的一些感受。
用或者不用 Rails，上面的那篇文章应该分析的非常详细，面面俱到了。
但是我想从经济的角度谈谈一些我的感受。
Rails 网页开发的生态经过很多年的发展，非常成熟
Rails 自从第一版发布到如今已经走过了快 14 个年头了，围绕着 Rails Web 开发有着许多不错的 Gem，这些 Gem 包让我们可以很快的搭建起来产品的原型。因为对其他语言的框架，了解比较少，至少在我浅尝辄止的过程中，我感觉到很少其他语言在 Web 开发库方面能和 Rails 的生态相比。
这点对公司来说，带来的经济价值就是减少了公司重新造轮子所带来的人力和资源上的消耗。
惯例优于配置，降低了优秀程序员的门槛
理论上来说，惯例优于配置，并不会真正降低了优秀程序员的门槛。知之而行和不知而行的差别是显而易见的。
但是，在大多数的情况下，只要我们遵循社区的最佳实践，相对来说比较容易写出较高质量的代码。
从经济的角度来说，我们有可能让初级的程序员，写出中级程序员以及高级程序员才能写出的代码。
原因显而易见，这些最佳实践，都是源于顶级程序员多年的经验总结。
前后端分离，无形中提高了对前端程序员的要求
我们在公司实践过一段时间前后端分离，后来还是放弃了。
放弃的原因很简单，因为我们的前端工程师，并不能够流畅的使用现代前端构建的工具。这些工具带来的效益比如自动 assets 压缩，缓存等等都对前端程序员有较高的要求。
现在一个能熟练掌握前端构建工具，如 Webpack 等，掌握 React/Vue 全生态的程序员，一定是一个相对高级的前端工程师了。
Rails 通过 Sprockets 实现了前端资源的自动压缩，使用 Turbolinks 优化了前端的加载速度，注意，这些几乎都是 Rails 自动完成的。
erb 模板文件，俄罗斯套娃式的缓存，对于有一定学习能力的前端工程师来说，掌握起来比 Redux 不知道要容易多少倍。
前后端分离，如果实施不当，很容易变成东施效颦。
乖乖的待在 Rails 的前端生态中，用户 Rails 的前端工具，依然可以满足现今大部分公司的业务需求。
前后端分离，与其说是公司的需要，可能更大程度上是程序员对于技术栈追求的需要。
以上三点，是我目前感受最深的几点，欢迎拍砖。
离开 Rails 的人通常不会否认 Rails 的成熟，真正的动因大多都是因为 Rails（或者说 Ruby）的短板在可见的未来里没有提升的可能（或者可能性微弱，又或者是即使有所改善也就聊胜于无）。
惯例优于配置并不能降低成为“优秀程序员”的门槛，它只能拉高“普通程序员”的底线。对于真正的优秀程序员来说，惯例优于配置是一种“品德”，然而即便身处于“没有惯例”或者“惯例崩坏”的场合，优秀的程序员依然优秀，而普通的程序员则会原形毕露，坠入深渊。如果一个普通的程序员可以进化成优秀的程序员，那么即便他不知道什么叫“惯例优于配置”也不会阻碍他的进化的。
前后端分离是一种工程实践，而不是一种意识形态；不能理解到这一点的，对它的评价最终也会归于意识形态批判的范畴，变得没有价值可言。
总结：你认为对你合适的，且在今天也确实适合你的，那就是你的选择；至于你怎么看自己的明天，那是你的自由。
1.确实一些新语言的出现，对 Rails 造成了很大的冲击。但是软件开发是一个系统工程，应该从全局去衡量。没有人真的统计过开发相应的系统，整个公司的开销，我想一旦去统计，就会发现事实并不像想象那样。
2.惯例优于配置确实并不能降低优秀程序员的门槛，但是在实际上有助于初级程序员提高代码的质量。反过来，也会促进程序员的成长。
3.我这篇主要是从经济的角度去谈的，过高的开发门槛，必然会导致公司人力成本的提高。同样的效果，如果能让水平一般的人来实现，何乐而不为？主要是高级别的程序员非常难招，说百里挑一，一点也不过分。
主要还是语言的弱点。比如说 Rust 的三条安全、性能、并发。Ruby 只是在性能上改进，安全上弥补字符串改成不可改，也在探索类型系统。但是要与新语言全面竞争肯定是劣势。
Rust 的面向对象感觉比较折衷和可行，数据默认为只读，也没有继承，这样就杜绝了数据耦合。
老外博客分享的是 Elixir 可以省掉三分之一的烦恼，另外有公司定了目标五年之内 Elixir 进入前十名语言。而目前 Rust 排名快速上升到 31 位。
经济考虑是可以理解和必要的，我上次在网上遇到 dry 的负责人，他说目前还是 Ruby 为主，因为有前期投资，不排除逐步引入 Elxiir。
至于说人员，为什么不用质量换数量呢？当然人难找是个事实。
那些技术负责人应该就是简单的技术水平不行，眼界不足，看到别的东西玩出花了心里也就痒痒了。
其实说到底 rails 以及 ruby 的理念不知道要精髓多少
- 像 rails-ujs，turbolinks，stimulus 这三个的组合体不比 react + redux 开发效率不知道高了多少倍，甚至有些想玩 hybrid 的那些人 turbolinks-* 也能很好的支持。
- 优雅的数据库查询方式，简单的处理 n+1 问题，我到现在还没能看到任何语言的 web 开发框架能像 rails 这样方便；以及 callback 简直不要太灵活的处理各种奇怪的逻辑，还不带影响上下文。
- 还有就是 action job，action cable，action storage 这种工具巨额提升开发效率，完全一条龙服务。
- 唯一的确点也就语言本身的运行效率低一点，但是 fragment cache 已经解决了页面级别的效率问题，不行还能直接手写 cache 也不错。
posee
回复
是啊。
知名度其实很重要，大家认为学这个以后能够进大公司、赚大钱，才会有人学。多数人都是这样的，靠少数爱好者社区只能勉强维持，很难继续壮大。然后这种情况下能入坑的大多数是一些 geek，干了一段时间他觉得技术上没有新鲜感了，于是就会跑去折腾别的东西。大多数公司需要的是能花时间把公司的业务梳理得更清楚的码农，技术能力够用就可以了，太 geek 有些时候弊大于利。招几个新手来培养一下吧，也不简单。元编程、惯例优于配置等等，写起来是比较爽，但是维护起来就不是那么回事了。本来依靠静态分析或者在编译时就可以发现的问题，现在要依靠 CI，或者纯脑力去发现。一些静态语言，只要学会基本语法，自己去跟代码，最后总能找到问题点。普通的 Rails 新手，要是调用接口的结果和自己的认识不一致，就很难了，要成为即战力恐怕至少得三个月。种种原因都造成了 Rails 招工难的问题。
带来受不了委屈的，干不了脏活的，矫情的一逼的员工。
PHP 才是公司的最爱，连 PHP 这么丑陋的语言都能接受的程序员，什么活接受不了？
Rails 通过 Sprockets 实现了前端资源的自动压缩，使用 Turbolinks 优化了前端的加载速度，注意，这些几乎都是 Rails 自动完成的。
最主要的问题是，类似的方案，npm 那边可以拿出来 100 个。。。社区太兴旺了。。。小公司里挑一个就可以上手，大公司还可以反复造轮子刷 KPI。。。。。所以部门编制越来越大出路越来越广。。。。
rails 自身太优秀把自己的路走死了。。
说到底还是大前端对 Rails 的冲击，写接口的就好好写接口，前端构建基本的常识难道也成高级工程师了，组件化开发谁用谁知道，路由视图无需后端干预，把数据接口准备好就 OK，Rails 的确设计理念优秀，导致很多其它语言也都有相应的借鉴的框架，但是越来越多的人已经不喜欢全栈开发框架了，而是需要一个纯接口的开发框架而已，当然还有一部分原因是老生常谈的性能问题。
hxh1246996371
回复
我觉得 rails 性能还可以呀。又不是每个程序都会存在很高的并发问题。。做 web 有页面缓存，还有 controller 缓存，性能不是根本问题，
posee
回复
不是很了解 nodejs，个人觉得 Rails 的衰弱并不是因为其他更优秀竞品的出现，而是和它自身的特点以及时代发展有关。不过话说回来，要是现在让我起手一个 web 项目，第一选择还是 Rails，最大的原因当然是因为——我只会这个。
posee
回复
Rails 刚出来的时候，可以说一家独大，独特的 MVC 框架，在哪个没有框架的年代无异于一颗耀眼的明星
如今各种框架纷呈，其他语言的程序员也有了更多的选择
所以从这种角度上来说，Rails 是衰弱了，不过 Rails 还是 Rails，只是大家选择更多而已
posee
回复
对于小团队来说建议使用 asset pipeline，因为对前端要求不高 对于不差钱，不差人才的，想怎么样就怎么样吧 技术只是个工具，需要各方面来权衡
入行十多年，接触 Ruby/Rails 近十年，接触 Elixir 两三年，从带领小团队到带领 20 多人的团队后…… 小小的领悟是，对于大部分 CRUD 类的项目，比较笼统的个人看法：
当一个团队中大部分都是经验老道的成员的话，我还是会选择 Rails（或是至少选择 Ruby）。
当一个团队中大部分是入行不久的新人时，我会选择 Elixir 或其他 FP。
我个人接触过的不论是开源项目还是闭源项目，采用 Rails 的代码质量普遍较差（有些甚至是不堪入目）。:(
