#17 楼 @Rei 我只能呵呵，观点不一样没啥必要解释了。到现在你还是在回避我的核心观点，算了散了吧

#14 楼 @Rei 我是个话痨，有时候会在非核心观点上浪费好多文字，结果导致核心观点一点也不突出。

我跟你的观点正好相反：我觉得对于 Ruby 本身来说，其实并不算慢，或者说至少没有慢到现在所有得到的吐槽。如果用一些合理的设计，比如 h2o 或者 nginx 这种潜入 mruby 用 fiber 来做，是完全可以做到其他很多语言包括 Elixir，包括 Crystal 一个数量级上的性能的。

我曾经今年年初花了很长时间调研能否基于 h2o 与 mruby 来做一个框架，就是针对这个问题来解决。但是我跟人聊遇到的一个核心观点都是"这不是 Rails 我不用"。包括这个帖子里在我们讨论 Crystal 的时候都有人无聊的来问能不能跑 Rails。我这里的核心观点是：我对 Rails 本身没有歧视，我只是觉得对 Rails 的推广已经到了影响到 Ruby 圈内其他生态发展的程度了。包括现在 Rack 也是由 Rails 核心团队维护，在第一次发布 2.0 计划的时候，有考虑过改动核心来支持 Web Sockets，但是之后到现在也就不了了之了。这也就是为什么我之前发另一篇帖子的主要动机，我个人觉得现在的舆论风向是不包容其他解决方案的，这个是件不正确的事。

另外我个人觉得提到 Web Sockets 时就把 ActionCable 抛出来，或是压根就质疑对方有没有这个需求是不正确的方式。作为一个好多人口中的 safe bet，对于一个用处越来越多的场景只有一个半 hack 的解决方案，我个人是不认为这是对的。

所以这才是我想说的话，能解决这个的话，JRuby，mruby 甚至 CRuby 可以说都不慢，就像你说的语言不是瓶颈，我只是跟你对于瓶颈到底在哪里的观点不一致，你觉得不在 Ruby 的任何部分里，我觉得在 Ruby 的好多库里

这个观点简直让我无从吐槽：Crystal 的作者自己写了篇文章，说你们别老用 Fib 来做 benchmark 了，这太 2 了，这样会给 Crystal 招黑，结果这反成支持 Ruby 的人证明 Ruby 不慢的理由了。问题 Benchmark 还有很多啊，有没有兴趣一个一个来攻击证明 Ruby 怎么提升性能。

况且我之前吐槽的时候就给出了一个观点：这年头 Ruby 本身语言级的优化远远没有达到让大家觉得 Ruby 慢的程度，Ruby 的慢更多是因为 ecosystem 的结果，很多 library 的写法让 Matz 没法大改 Ruby，所以现在情况越来越棘手，刚刚有同学发了篇文章也是讲这件事的：https://ruby-china.org/topics/30740。遗憾的是之前的讨论被人看作我是伸手党，哎满是无奈

最后我建议有兴趣的同学想换 Elixir，Crystal 的就直接换，不要再在这里争论这些无聊的事了，本来就不会有好的结果。换个角度讲我们还是需要赞扬 RubyChina 这个社区的，至少管理员们还会帮忙建别的节点包容讨论，而不是直接当成异教徒烧死，不信的去隔壁看看 RustChina，那个人气简直惨不忍睹

#32 楼 @small_fish__ 我觉得可以试试，带不带的起来就要看天了。虽然我现在个人兴趣在 Rust，不过 Crystal 作为一门 work language 还是非常不错的，基本上 Ruby 我想吐槽的地方都避免了

#7 楼 @numbcoder 这个要看你怎么定义了，现在已经比去年这个时候成熟很多了：https://crystal-lang.org/docs/guides/concurrency.html

但是目前来看最大的阻碍是 GC，内嵌的 GC 还是很原始，不过这个也是看怎么取舍了，毕竟当年 Rails 4 分钟重启一次 也就这么过来了。

