Rails 之父 DHH 狂吹 Rust 快 150 倍，被开发者翻代码后群嘲

作者 | Tina

“我发自内心地讨厌 Rust。每次看 Rust 代码，我都觉得像有人把酸液倒进了我的眼睛。”

9 月底的 Rails World 2026 上，Ruby on Rails 创始人 David Heinemeier Hansson（DHH）站在台上，把 Rust 称为“过去 40 年里发明的最丑陋的编程语言”。

“如果让人类亲自编写，它就是一种糟糕、糟糕、糟糕透顶的编程语言。要求有血有肉的人类用自己的眼睛承受这些代码，简直毫无人性。”

然而几句话之后，DHH 话锋一转：“但如果我永远不用看这些代码，只需要享受应用快上 30 倍甚至 100 倍，编译出极小的可执行文件，并在不到一毫秒内启动，那我爱 Rust！”

“Agent 喜欢 Rust，这正好形成了完美的分工：我告诉它要做什么，它负责用 Rust 写出来，而我永远不用看那些代码。我很喜欢这种方式。”

两周后，DHH 用一张性能图表进一步证明自己的观点。他让 Agent 将 37signals 的群聊应用 Campfire 分别重写为 Elixir、Go 和 Rust 版本，再与原来的 Ruby on Rails 版本对比。结果中，Rust 几乎横扫全场。仅在加载聊天室页面这项测试中，Rust 就达到每秒 36260 个请求，大约是 Rails 的 150 倍、Elixir 的 50 倍、Go 的 9.4 倍。

DHH 在推文中写道：“没错，Ruby 是最慢的。过去我并不在乎，因为它换来了巨大的生产力和开发乐趣。但如果你已经不再阅读代码了呢？”

这项测试与 37signals 最近的一次重大技术转向有关：DHH 已经开始让 Agent 用 Rust 重写自家产品。

Rails 之父，开始转向 Rust

Basecamp 背后的 37signals 一直是一个重视编程技艺、很少为了赶进度走捷径的团队。DHH 也曾以亲手打磨代码为荣。但在 Rails World 2026 上，他说自己大约在四个月前停止了手工编写代码。

“手工编写代码已经不再是一种具有经济生产力的活动。到今年年底，这种变化将覆盖几乎所有领域、几乎所有程序员和几乎所有公司。”

作为 Ruby on Rails 的创造者和 37signals 的 CTO，他过去二十多年一直是“程序员生产力”和“代码美感”最坚定的拥护者之一。

长期以来，Ruby on Rails 一直被视为“单人开发者框架”：它用约定、抽象和完整的全栈能力，尽可能放大一名程序员的产出，让一个人也能开发和维护完整的 Web 应用。Ruby 的性能并不突出，但它始终拥有一批忠实的拥趸，DHH 就是其中之一。

以前他最喜欢的事情就是使用他最得意的应用 Basecamp 和 Hey 的代码示例来强调 Ruby 的优美，以及讽刺其他语言的丑陋，这个其他语言包括 Rust。

但这次 DHH 的变化尤其让人感到震惊。这位过去长期用 Basecamp 和 HEY 证明 Ruby 与 Rails 优越性的框架创始人，在这场大会上，站在近千名 Rails 开发者面前宣布：HEY 将采用原生客户端，后端也将转向 Rust。

下一代邮件服务 HEY 将不再以 Web 应用为中心，而会为主要操作系统分别开发原生客户端。过去，一支小团队几乎不可能同时维护六款原生应用，只能依靠 Web、React Native 或 Hotwire Native 等方案控制成本。如今，DHH 认为这件事已经从团队规模和开发周期的问题，变成了需要消耗多少 Token 的问题。

前端转向原生应用后，HEY 的后端也不再需要承担 HTML 渲染等职责。37signals 准备将它改造成一个更加纯粹的邮件服务器，并通过 Agentic Coding 使用 Rust 重写。

这个决定让 Rails World 的现场一度陷入沉默。

DHH 并没有宣告 Rails 死亡，但他自己的选择已经表明，开发体验不再是唯一需要优先考虑的因素。运行性能、资源占用、编译结果大小等过去可能为生产力让路的指标，正在重新获得更高权重。

DHH 还给出了新版 HEY 后端的初步数据：CPU 使用量降低了 99%，内存使用量降低了 95%，服务器数量可以缩减到十台，而且保留这些服务器主要是为了冗余。按照团队的粗略估算，一台 Raspberry Pi 甚至可能承担 HEY 后端的全部峰值负载。

而他最新发布的 Campfire 的多语言测试，则直接拿出了一张更加直观的成绩单：Rust 比原来的 Ruby on Rails 版本快约 150 倍。在 DHH 的测试中，Rust 实现轻松胜过其他所有实现，在所有五种工作负载下都表现出色，有时甚至优势明显。

100 万次浏览后，评论区开始翻代码

如今，用 Rust 重写应用程序似乎是一项流行举措，微软的 Copilot 运行时、pnpm JavaScript 安装程序和 Bun JavaScript 工具链都采用了 Rust 进行重写。

DHH 的推文浏览量接近 100 万，但开发者没有顺着 DHH 的思路，讨论是否应该在 Agent 时代重新选择 Rust 编程语言。很多人的第一反应是：这组结果明显不对，几个版本很可能没有站在同一条起跑线上。

Google 工程师 Jaana Dogan 的回应传播最广：“真正让我担心编程未来的是，你看到这样的结果后，居然没有立刻意识到，测试结果或者实际测量的东西肯定有问题。”

虽然 Dogan 没详细解释这项测试具体存在哪些缺陷，但一些其他语言倡导者给出了详细信息。

