我没用过 hotwire，对这个技术也没做过研究，所以没有办法对此给出任何评价。

前端可能有自己的想法，有可能是觉得难，或者觉得没有学习的必要。不过这个还是前端来说比较好。

总结下来是不是

1. Hotwire 依赖 DOM HTML，对新时代前端不友好
2. 导致上手成本高

感觉楼主可以展开说说。

Rails 的开发者多数是后端或者是全栈，所以他们看问题，多数是从后端或者全栈的角度来看的。

但前端有前端看问题的角度和方法。所以具体聊聊，可能会很有意思。

评价一个事物，需要跳出来看看。比如西瓜好吃，那需要尝尝几种其他水果，甚至是和蔬菜，肉对比一下。

棒棒棒

我们有一个项目，原来是用 Erlang 写的，打算用 Rust 重写。还没重写完，tokio 就升级了。。。

Erlang 这段时间，做了一些优化，扛住了并发，稳如老狗。

可能看看 tokio 的 example，看看 match 会好一些。

如果一个人用工作时长的一半就完成了他的工作，剩下的时间他选择阳光海滩。而另一个人每天加班加点，超时工作才能把事情做完，果断给第一个人加工资。

软件开发，工作完成，很难界定。比如一个东西，修修补补就 30 分钟，但要是考虑合理行，就要几个小时。

再比如文档，写文档会花很多时间，还不一定算在产出里。

Redis 单线程，首先是因为他是内存型的（Redis 落盘默认也不是每次都落），内存操作比较快，多线程要考虑锁，锁冲突，编程难度大。所以做人认为多线程可以。这种玩法，是很久以前的玩法。

不少 key value storage 是用多线程，比如 Erlang 的 ETS，可以跑满 60 几核，可以随着 cpu 核心数横向扩展，是一个比较有意思的事情。但实际工业上，多数靠集群抗，再加上有 docker。Reids 5 的一般上限制是 5w ~ 6w qps，不少应用，都到不了这个 qps。所以，单核就单核吧。

多说一嘴，in memory 的 key value 瓶颈可能也不在 cpu 那，在网络协议。

大佬，听说你们公司还在招 Ruby？都有什么要求啊？

这个工具是否有用，要看项目的复杂程度，简单的项目用处不大，但复杂的项目就有帮助了。

之前有次 ES 负载不均，搜索服务一直报错，用户开始反馈，更尴尬的是没熔断。搜索团队给了各种建议。我们的负责人（业务网关在我们这）说，把这个功能去掉，上线。。。去掉了一个月，也没有用户发现。

大佬带带我

架构设计，log，监控，压测，灰度方案，回滚方案，限流，降级方案，扩容方案。

除了架构设计，基础服务好的话，做起来很方便，没有的话，就很麻烦。

感谢，已更新。

来呀～～～

有个研究数据库的人参加 大数据大会，他说他非常高兴，终于知道自己这四十年来，研究的叫什么了。

还有写相关的，比如红蓝黄。再比如疫苗，再比如奶粉。再比如三鹿 http://finance.people.com.cn/n/2014/0812/c66323-25446708.html

多看看新闻联播心情就好了。

https://mp.weixin.qq.com/s/sqFkBEIMhKlMuvvhMPnTTg

聊到 Large Scale 的时候，还盯着 web server 的话，就特没啥意思。。。

现在招聘计划有变，我先问问他们。

我们就叫 crypto.com

我们公司叫 crypto，我以为你在说我们。

在哪都差不多吧，可以线上交流啊

嗯，是的，前后端分离，这些事情，都是前端的活。

嗯，是的 Github 和 Shopify 确实做了很多。

但比如 微服务，熔断，限流这些，似乎支持的不好。再比如 ActionCable

Rails 在快速开发上已经做的非常好了，但在高性能上，似乎并不怎么好。

Rails 一些东西是假设流量不大，架构简单的场景。Rails 似乎没想法走出这个场景。

数据库少了 NewSql 还有 OLAP 这些。

我现在的公司，Ruby 服务线上的 CPU 很早就上千了。出了很多问题，在我的印象里，没有一个是由语言引起的。

上份工作，整个后端服务（这个服务是企业级的，虽然我不知道企业级是怎么定义的 ），CPU 用了大约有 300 到 500 吧，语言有 Clojure/Erlang/Java/Rust。

1000 核的 CPU 在阿里云上，一年大约 100w，大约是 2 ～ 3 个初级程序员的钱。

Erlang/Java/Rust 的服务都做过或者看过别人做过一些优化，大多数问题，还是跟架构，实现有关。

还遇到过很多有趣的事情，比如 Erlang 并发好，结果流量一上来，他第一个躺尸。Rust 不是内存安全吗，一部署，丫内存就涨涨涨。倒是 Java 保持了他一贯的水准，经常内存泄漏。

我们有个服务原来是 Erlang 的，后来用 Rust 重写了。Rust 一样要解决性能和扩展性的问题。Erlang 性能是差一点，但目前的流量，翻十倍，Erlang 一样扛的住。翻一百倍，Rust 没准也会躺。Rust 和 Erlang 比起来，确实能省些机器钱，但太折腾了。Rust 是快，但网络延迟考虑进去的话，也就优势不大了。

高并发、高性能、高可用

web 开发，瓶颈在 IO。不过 Ruby 并发确实不咋样。不过，还是那句话，多数的时候，问题没在语言上。

高可用上，ruby 积累的很少，甚至可以说还没有这方面的意识，但多数手段，跟语言也是无关的。

感谢，试了一下，很有帮助