分享一个 Ruby 圈转到 Crystal 的人的观点：https://twitter.com/soveran/status/736596798500941825，为方便懒的翻墙的人，我在这里也直接引用一下：

Ruby has an imperative desire to expand, maybe inspired by Rails. My wish is for Crystal to never surrender to that culture.

在经历 Rails 这么有争议性的东西之后，很多社区都在避免再造一个跟 Rails 一样庞大复杂的框架，包括 Phoenix 也一样，在尝试避免 Rails 的很多问题。所以我们将来可能会有一个比 Kemal 更具有可维护性的框架，但是估计这个也会跟 Rails 有很大区别的。

Crystal +1，这个时候就是强势植入 Crystal 的最佳场景了，如 Ruby 般顺滑，如 C 一般的性能。还是内部 async 的，光 这里 体现出来的 WebSockets 可能性就够 ActionCable 狂流口水的。

上次吵了半天之后我已经对 Ruby 能不能成功转型不抱希望了，与其想改变那么多人，大热的天还不如我自己求变，换个地方玩就好了

#12 楼 @luikore 哇塞，我也想参加大神教你写代码系列

另外我没有在调侃，我是真心的，吕神这么主动想写代码是件不容易的事。我忍住这么久没在这个帖子上吐槽就是不想吵了

#5 楼 @lychee 我可不可以补充一句，这个解释的信服力无限接近于 0。。。

#4 楼 @fredwu 好吧我土了，感谢指教

I Accidentally Some Machine Learning 问下这个是有意为之么？读了几遍怎么还觉得是个病句。。。

另外 My Story of A Month of Learning Elixir 这里第二个 of 不需要吧？

#13 楼 @luikore 啊好吧，这样，我还真没细看，喷错了

#10 楼 @nong 很抱歉，经过上次的讨论之后我已经懒得在这里讨论 Rails 了，没必要，因为就不会有一个理性的讨论环境。

我前面的问题写法有点问题，这里我想提出的问题是：针对这个 library，这样把实际生成的结构是 array 的语义隐藏在 comments 的类型下面，是不是个好结果。

json[:comments] = {
  content: @message.comments.content,
  created_at: @message.comments.created_at
}

这样的写法会变成：

"comments": [
  { "content": "Hello, world!", "created_at": "2016-06-29T20:45:28-05:00" },
  { "content": "<script>alert('Hello, world!');</script>", "created_at": "2016-06-29T20:47:28-05:00" }
]

这样真的好么。。。还嫌 Rails 中隐藏起来的知识不够多么。。。

#47 楼 @luikore 是的，但是对于 python 圈来说，不遵守 wsgi 没像不用 rack 这么满是邪教的感觉，所以情况会好很多

@luikore 再补充一点，反复提到用 Fiber 的另一个好处是针对合适的项目可以直接上 mruby 了，没有必要搞 CRuby 这一套，配合 nginx 或者 h2o 嵌入使用 mruby 又是新的一片天

#38 楼 @luikore 太长了就不逐条回复了，况且很多观点我是支持的，我只写几点：

