Ruby 的魏玛时代：DHH 主题演讲后，Ruby 社区为何迎来文艺复兴

关于 DHH 在 RailsWorld 上的主题演讲，已经有很多讨论了。对我来说，那是一个身处存在危机之人的声音，而且还是一个非常厌倦的人的声音。“看看我多么不在乎了，你们也不该在乎”并不是一个很好的信息，尤其是当你是这个你本人曾游说争取来的大会——我们姑且称之为 CareConf——的头牌演讲者时。

最高领袖传达的信息很明确：我们用 vibe 重写了 HEY，性能更好，效果很棒，我们不再需要 Rails，也不在乎它了。我真诚地相信，与其通过尖刻的真相轰炸来赢得更多掌声，他本可以只是安静地离开那个他不再喜爱的玩具——包括它的社区。

但事情是这样的：富人和名人失去对好东西的兴趣，并不迫使我们也失去兴趣。如果说有什么影响，那反而是腾出了空间。

🧭 我目前可以接合同工作。 雇用我来帮你改进你的 Rails 应用！

我必须承认，有几天我对这一切感到非常沮丧。不是因为“AI 会写所有代码”——这一点我很清楚，我并不哀叹手艺领域的变化——我哀叹的是使用领域的变化，这是另一篇文章的话题。显而易见，LLM 会一直存在，逐行手写代码不再可持续，天平已经发生了深刻的变化。让我沮丧的是，人们对 Ruby 生态系统和社区如此漠不关心，以及 David 为了“在单个树莓派上运行它”（如他所说）而将整个 Rails 和 Ruby 文化弃之如敝屣的轻蔑态度。

我实际观察到的却是另一番景象：一场复兴，尽管不少知名的 Ruby 开发者已经转向其他技术栈——这些技术栈现在更值得探索，因为你不用再手写那些……垃圾——我们就直说吧。解析 7 个小端整数并不特别有趣，也不艺术——它就是垃圾，我不会怀念它。除非需要结构体打包来提速，但那时我们总可以额外进行艺术指导。

德国历史上有一段有趣的时期，正好在两次世界大战之间——“战间期”，魏玛共和国时期。那是一个非常动荡的时期，很多方面一点也不美好——社会困难、失业、惊人的通货膨胀、肮脏的生活条件、最狂野的运动、歌舞表演和邪教的涌现……但还有别的东西。魏玛德国的“咆哮的二十年代”也产生了数量惊人的伟大、异想天开、引人入胜的艺术运动。从包豪斯到柏林同性恋歌舞厅，从库尔特·魏尔到弗里茨·朗的大都会——那是一个蓬勃发展的时代，当时出现的许多东西至今仍被珍视。

那也是一个技术繁荣的时代——电力越来越普及，现代药物大规模部署，地铁，汽车……迷人的时代。

我知道那个时代是如何结束的，不——那不是我想要的类比部分。我想要的部分是：旧秩序失去了兴趣，没有人掌权，脚下的土地在每个人脚下移动——而那正是最有趣的作品被创作出来的时候。巨大的动荡，巨大的工业变革，没有成年人的监督。听起来熟悉吗？

而 Ruby 社区一直充满艺术气息，早在 _why 的作品中就是如此。毕竟，美学正是吸引许多人进入 Rails 的原因。你不需要括号。事情不是像荷兰人发明的那样写成一个词，没有“这是属性，这是方法”的混淆……这门语言的许多方面在美学上都极为出色。

而随着大量新工具的出现，看待生态系统现状的正确心态应该是：

你说得对，但这也显得目光短浅？你拥有前所未有的最强大工具，你已成为千倍创造者，却想不出如何让你的技术栈好上十倍？

是的，Rust 很快，类型系统能捕获 bug，但除此之外还有太多东西。

* 为什么不让 Ruby 快上十倍？
* 为什么不让 Ruby（以及因此的 Rails）在并发方面真正出色？
* 为什么不为 Ruby 添加一个能提供超越 Rust 保证的惊艳类型系统？
* 为什么不将 SQLite3 嵌入 Rails 并配以复制协议，从而真正将技术栈压缩到超越单台服务器？
* 如何预先修复 Rails 最关键部分（如数据库连接池）中的大多数 bug？

