先过一遍 rails guides？以后就是靠自己摸索，以及看源码了

他这里面东西太多了，运行起来你看多少个进程。考虑到可延展性架构很复杂。其实如果你只是要个仓库，就放个裸 git，issue 管理外面用个免费的比如 youtrack 就行了，如果你不需要很多功能的话

不要换，ruby 就是硬

以下仅代表个人经验：

用 hotwire 的时候，不免会思考，这个交互是放在服务端还是客户端。这点界面变化，我是为了渲染接口统一走后端，还是用 dhh 的 stimulus 在前端搞一搞？

实际使用下来，vue 2 那种模式是最方便的，把他当成一个强效版 stimulus 就可以了。hotwire 拉 html 不够的时候，自然的引入一个 vue 2 做前端渲染，保证最大的灵活性。

DHH 肯定是在宣传自己的理念了。前后端一体是个好的想法，只是某些时候可能会比较费脑子。举例说，我有一个 3 个标签页的结构，如果用 hotwire，还得纠结一下这三个标签是一次渲染出来还是分批渲染。分批我还得搞 3 个 action 这种事情。React 则胜在简单粗暴，上就对了。

至于打包开销，自从有 esbuild 后，一切都很轻松愉快。第一次从 webpack 换过来，真的是把一分钟的时间缩到了 2 秒内。

我倒是希望前后端一体话可以有更加容易理解和执行的解决方案，能让 Web 开发更加简化。

你怎么看出来这里的人都沉睡着？人家问 rails 有没有技术优势，又没问怎么挣钱。人生导师当惯了？

仍然具有极大优势。借鉴的那些你用下就知道了，只学了点皮毛。光一个 orm，别的借鉴的都缺胳膊少腿的，比如 migration 有限制，没有自带，不给脚本等。以及不给测试。这都还是 mvc 的一个 m，其他两个都还没提到，更没有提三个结合在一起，外加后面经典几个 gem 带来的巨大生产力提升。

拿起键盘，复制粘贴，就是干

java 也不是默认性能就强，都是要好好调教的。ruby 做项目一样，都是要想办法的。这不能证明是语言性能的差异。

1.9 开始就 vm 了。我估计你是在思考一些不存在的问题，就是 java 里面 jvm 垃圾回收是否效率高，jit 是否牛逼等等等。ruby 世界里不是这么解决问题的。

不否认多线程模型是有用的，但是现实里很多时候多进程就搞定而且更好。另外 ruby/python 这边本来高性能部分就是要上 C 的，不是想做 java/js 那种全家桶。说白了 java/js 想替代一切那都是为了宣传，至于要干活，办法可以有很多，条条大路通罗马。

benchmark 这个 gem 没用过吗

同意 1 楼的。

第一，花括号和 do end 这个从没有思考过程，就是单行/多行 第二，if 这个，写 if 的时候我思考方式是这样：要么是情况比较简单，我就会想 if a 则 b，这样就看这个 a 是不是足够简单，如果是就写单行，不是就考虑多行。否则我就是 if esle 先铺好，再填内容。无论哪一种我不会纠结单行还是多行。

关于以上两点，还有一点可提的是，ruby 这些功能都是为了可读性而设立的，不是为了一次打字不纠结设立的。写代码的时候为了可读性而改已写好的部分是很经常的事情。退一步讲就算我写了单行 block，我发现此处多行可读性更强，那我就回头改为多行。这就跟回过头去对齐等号，加注释等等行为是完全一样的。

我不认为“有更多选择”就带来“纠结”。抛开语法层面，本身代码逻辑，一种逻辑也有很多种可能的形式。那这一点我们为什么不纠结呢？

然后就是可读性问题了。如果你习惯 C，那么 C 和 C++ 的很多发展本身也都是在提高可读性。举个简单的例子，上学的时候我和小伙伴写 C，包括老师，我们都是写 while(1) 来做死循环，大家都看得懂，但是按现在眼光都会用 true 代替 1。

关于最后一点 c like 的问题，这世界上编程语言可以说五花八门海了去了，见得多了，每种风格都有它的好处。这一点个人认为不仅不是障碍，而且是必经之路。

还是进程隔离好，ruby 多线程并不强。多进程也不是想象的那么耗内存。

人家都是 SPA

就目前人才市场来说，前后端分离会令一般开发人员比较好理解。但其实你想想在没有前端框架的时代，公司也是有专职前端的，这一点并不矛盾，也就是说用传统 Rails 一套也是可以引入前端开发的。

流畅度参考 Basecamp，Stimulus 的示范，速度非常流畅。另外 Basecamp 也打包了 app。我自己的体会是前后端分离在很多时候是一种负担，直接把 Web 开发升级成了 App 开发。在一些强交互的地方局部使用 Vue/React 是我比较偏好的做法。

直接招人，要求用 Rails 即可。此外，没有特别原因搞前后端分离的话，是会增加投入的。Rails 开发效率高，就是因为是个通吃的框架。富前端，不妨考虑 Stimulus？