• 我举 Lua 的例子，只是说 VM 的优化是一条可以走的路，但并不仅仅是唯一的路，Ruby 即使只是现在的 VM 不去改动，从 library 的层面也可以做很多优化，但是 Rack 这边已经把路线都绑死了。而且 Ruby 社区的一个坏处是死绑 Rails/Rack 不放手，不像 Python 什么的因为从一开始就是多种 library 并行，你说一个其他的解决方案不像 Ruby 圈里很多人会直接流露出“烧死异教徒”的眼神
• 关于CGI 的历史遗留，这个真的是我遗漏了，我一直以为 hash based API 改成 object based API 更多的只是语法糖的处理，真没想到这个
• C 扩展的优化部分，同样参考，这个可能也是一个画的很好的大饼，但实际上能达到什么程度不太好说。不过这个不重要，我要表达的观点从来也不是只要改善 VM
• 是的，HTTP/2 跟 Web Sockets 都不是万能药。但是至少处于竞争关系的语言都有相对应的解决方案，而不是像 Ruby 这样，表示不想跟你说话并扔给你一个 ActionCable 另外 Faye 也不是一个很好的解决方案，我们这边有太多的库为了兼容 Rails 这一套而放弃 Fiber 或是其他的可能性了
• 从来就没有人说 Fiber，eventmachine，coroutine 这些没有问题，只是当每个人每写一个 Ruby 库都假装 Fiber 这一套不存在，而只关心兼容 Rails 这一套时，问题就出现了。我反复提到 OpenResty，也不是说 OpenResty 就没有毛病，相反 OpenResty 写起代码来很烦，烦到我还保持了 Ruby 这套架构没动，当确认不需要太高的并发时，还用 Ruby 这一套。但是 OpenResty 至少有一点做对了：OpenResty 里基于 coroutine 做了一个完全异步的 socket，这套 socket 同时保持了跟已有的非 OpenResty 的 Lua 库中的 socket 完全相同的 API，这样的结果就是，如果针对这套 API 编程写库，那并不是十分关心下面是在原生的 Lua 以及 POSIX 的 socket 上跑，还是 OpenResty 里面基于 coroutine 的 socket 上跑。这才是我觉得 Ruby 圈里我们应该考虑前进的方向。而不是一味的列举说 coroutine 也有坑也不好，就像上面说的，一切都是 tradeoff，当我想接受 coroutine 的弱点同时拥抱它的优势时，不应该是面对市面上 99% 的 Ruby 库都不兼容的一个悲惨景象

就像我反复提到的，这里不是说 Rails 完全不好，这里更多的是说，我们需要给大家提供更多的 options，不然现在 Ruby 圈的弱点会远远压倒仅剩不多的好处

#36 楼 @jasl 最近刚刚有 VM 级的大神表示这条路不是很好：https://www.youtube.com/watch?v=b1NTaVQPt1E，我很尊敬 Yehuda 这个人，但是每个人都是有自己擅长的领域的，涉及底层性能优化部分，个人认为 Yehuda 不是很懂。

另外就是跟我之前回复吕神的观点一样：现在问题不仅仅是 VM 层，更多的是这个 ecosystem 导致的架构上没有什么灵活性，而且问题起源甚至不在 Rails，而在 Rack 层。

#37 楼 @small_fish__ 是的我们也有同样的体验，从来就不需要那些无聊的 Russian Doll Caching，感觉就是自己给自己找麻烦。

另外就是如同上面 @nouse 说的（虽说我觉得这位同学吵架朝偏了），现在越来越多的 startup 的架构是前段直接 native app，或者是 web app，然后通过基于 JSON 的 API 来跟服务器通信，这样 Rails 提供的很多拼模版的功能完全没有必要了，而且还带来额外的性能负担。从这个角度讲，可以认为 Rails 这一套已经逐渐过时了（是的我了解有 Rails API 的存在，但是性能还是很拙急）

同时 H2 Server Push/Web Socket 带来的 Real Time 架构是 Rails，甚至基于 Rack 的 Ruby 都没有办法处理的。从这里来说，我感觉现在再选择这一套就是先给自己挖了个大坑，然后安慰自己这个坑还不够深。。。

最后再给一刀，虽然我尽一切可能不用 Elixir，但是 Elixir/Phoenix 这一套也已经挤压到传统的 Rails 生存空间了，这是刀刀把人往死路上逼啊

还是那句话，我个人的观点是，虽然现在 Rails 看起来还可以，但是其实已经到了很危险的时刻了，社区再不做些什么，就只能是走向衰落了

#32 楼 @luikore 这是一方面，另一方面是基于 Rack 的这套系统也从来没为性能考虑过。参考 OpenResty 里面是可以跑 Lua 官方的实现以及 LuaJIT 的，根据场景的不同，很多重 IO 轻计算的需求中，Lua 官方实现即使就是一个 interpreter，也没有比 LuaJIT 慢很多，归根结底是基于 coroutine 的结构减轻了很多架构上的负担。

