Go 和 Rust 谁更适合 AI 编程：验证成本账本解析与选型建议

"Rust is better. It just is."

这是 Hacker News 317 条评论里排在第一的一句话。它针对的是 Google 昨天刚发的官方宣言：Go 才是 AI 辅助软件工程的理想语言。

两拨人吵了一整天。但我们的判断是：这场架两边都吵错了方向——他们算的是「写代码」的账，而你真金白银花出去的，是「审代码」的成本。

这篇文章不站队，只给你三样东西：我们重算的这笔账、按这笔账得出的选型建议、一个今晚就能验证我们说法的对照实验。

▍我们的观点：Google 说对了一半，但账算错了地方

先亮立场。以下是我们的观点，证据在后两节。

Google 说对的那一半：评价语言生产力的标准确实变了。coding agent 几秒钟能生成几百行语法正确的代码，人写代码的速度不再重要，重要的是 review、verify、maintain——瓶颈从 generation 转移到了 verification。这是 Google 全文唯一真正有价值的新框架。

算错的那一半：Google 用这个框架推出的结论是「Go 最理想」。但你只要真的按「审」的标准把账算到底，就得不出这个结论。验证成本由三样东西构成，它们各有赢家：

验证成本要素	赢家	为什么
编译器能在编译期挡掉多少错误	Rust	借用检查器 + 模式匹配穷举，整类错误根本活不到运行时
agent 自我纠错一轮的代价	Go	编译快、报错直接、工具链内置一体，「生成→编译→修」循环最便宜
人 review 的认知负担	Go	只有一种写法，风格统一，人审和模型生成都不费神

所以我们的结论是：「AI 编程的理想语言」是个伪命题，但「验证成本」是真账本。 你的项目里验证成本主要花在哪一项，哪门语言就赢——这才是选型的正确问题。

对 Rust 读者再补一句诚实的：这个号写了几十篇 Rust 教程，但账本第一行有个隐患——如果 LLM 不犯人类那些低级错误，借用检查器防住的东西就会缩水。这一点 HN 评论区有人替我们说了，后面会引到。语言优势的账，到了重算的时候。

▍Google 实际说了什么（以及它没说破的）

Google 这篇文章由 Go 的 Group Product Manager Cameron Balahan 和 Google Cloud Chief Evangelist Richard Seroter 联名发布。抛开立场，它的论据是四条，我们按「验证成本」账本重新归类：

1. 工具链内置一体（对应：自纠错循环代价）。gofmt、测试框架、依赖管理、govulncheck 全在标准工具链里。文章自己也承认一个关键事实：AI agent 在没有外部验证时迭代重构，错误率会复利式累积，污染上下文、烧 token。内置工具链就是给 agent 的廉价校验器。
2. 风格统一（对应：review 负担）。gofmt 强制一种写法，「看不出代码是谁写的」，幻觉出来的 API 调用更容易被人眼抓住。
3. 静态类型 + 编译快（两条账都占）。类型错误编译期拒绝；编译速度原文声称比 Java、C#、Rust「快几个数量级」——注意，这是修辞，不是实测数据。
4. 兼容性承诺 + 静态二进制（长期维护成本）。Go 1.0 的代码今天还能编译，「永远不会有 Go 2.0」；产物是零依赖单文件，交叉编译一条命令。

它没说破的是：这四条论据里有三条，用更强的类型系统可以做到更彻底——编译期挡错误，Rust挡得比 Go 多得多。Google 通篇没有正面回应这一点，HN 评论区替它补上了。

▍HN 317 条评论里，真正值得看的六条

评论区吵成四派，但大部分是水。真正对我们这笔账有增量的，是这六条（引用均已对照原文逐条核验）：

支持「编译期挡错误」值钱的，是 @Havoc：

The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests. Tokens are cheap, surprises at runtime are not.

大意：用 token 砸编译，比猜运行时哪里会炸再写测试去堵划算——token 便宜，运行时的惊吓贵。这正中我们账本的第一行。

支持「循环代价」值钱的，是 @throwitaway222 的实测：「Fewest glitches for AI generated code... Doesn't seem to burn tokens as much as other languages.」AI 生成的 Go 毛病最少、不烧 token。正中账本第二行。

对 Rust 党最有价值的一条警告，来自 @YuechenLi：LLM 不会犯 borrow checker 设计来防的那类人类错误，所以它「spend more time fighting Rust's infrastructure than writing code」。如果这条成立，我们账本第一行的权重就得下调——这也是为什么我们只说「隐患」而不下定论：它还没人被系统验证过，值得你用自己的实验去测。