带头的蠢吧，需要高度协调一起踩坑

广告做的差，领头的是日本人，不擅长在欧美推广

顶楼是错的，要讨论再开一帖吧。

jekyll 或 wordpress，自己写功能差远了

grep/rg玩的转，没啥问题

我也是 Linux 很久最后转 Mac/Win 了。Linux 从 Fedora Core 5 开始折腾，经历过 Fedora，Ubuntu，Arch，Suse，都是做过主力桌面的。发表下个人观点：

桌面系统我们需要一个成熟稳定的东西，来把精力放在更重要的事情上。使用这个桌面的用户和为其开发的开发者数量将是硬指标。在这一点上，Win 远大于 Mac 远大于 Linux（桌面）。但是在开发者领域 Mac 和 Win 的比例就没有那么悬殊了，具体不好说。选 Mac 的理由就是 Unix 系统外加完善的 GUI。其实 Mac 也有不稳定的时候，比如 macOS 10.11 和 10.12 对 4K 屏幕兼容性问题（鼠标指针漂移）就困扰了我好几年。但总的来说 macOS 我从 10.6 用下来，基本稳定。尤其是在电池、温度、功耗上的平衡是令我想当满意的，尤其是 Haswell 之前是别家两倍的续航，那真是提前进入下一个时代。

从硬件性价比上，mac 的确不是最佳的。但是这一块通常不是太大的问题，因为一来生产工具预算充足一些，钱也买不来稳定 GUI+Linux 跑在 Windows 笔记本上。二来如果考虑到某些因素可能性价比不是那么差，例如 iMac 的 5K 广色域屏，如果单买也很贵。

另外，作为开发肯定推荐 Pro，目前的话，用的 8 代，13 寸性能也很强劲，轻薄程度还不错吧。像我手里的 2014 款的话，当年的 13 寸，低压版 CPU 性能就要比标压差很多。

从软件上来说，说到动画，这个就是适应。有人觉得炫酷，有人觉得烦，但没必要太纠结。实际上 macOS/iOS 的设计理念，动画往往是给人以提示作用，而非酷炫，只是别家图形界面用文字的，这边改为动画了而已。这一点我是 iOS 开发多年，这是他自己 HIG 说的。

快捷键方面，我的看法也是适应大于更改。mac 快捷键是有不少槽点，比如我以前 Photoshop 每天按一万次的 command option shift s，这就一点也不“快捷”。但是系统没有完美的。我在做移动开发那几年，需要同时操作 vim 来写后段代码，Xcode 来写 iOS，Android Studio 写 Android。而我因为 IntelliJ Idea 用过一阵子，快捷键又是默认的，所以我脑中同时要在三套快捷键之间切换。这三个工具基本鼠标都是配角这个大家应该没意见。是的很繁琐，甚至有些变态，但是回想下，能最有效同时运行这三个的，只有 mac 系统。那时候甚至 windows 的 Android 模拟器执行效率都大不如 mac，后来才赶上。

我有理由相信，macOS 是除 Windows 开发外的首选系统。

我们一般就是花式 rg、awk、甚至 ruby 来搜索。搭建日志服务需要花费一些精力，也需要额外时间维护

对比度太低，界面不同功能区域不突出。整个界面全白晃眼睛，毫无品牌辨识度，貌似是自大到不需要？

本身的重启是使用 unicorn 的 USR2 信号进行无缝重启的，唯一的问题是等待时间。要排查这个问题，你需要了解 unicorn 无缝重启的过程。

please read /Users/shan/.rvm/log/1540623603_ruby-2.5.1/configure.log

这个日志你可以分析下

我这个帖子里提到了 M_ARENA_MAX 默认值的变化（从 2 到 2 * CPU 核数），有人怀疑是 red hat 为了讨好大用户（通常拥有足够的配置）所以用空间换性能。最后页面下方 sidekiq 作者和 Sam（一开始 jemalloc）的倡导者也都达成了一致，认为 malloc 和 jemalloc 的区别的原因是他们默认参数的不同。换句话说 malloc 如果设置了 M_ARENA_MAX = 2 也可以达到 jemalloc 的评测性能。因此两者并没有所谓的性能上的明显区别。

持谨慎态度的人并不仅仅是认为 jemalloc 会带来问题，而是如果不能证明 jemalloc 确实更适合 ruby，那么就没必要作为默认选项（本帖的讨论内容）。毕竟这不是一个小的改动。

https://bugs.ruby-lang.org/issues/14718 在这个里由后续。结论是 malloc 的问题是在 glibc 在某个版本开始某个默认参数发生了变化，如果调回去就跟 jemalloc 差不多了。而 jemalloc 不同版本表现也不尽相同，无非是时间和空间的取舍。最后大家一致认为最佳解决方案是调整 malloc 的那个参数，因为对于 ruby 的场景更为适合。

break if str[v+=1] != 3

不是可以吗