所以我赞同 Ruby 本身的语言设计就不适合优化性能，但是 ecosystem 的方向也没有为性能考虑过，假如大家都在 fiber 的方向上努力，那即使达不到 2ms 那种级别的性能，至少也不会是现在赤裸裸的被嘲笑的现实了。所以我觉得总把锅放在虚拟机上面是不对的。

PS：ActiveRecord 真心不熟这个就不直接评论了，省的被抓到小辫子，毕竟吕神歪楼的能力还是一等一的

#25 楼 @xiaoronglv 现在就是这样，Ruby 拼死拼活优化之后，可能都没有别的技术随便拿来写写的快（当然我不是在暗示这里提到的 Teddy Wang 他们只是随便写写，2ms 还是很牛的，不过随便写写可能也有几十 ms 的级别的了，这基本上跟合理优化过后的 Rails 是一个量级了）

这已经是一个很危险的信号了：如果我们再不反思如何变通，而是继续死心眼的坚持“瓶颈在 SQL 而不在 Rais”，或者是“你需要那么快么”，或者是“机器比人便宜”，那从 Ruby 圈流失的人只会越来越多。

#24 楼 @luikore 这个是小细节好吧。。。我们用 Redis 做后端的服务，同样的逻辑 OpenResty 可以比 Ruby 快到 2 到 3 倍，这里数据库不是瓶颈了。。。况且这里从来没有说 Ruby 搞不定这些事情，这里都只是说用 Ruby，Python 之流可能需要额外花好多精力来处理这些在其他框架里没有的问题

另外你适合花大精力推广 Haskell。。。不适合鼓吹 Rails。。。

#13 楼 @huacnlee 这个我赞同，我本人也从 Rails 中学到很多理念，但是我想要表达的一个观点是：在现在这个时代，仅仅靠 Rails 的理念是不够了，Ruby 圈需要更多的空间。

#12 楼 @rei 要 code 的话 Elixir 满满都是 code，我只是想引发一个“为什么 Ruby 社区见不到这样的 code”的讨论

#10 楼 @fcicq 很抱歉，说 websocket 比 h2 味道更正确对我来说，跟无数标榜着 xxx is yyy done right 的无聊 library 没什么区别，都是觉得品味重于一切，而没有意识到一个人的品味跟另一个人可能完全不同。

更多的情况下，我不会只关注代码写起来漂不漂亮，我更会关注是否有架构上的可能性，而不是为了一点点 DSL 的好处给架构上增加更多的难度。当然在其他条件相同时，我赞同代码是应该写得漂亮一点，但是话又说回来，漂亮不漂亮怎么衡量呢？

#8 楼 @fcicq 我理解你是想说 http2 协议自己的 server push 是只能推到 cache 推不到 application 层的，但是还有个东西叫做 Server Sent Events。同时 HTTP2 只是我举的一个例子而已，我的核型观点是 Ruby 圈不务正业好久了

#3 楼 @pathbox 这里我建议的 metric 不仅仅是“足够成熟”，而是“是否可以带来新架构的可能性”，我对 PHP 不熟没法做评论，但是从我接触过的 PHP 工程师的平均水平来看，我深表怀疑。

#1 楼 @small_fish__ 我个人觉得这个不是缺场景的问题，Firebase 的 API 里已经开始做 Real Time 的东西了，在客户端主动去服务器端拉数据之外，服务器也可以把新数据主动推送到客户端。

我的想法是这个和当年的下拉刷新一样，只需要一个引爆点，一旦有一个流行的 app 把这个东西引入，培养出来习惯之后，所有的 PM 都会要求工程师同样去做这些事。这时如果没有解决方案，那不是工程师的锅，但是既然 HTTP/2 给出了这样的架构我们还不去这样做的话，那就是我们的问题了。如果真到了每个 app 都这样做的时代，Ruby 才去应对就晚了

为什么不只用 Grape 做 API？前端按照现在的趋势多半也会用 React 之类的框架，做 frontend only web app，也通过 API 通信就好了

歪个楼，现在青云的带宽足到能保证那天不 down 机么