看到这条 Ruby 优化的新闻，想起当年在深圳创业初期。那时候年轻气盛，总觉得代码跑得越快越好，恨不得每一行都塞进汇编里。为了那零点几秒的响应时间，熬过好几个通宵。

后来服务器崩了几次，才懂路宽不宽，跟车技关系不大，跟路况有关。现在回头看，那些所谓的“极致路径”，很多时候只是给未来埋的坑。开源社区里大家讨论这些细节，其实是在找平衡点。

有时候慢一点，反而能走更远。怎么说呢就像我摄影一样，对焦慢了半拍，画面反而稳了。嗯…各位在重构老代码时，多留个心眼吧。毕竟生意场上，活下来比跑得快重要。

话说回来，你们那边跑 Ruby 的多吗？还是早就转 Go 了？

Ruby 还在跑，主力服务用的 Puma + Redis 缓存层，没急着换 Go。你提到“极致路径埋坑”这点我深有体会——去年重构一个老 Rails 项目，硬塞了几个 inline assembly 风格的 C 扩展，结果 CI 跑不过 ARM 架构，回滚三次才稳住。现在宁可多花 50ms，也要保证 deploy 能一次过。话说你当年崩服是不是也栽在类似地方？

看到你说熬通宵那段，手里的黑胶唱针好像都顿了一下。我也常为了赶动画帧数盯着屏幕发呆，那时候觉得时间不够用，现在反而觉得慢一点才有呼吸感。

以前当兵的时候养成的习惯，总觉得闲下来会慌，所以退伍后总找事做。但代码也是艺术的一种吧，就像文艺复兴的画，笔触急了线条会抖。你摄影那个对焦的例子很妙，有时候留白比填满更有力量。

我这边主要折腾的是绘图软件脚本，Ruby 用得不多，不过比起 Go 那种冷冰冰的速度，我更喜欢能读懂逻辑的语言。毕竟活着最重要，身体垮了就什么都没了。东京的夜虽然亮，但也别把自己逼太紧。是呢

改天聊聊爵士乐放松下？深夜听 Bill Evans 配着热咖啡，感觉心情会很気持ちいい。要是你也喜欢蓝调，下次给你推荐几张老唱片。

你提到C扩展在ARM上翻车…，让我想起08年那会儿给一个嵌入式项目硬塞SSE指令，结果客户拿去跑在龙芯上，当场哑火。现在想想，所谓“极致优化”，很多时候不过是把地雷埋得更深罢了。别急你们用Puma配Redis还算稳，真要换Go，怕不是得把整个后勤体系都推倒重来？

你提到“代码也是艺术，笔触急了线条会抖”——这让我想起去年在首尔用 Ruby 写一个 SVG 生成器时干的蠢事。为了压低 GC 压力，我把 Symbol 全换成 frozen string，结果 render 出来的贝塞尔曲线在 Retina 屏上轻微错位，肉眼看不出，但打印出来边缘发虚。debug 三天才发现是字符串哈希碰撞导致缓存键污染……文艺复兴画家调颜料都讲究干燥时间，我们却总想让解释器一口吞下整管钛白。

Bill Evans 的《Waltz for Debby》我黑胶柜里有 Columbia 6-eye 版，但你说深夜配咖啡听蓝调，建议试试 Grant Green 的《Idle Moments》——1963 年那版混响像凌晨四点的汉江水面，尤其适合盯着 bundle install 的进度条发呆。不过别学我疫情期间在釜山隔离时连喝三周冷萃 debug Rails asset pipeline，最后胃镜查出 erosive gastritis，医生说我的胃黏膜比 precompiled assets 还脆弱。

话说你做绘图脚本，有没有试过用 Ruby 的 Fiddle 直接调 Cairo？比 RMagick 轻，还能保留矢量精度。虽然文档烂得像被猫抓过的乐谱，但至少不会因为优化过度把 control point 给 optimize 掉了……对了，你退伍后还保持晨跑习惯吗？我靠每天六点绕梨花女大跑圈才戒掉通宵写 monkey patch 的瘾