是的，谁在乎 ActiveSearch，但我们可以从根本上改进技术栈的方式太多了，远不止让智能体胡乱输出代码。Phoenix 仍然是唯一自带 presence 功能的框架，因为事实证明，正确解决这个问题出奇地困难，但不知何故所有问题都解决了？

我理解有些人对做上述任何事情都不感兴趣，这没问题，但至少把接力棒传给那些正想做这些事的人。

PS：我说这一切都出于爱 ❤️

September 26, 2026

为什么，在如今 Ruby 中我们能做的所有事情里，我们却选择做 Rust 风格的氛围重写？当然，故事是这样的，我们所有的应用都会神奇地转变为加速的、不透明的 SIMD 二进制块——由 LLM 翻译我们的每一个决定，无论显式还是隐式，并经过严格的对比测试（或者通过阅读茶叶矩阵系数）。如果可以把我们已居住的花园夷为平地，换成辉煌的混凝土，为什么还要花费宝贵的 token 去改善它们呢？

但当然，从来没有人那样做

而且，幸运的是，夷平和替换并不是唯一正在发生的事情。否则故事就太悲惨了。

你看，Ruby 运行时和“场景”中存在大量问题，从技术上讲，它们只是“太多了”。

• 生成带布局的 PDF 会很痛苦——没有库
• 你无法再构建原生 GUI 应用程序——没有库
• 你无法轻松生成原生 gem——除非你准备以极其精确的方式拼写出数百个 ubf_unblock 和 INT2FIX……

所有这些都是糟糕的问题。即使对一个 3 人团队来说也太多了，有时甚至更多人也不够。将它们引入应用程序的障碍很高——即使我们拥有它们——因为在大多数公司，Rails 应用的发布周期并不那么快。许多人会绝望地举起双手，说出那句恐惧的咒语：

反正没人用 Ruby 做这种事。

我们大家都记得，《恐惧咒语》的咒语手册是这样的：就在我们念出“Rails 开发者很难招”之后，所有讨厌 Ruby 的人就可以跳个小舞，来证明他们说得对。

但如今，这个等式已经发生了翻天覆地的变化。让我给你举个简单的例子。

人不能随随便便就生成一张发票

Ruby 一直以来典型的糟糕问题之一就是 PDF 生成。就在 18 个月前，一个 Rubyist 如果想从他们的 Rails 应用生成 PDF 文件，会面临一堆选项，而每一个都同样不吸引人：

• 运行 Gotenberg，让 Chromium 渲染 HTML，然后将其转换为 PDF
• 使用 Ferrum 启动本地 Chromium，做同样的事
• 使用 Prawn，然后跟它近乎逐字符的手动坐标定位搏斗
• 使用 wkhtmltopdf，它大约四年前就被废弃了，还要跟构建它及其必需依赖项较劲

Prawn 在过去很棒，但非常具有挑战性——主要是因为它强制要求近乎完全的手动布局，没有任何合适的度量或排版引擎功能。所谓排版引擎，就是帮助你放置和平衡排版字符，使它们适配到预设大小块中的引擎。有时，你还想调整那个块，让你的布局看起来更好——而这正是 CSS 真正擅长的。而且你还想要断词和 SVG 输出……

虽然 Cursor 和其他“第一波”AI 工具让跟 Prawn 搏斗稍微愉快了一些，但距离“轻松”仍然差得很远——在各个方面都是如此。

这正是“在 Ruby 里做 X 很烂”的定义，而且对某些人来说，完全不使用这个平台也是合理的论点。或者，也可以运行额外的微服务（或者叫巨型服务，考虑到其体积，任何内含 Chromium 的 Docker 镜像都更应该这么叫）。

现在——快进到今年九月。在短短几个月内，我们不是有了一个，而是有了两个出色的 PDF 生成库。

Waka 的 sghtmltopdf 创造性地重新构想了 wkhtmltopdf，用基于 Servo crates 构建的、带有 vibe 的 Rust 布局引擎替换了它的 WebKit 核心，该引擎支持相当一部分 CSS 布局指令——还加入了来自 Typst 的 Rust 库，用于字体处理、度量、行排版……我在大约一小时内就把整个发票生成从 Ferrum 迁移到了它上面。起初它有一些粗糙之处，但社区大约用了一周就把它们打磨掉了，然后它就变得很棒。不是“3 个文本块的手动证书布局”那种棒，而是真正的“带表格、块和矢量图形的 6 页发票”那种棒，而且生成一份文档只需两位数毫秒。