一名 Elixir 开发者直接把这份实现称为“愚蠢至极”。他指出，Agent 把所有 SQL 查询都交给同一个 GenServer，并通过同步的 GenServer.call 等待结果，相当于让原本可以并发执行的数据库查询排队逐个完成，主动废掉了 Elixir/BEAM 的并发优势。

另外几个人直接重写了 Elixir 代码，使其性能达到与 Rust 相当的水平。重写之后，Elixir 版本在部分任务上的性能甚至超过了 Rust，尽管第三方后来又对 Rust 版本做了进一步优化。

还有观察者指出，与 Go 和 Elixir 实现相比，Rust 重写版在编码完成后得到了多得多的关注。Go 和 Elixir 版本似乎在完成最初的 Agent 请求后，就被匆忙收尾了。

“DHH 比较的，其实是一个经历了 300 次提交的 Rust 版本，以及只有两三次提交的 Elixir 和 Go 版本。”

“300 次对两三次”还只是当时的概括。Jared Smith 随后检查了三个公开仓库的完整记录。截至 10 月 6 日，Rust 版本的 main 分支已经有 398 次提交，Elixir 和 Go 则各自只有 3 次。

Rust 的 398 次提交中，380 次来自 DHH，10 次来自 Abdelkader Boudih，8 次来自 Daniel Collin。其中 397 次集中发生在 9 月 26 日至 10 月 1 日之间。Elixir 仓库只有一次移植提交和两次文档提交；Go 仓库则包含一次移植、一次性能优化和一次 README 更新。

Rust 仓库还有 44 个 PR，其中 39 个已经合并。按照标题统计，已合并的 PR 中有 16 个明确与性能相关，另有两个性能 PR 尚未合并。优化内容包括按房间和时间为消息建立索引、缓存页面的每个部分、使用专用线程读取数据库，以及调用 ARMv8 SHA-256 指令执行哈希计算。

这意味着，Rust 版本经历的远不止一次 Agent 重写。它在六天里不断接受新的性能目标，反复经历测试、发现瓶颈、修改代码和再次测试。Elixir 和 Go 基本停留在 Agent 交付的第一版。

几个 Agent 从一开始收到的任务要求也不相同。

Rust 版本的 AGENTS.md 明确告诉 Agent：“如果这样能让应用更快或者更好，现在可以偏离 Rails 的实现。”它还要求每一项性能改动都提供优化前后的测量数据。

Elixir 版本的主要要求则是“保留固定版本的 Rails 参考实现行为”。Go 版本以已经调优的 Rust 应用为参考，要求保留 Rust 应用的行为。Elixir 和 Go 都没有得到一个必须击败的性能数字，也没有被允许为了速度放弃与参考实现的一致性。

Rust Agent 接到的是一项持续优化任务，Elixir Agent 接到的主要是一项功能移植任务。最后再把几个版本放进同一张性能表里，比较的已经不只是编程语言。

DHH 说对了一半？

争议发生后，DHH 仍然坚持自己的核心判断。

“速度并不是衡量一个代码库时唯一需要考虑的因素。Rust 也有其他缺点，比如编译速度慢。但当 Agent 负责写代码并验证输出时，我们显然需要适应一种新的现实。如果连这一点都看不到，那就真的是把头埋进沙子里了。”

对于在 Elixir 版本中禁止数据库并发读取的质疑，DHH 回应称，自己并没有干预具体实现。他只是要求两个前沿 Agent 尽可能发挥 Elixir 的性能，最终得到的就是这份代码。他欢迎开发者提交 PR 提升速度，同时强调：“如果前沿 Agent 找不到那些让程序‘跑得更快’的神奇开关，这也不能算是 Elixir 的加分项。”

这段回应也暴露了双方对这项测试的理解差异。Elixir 开发者认为，这测试无法反映两种语言的真实水平。但 DHH 关注的则是另一件事：在相同任务下，把代码交给当前最强的 Agent，它们能否自行找到一门语言的正确写法和性能优化方式。

当 Agent 承担大部分编码工作后，语言是否容易书写、代码是否赏心悦目，确实可能不再像过去那样重要。

这恰好触及 DHH 所说的“以后不再阅读代码”。只是如果标准写得不完整，Agent 仍然可能交付一个功能正确却性能糟糕的版本；如果比较条件本身不公平，再精确的数字也会产生误导。

DHH 想用 Campfire 证明：人类不看代码之后，就能绕开 Rust 糟糕的开发体验，直接吃到它的性能红利。可评论区把仓库翻了个底朝天，翻出的却是另一个结论——你可以不写代码，但不能不懂代码。让 Agent 做什么、做得对不对、这场比较公不公平，终究还得人来判断。

https://www.youtube.com/watch?v=vDjW_dRyKXY

https://x.com/dhh/status/2106810173683851564

https://sublimecoding.com/blog/dhh-campfire-benchmark-measured-the-agent

https://www.theregister.com/devops/2026/10/07/rails-originator-roasted-over-rust-boosterism/5301494

声明：本文为 InfoQ 原创，不代表平台观点，也不构成投资建议，未经许可禁止转载。

会议推荐

QCon 全球软件开发大会·2026（上海站）将于 10 月 22 日—24 日举办。本届大会聚焦 Harness AI 时代的工程实践，从「构建 AI」到「驾驭 AI」，围绕 AI Native 架构、Agent Runtime、AI Infra、Agent 安全与可观测、Loop Engineering、具身智能与世界模型 等热门技术方向，邀请全球技术社区与产业一线实践者，共同分享 AI Native 时代最具价值的工程经验。限时 9 折优惠立减 680！查看更多详情可扫码或联系票务经理 18514549229 进行咨询。