划出 Go 边界的，是 Go 派自己人 @kstenerud。他夸完工具链（forbidigo 限文件访问、coverage 的 nocover 标记、lint 成熟）之后补了一句：「Rust is better for error paths because you're not allowed to ignore them.」连他都承认，错误路径上 Rust 不允许你忽略错误。

质疑动机的最锋利一刀，来自 @tpoacher：「"Oreo cookies are the tastiest cookies currently in the market!" ~ Oreo cookie company.」奥利奥公司宣布奥利奥最好吃——作者是 Go 的产品经理和 Google Cloud 首席布道师，立场写在工牌上。读原文时记得这一点。

给整场争论收尾的，是 @pianopatrick：「Seems to me the ideal language for AI has not been created yet.」以及 @WalterGR 的发现：五个月前同一话题就吵过一次，203 赞、304 条评论。这场争论是周期性的——下次再看到「XX 语言最适合 AI」，你可以直接套我们的三要素账本。

▍落到选型：我们的建议

按验证成本算账，决策规则其实很清楚：

• 内部工具、网络服务、CLI、标准库能覆盖的场景——选 Go。循环快、token 省、团队审查负担低。HN 实测派的正面报告也全都集中在这类项目。
• 性能敏感、正确性敏感、错误路径不能出事的系统——选 Rust。编译期挡掉的错误最多，代价是 agent 循环更慢、token 更贵。
• 原型、脚本、数据处理——Python 可能仍是 token 效率最高的，@mg 在评论区举了 Dan Luu 的 pl-tokens 测试佐证，这个判断我们持保留态度，但方向合理。
• 任何场景——选你「审起来最不累」的那门，而不是「写起来最爽」的那门。AI 时代，写已经不是你在干的事了。

▍今晚就能做的对照实验

我们的账本对不对，你不用信我们，今晚自己测：

1. 选一个你熟悉的、中等复杂度的需求，比如「实现一个带速率限制的并发任务队列，支持优先级和优雅关闭」。
2. 用同一个 agent、同一个模型、同一段 prompt，分别要求用 Go 和 Rust 实现。
3. 记录四个数：编译运行通过花了几轮对话、总共消耗多少 token、你 review 花了多少分钟、测试一次性通过率。
4. 有条件的话各跑三次取中位数，单次结果噪声很大。

注意边界：这个实验只能回答「对你的项目、你的 agent、你的模型，哪门语言验证成本更低」，不能证明任何语言普适优越。谁拿单次实验结果宣称某门语言全面胜出，谁就在重复 Google 这篇文章的毛病。

▍FAQ

AI 写代码的时代，选语言的标准是什么？

我们的观点：看验证成本——编译器能在编译期挡掉多少错误、agent 自我纠错一轮的代价、人 review 的认知负担。谁让你的验证成本最低，就选谁。

那到底该选 Go 还是 Rust？

看你的验证成本花在哪：内部工具、网络服务、标准库够用的场景选 Go，循环快、token 省；性能敏感、错误路径不能出事的系统选 Rust，编译期挡掉的错误最多。

Google 为什么说 Go 适合 AI？

四个论据：工具链内置一体；风格统一好审查；静态类型加快速编译让自纠错循环便宜；兼容性承诺和静态二进制省心。但它没说破的是：按这个逻辑推演到底，类型系统更强的语言其实更占优。

怎么验证哪门语言对我的项目更合适？

用同一个 agent 和 prompt，分别生成 Go 和 Rust 实现，记录编译通过轮数、token 消耗、review 时长和测试通过率，各跑三次取中位数。单次实验噪声大，且结论只适用于你的场景。

▍资料出处

• Google 官方博文：Cameron Balahan（Go Group Product Manager）与 Richard Seroter（Google Cloud Chief Evangelist）2026 年 8 月 11 日发表于 Google Developers Blog 的《Why Go is an Ideal Language for AI-Assisted Software Engineering》，本文第三节的四条论据出自此文，「比 Java、C#、Rust 快几个数量级」为原文原话。
• Hacker News 讨论串《Go is an ideal language for AI-assisted software engineering》，截至 2026 年 8 月 12 日抓取时显示 270 多赞、317 条评论，本文所有带 @ 的引用均逐条对照原文核验。
• @WalterGR 在评论中提到的前作：Hacker News 讨论串《A case for Go as the best language for AI agents》，五个月前，203 赞、304 条评论。
• @mg 提到的语言 token 效率对比测试：Dan Luu 的《PL tokens》。

▍写在最后

这场争论里，云栈社区上的开发者们吵得同样热闹。有人晒 Go 项目里 agent 一次通过的截图，有人贴 Rust 编译器的报错日志当「防线验收报告」。真实世界的选型从来不是靠立场投票决定的——今晚跑一遍对照实验，把四个数字贴出来，比任何论点都更有说服力。