Mikael Henriksson 的 stationery 采取了不同的方法——更接近 Prawn，并加入了大量 Phlex 元素。它坦然接受了一个事实：PDF 就只是……文本——因此，任何能够在某处写出文本文件的工具都应该毫不羞愧地输出它。它采用 Phlex 风格的视图组件和块，用一些令人愉悦的布局原语将它们包装起来——结果就是一种更具 Ruby 精神的 PDF 输出方式，性能可与 sghtmltopdf 的 Rust 引擎相媲美。

我能在很短的时间内对两者进行改造，但仍然有点难以抉择。我们从“所有可用选项都非常糟糕的绝对荒原”迅速变成了“你可以在两个很棒的选择之间挑选”。

我们做事是因为我们想做

而且它并不止于 PDF。Qt 绑定又在开发中了——不错的、大型的 Qt 绑定。这是我记忆中 Ruby 一直存在以来就很糟糕的东西。Schwad 以 Scarpe 的形式复活了 Shoes——不是那种需要 SWT、JRuby 和一大堆东西的阴郁 Java jar，而是一个由 Ruby 脚本驱动的正经图形后端，全部使用原生图形。RMagick 又开始定期发布，并且运行得很漂亮。GD 绑定也正在开发中。

在我这边——我遇到了一些涉及 Rails 的相当大的 ETL 项目，而我总是会碰到的一个痛点是 Parquet。从 Rails 应用轻松输出它根本不可能——我们总是不得不降级为 CSV，或者拼凑一些奇怪的 CDC 管道来绕过应用，仅仅为了生成数据湖。我当时的看法是，Parquet 被严重过度设计了，而你可以用一把钝叉子搞定 CSV。而且在任何不是 100% 原生 Apache 大数据文化的环境（即不是 C++、Java 或 Python）中，使用它都很痛苦。

这让我很恼火。不，不能是“我们的小玩具语言太慢太小，谁在乎它呢”——Parquet 文件只是字节。另一种自制的 swizzled-and-zigzagged 字节编码约定、结构体重复、可插拔压缩模块和原生宽度类型，再加上一些编码设施……它只是很复杂。它并没有特殊到需要原生代码，也没有大到需要一整架 JAR——它只是太麻烦了，不值得处理。少数确实存在的库通过链接 GObject 以及谁知道还有什么来处理它。那片荒漠持续了十多年。现在，我能够在几天内构建一个完整的 Parquet 库——herringbone。曾经是 Rails ETL 中一个拖累的问题现在根本不是问题——有一个对人和代理都方便的 Ruby 库，它可以流式处理，在适当的地方使用原生压缩模块，并且只需要最少的用户代码——甚至包括像 Parquet 加密这样相当高级的功能。

不，你实际上还不能一次性完成这样的库。你确实需要知道你想要什么，而且你确实需要迭代，才能让它变得精致和快速。或者，换句话说：你会一次性完成它，但结果在美学上不会好。Ruby 的东西必须看起来（和感觉）好。现在我不再需要花几天时间弄清楚 Thrift 位打包的复杂性（我也不怀念那玩意儿）——我可以自上而下地设计 API，并引导 LLM 完成它。

以前，制作这样一个库会花我几个月时间。制作 zip_kit 花了 3 个月（分摊到十年，其中 2 个月集中在其诞生前后），而 Parquet 规范的规模是 ZIP APPNOTE 文档的 5 倍。如果 ZIP 是一场建筑学上的酒精之旅，那么 Parquet 就是一场恐惧与厌恶式的建筑学宇航冒险。

更不用说我还得为了调用一些压根没提供 Ruby SDK 的云服务而临时拼凑出大约 6 个微型库。或者至少 2 个我知道质量或打包方式都存疑的功能开关服务库，它们完全值得以优雅的方式推倒重做。

我们做事是因为我们需要做

Ruby 和 Rails 应用的另一个典型痛点一直是 gRPC。我还没见过哪个 Ruby 开发者不得不在实际项目中使用 gRPC 却毫无问题。挂起的线程、对 fork 不友好、奇怪的 protobuf 兼容性问题……这个清单可以一直列下去。现在 Samuel 直接动手重做了一个对 Async 友好的 gRPC——因为我们不再受制于“X 公司的大团队在维护这个东西，而他们今年已经被重组了 6 次，没人能搞得清楚”这种约束。我们可以把这玩意儿直接塞进 LLM 的碎木机里，让它帮我们搞清楚，然后按照本该从一开始就采用的方式来做。

Protobuf 是 gRPC 的基础，在 Ruby 世界里也绝非轻松之事。它看起来非常简单，甚至平淡无奇——把几个字节pack成二进制字符串能有多难？

事实证明——你可以把它弄得和你允许团队里接触这东西的 staff/principal 工程师人数一样难。官方的 Ruby protobuf gem 需要原生代码。每条 proto 消息都是一个原生对象的句柄，无法轻易被序列化或分发到另一个进程。内省能力有限，API 也很奇怪。你需要一个单独的包（protoc，即 protobuf 编译器）才能把一个 .proto 文件转换成 Ruby 文件，里面还带着一些样板代码来标明你携带的字段。老实说，对于本质上就是一个 Marshal.dump 的东西来说，这完全是一台过度杀伤的巨型机器——还拖着一大堆原生编译代码。

而原生代码需要编译。还需要为你要支持的多个平台 × Ruby 版本提供 ABI 兼容的预编译 gem。推荐的 Ruby C API 还每个版本都在变。而且它会妨碍 GC，除非你非常非常小心，并且需要细致的 GVL 管理才能保证性能……

我们就该忍受这些，把它当作正常现象吗？那就是下一个目标。如果你也想要——请联系我，我可能有些东西可以让你玩玩。

该死的谎言，但还有统计数据

轶事固然不错，但我想确认我所看到的是否只是我自己时间线上的一个泡沫。于是我去了 ClickHouse 托管的 rubygems 数据集，数了一个非常蠢的东西：在过去十二个月里，有多少 gem 名称首次被占用，对比再往前十二个月。不是下载量，不是版本数——只是“一个在 rubygems.org 上不存在的名字，现在存在了”。

原始数字毫无意义——它包含了几千个被撤回的域名抢注和少数几个每个 API 端点就发一个 gem 的账号——所以所有未被索引的都去掉了，所有来自三个或更少账号的 20 个以上 gem 的前缀家族也去掉了。剩下的是无聊的、有机的、一次性的东西——sidekiq-buffered、schema_reaper、k8s-rails、rspec-hopper。其中截至 2025 年 10 月的一年里大约有 4,600 个，而此后的一年里大约有 8,900 个：多了 1.9 倍。这条线在整个 2025 年大致维持在每月 400 到 500 个，然后从 2026 年 3 月起跳升到每月 800 到 1,600 个。这不是一个斜坡，而是一个台阶。

这就是大家一直在谈论的软件大爆发，它也已经蔓延到我们这个小玩具语言上了。我无法告诉你这些是新面孔还是同一批人正处在状态火热的阶段——数据不知道，我也不知道——但某人需要的东西被封装并发布出来的频率翻了一倍，而不是被“恐惧咒语”一耸肩打发掉。质量如何随你怎么评判——有些是垃圾，有些是herringbone，哪个是哪个由你来定——但到底要不要动手做这个东西的决定，比一年前多出了一倍。这就是我所说的复兴。

没有借口

而且不只是库。性能是一个绝佳的切入点。Sam Ruby 正在做的Roundhouse 交叉编译器工作非常了不起，能通过一些没人认为可能的狂野暴力优化，让我们得到运行更快的应用。Tobi 出手，用原生 Ruby 而非 Rails 重写了 Campfire——Falcon、Ractors、基于 SQLite 的普通模块、字节级完全相同的 HTML——页面服务速度提升了 15 到 27 倍……

而这一切让每个做 Ruby 和 Rails 的人生活得更好，就在今天。不是“等一年后 LLM 追上来”或“等你的 CISO 终于批准 GitHub Copilot”。不是“等几个月后我们把治理策略想清楚”。就是今天。

我们真的可以动手去修那些多年来极其烦人的东西，很快，花相对不多的钱。

我们唯一需要的，就是哪怕只有中等程度的好奇心，而不是等着别人批准。1925 年的柏林没有人等着德皇回来批准卡巴莱——德皇已经退位去了荷兰，而卡巴莱因此更好了。

我们有活要干。他没有：

先生，我已经很有钱了。我最不想要的就是更多客户 😂

August 19, 2026