本文永久链接 – https://tonybai.com/2026/06/18/why-choose-go-over-rust-today-in-ai-age

大家好，我是Tony Bai。

随着 Cursor、Claude Code 和 Copilot 等 AI 编程智能体的爆发，整个技术圈的开发门槛被前所未有地铲平了。

在过去，Rust 最大的劝退门槛是它那极其陡峭的路径——生命周期、借用检查器（Borrow Checker）、复杂的泛型特征（Traits）。但如今，AI 可以轻而易举地帮你写出能够通过编译的复杂 Rust 代码。

这就引发了一个最近在 Reddit 的 r/golang 讨论区的终极发问：“既然 AI 已经帮我们消灭了 Rust 的学习和编写门槛，今天我们为什么还要选择 Go？（Why choose Go over Rust today?）”

海外大厂的资深架构师和 SRE 们纷纷下场，用生产环境中的血泪教训，给出了一个极具警示意义的工程结论：AI 极大地降低了“写”代码的门槛，却无形中成倍抬高了“读”与“维护”代码的成本。而在充斥着 AI 生成代码的时代，Go 语言那近乎固执的“简单与无聊”，反而成为了它最坚不可摧的壁垒。

以下是为什么在 AI 时代，Go 依然是很多企业技术选型终极首选的深层逻辑。

致命的“温水煮青蛙”：谁来在凌晨三点排查 AI 写的代码？

在帖子中，一位获得了极高赞同的资深开发者贴出了一句直击灵魂的忠告：

“如果你打算让 AI 写完所有代码且你从不检查，那么 Rust 是完美的（因为编译器会守住安全底线）……前提是，你是那个在凌晨 3 点值班、随时准备被报警电话叫醒去排查问题的人。”

这句话道出了软件工程中最朴素的真理：编写代码是一时的，而阅读、评审（Code Review）和在线排查（On-Call）才是永恒的。

大模型在生成代码时，为了迎合编译器的规则，往往会采用极其复杂、精妙但难以阅读的“高级语法特性”。

• AI 写的 Rust 代码：可能会充斥着各种复杂的泛型嵌套、宏（Macros）、高度抽象的 Trait 绑定以及微妙的生命周期标注。它确实能通过编译，但当它在生产环境中遇到边界条件发生崩溃时，由于代码不是你写的，面对这堆“天书般的高级 Rust 代码”，你根本无法在短时间内看清它的真实意图。
• AI 写的 Go 代码：由于 Go 语言刻意限制了特性的复杂性，奉行“一种问题只有一种解法”的极简主义。AI 写出来的 Go 代码，看起来和你自己写的、或者你同事写的没有任何区别。任何一个普通的后端开发，都能在 30 秒内梳理清楚数据流向。

在 AI 大规模入侵开发流水线的时代，“易读性”和“低认知负载（Cognitive Load）”成了比“易写性”更重要的资产。Go 的无聊和易读，在这个时候反向成了它最大的护城河。

运行时的隐形深渊：GMP 模型 vs 协作式异步的“雷区”

在涉及到高并发的系统设计时，很多开发者以为 Rust 拥有完美的类型安全（线程安全的 Mutex 检查等），就能在并发上完胜。

但 Reddit 上的多位分布式系统工程师指出了一个极易被忽视的“运行时隐形深渊”：非抢占式并发（Cooperative Async）的惩罚。

1. Go 的“无脑并发”（GMP 抢占式调度）

Go 语言底层的 GMP 调度器支持抢占式调度（Preemptive Scheduling）。

这意味着，即便 AI 给你写了一段“烂代码”（例如在一个 CPU 密集的循环里没有主动让出 CPU），Go 运行时也会在底层强行打断它，把执行权分给其他协程。你的服务可能会变慢，但绝对不会卡死。

2. Rust 的“协作式深渊”（Tokio 异步事件循环）

Rust 的主流异步运行时（如 Tokio）是协作式（Cooperative）的。

这意味着，如果 AI 帮你在一个 async 函数内部偷偷夹带了一句同步阻塞操作（比如调用了一个同步的第三库去读文件或发起网络请求），它会直接霸占并锁死整个事件循环（Event Loop）！

这种低级错误，Rust 那引以为傲的编译器完全无法察觉。在线上高并发场景下，这会导致整个微服务在瞬间陷入死锁状态。

在 AI 辅助开发时代，由于大模型无法完美感知具体的系统上下文，AI 极易在 Rust 的 async 块中引入阻塞调用。这让 Rust 系统的线上隐患比 Go 尖锐得多。

标准库生态 vs 依赖地狱（Crate Hell）

在构建微服务和后端 API 时，Go 的另一个绝对优势是它的 “Batteries included（自带电池）” 哲学。

• Go 的富标准库：Go 拥有世界上最强大、最稳定的标准库。你不需要引入任何第三方包，仅靠标准库就能写出高性能的 HTTP 服务器、完美的 JSON 解析器以及加密服务。这意味着你的项目极其干净，几乎没有供应链安全风险，并且可以无视版本的向前兼容。
• Rust 的极简库与 Crate 地狱：为了追求极致的小体积，Rust 的标准库非常“贫瘠”。写一个普通的 Web 服务，你不得不引入 tokio、serde、reqwest 等一整棵庞大的第三方树（类似于 Node.js 的 node_modules 依赖灾难）。

当项目依赖树膨胀到上百个节点时，不仅编译时间（Compile Times）会变得极其冗长（Rust 本就因为编译慢而臭名昭著），AI 也会因为各个第三方库之间复杂的版本冲突，频繁生成无法通过编译的代码，让开发体验陷入泥潭。

黄金法则：90% 的性能，10% 的心智负担

在经历了一轮轮深刻的讨论后，技术老兵们为我们总结出了一条极其务实的决策黄金法则：

除非你的业务是在写操作系统内核、高频交易引擎、或者内存极其受限的边缘设备；否则，用 Go 来换取 10 倍的开发效率、秒级的编译速度，以及任何人都能在 3天内上手的极低维护成本，在商业世界里永远是一个性价比高得多的选择。

小结

AI 的爆发并没有让“简单”失去价值，反而让“简单”变得更加昂贵。

AI 降低了代码“写”的门槛，但也导致互联网上的平庸同质化代码（Slop）呈指数级爆发。在充斥着 AI 生成代码的未来，能够一眼被看穿、能够被任何人轻松评审、能够无痛维护的代码，才是最稀缺的技术资产。

Go 语言那近乎固执的“无聊”与“克制”，并不是落后，而是其对“人机协同软件工程”最深邃的先见之明。

资料链接：https://www.reddit.com/r/golang/comments/1u2u96q/why_choose_go_over_rust_today/

今日开放讨论：

大模型确实降低了我们“落笔写代码”的门槛，但它同时也以前所未有的速度，向整个世界的代码库里倾倒着似是而非的“平庸垃圾（Slop）”。

面对这场温水煮青蛙的“人机协作大潮”，我们也想听听你在一线最真实的工程感受：

1. 你是否尝试过让 Cursor 或 Claude 帮你生成复杂的 Rust 代码？ 在实际编译和后续维护中，你觉得 AI 究竟是帮你“拆掉了门槛”，还是在暗中给你“挖了更深的坑”？
2. 如果今天你要为团队新立项一个中大型的后端微服务， 在有 AI 编程工具辅助的前提下，你会更倾向于选择“3 天就能上手、编译仅需毫秒的 Go”，还是“心智负担极高、但上限和安全性拉满的 Rust”？
3. 你是否经历过被 AI 生成的“黑盒代码”在半夜三点叫醒 On-Call 的惨痛经历？

欢迎在评论区留下你最硬核的观点，或者把这篇文章一键转发给身边正在为“技术栈选型”纠结的架构师朋友。我们评论区见！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/16/why-if-it-compiles-it-runs-rust-engineering-aesthetics-and-logic

大家好，我是Tony Bai。

在软件工程界，有一句流传甚广、近乎玄学的名言：“如果你的 Rust 代码通过了编译，那么它就已经可以正确运行了。”

对于被 Java 的空指针异常（NullPointerException）折磨得彻夜难眠、被 C++ 的段错误（Segfault）逼到崩溃、或者在 TypeScript 里为处理各种隐式错误而心力交瘁的开发者来说，这句话听起来像是一个过于美好的谎言。

为了探寻这句话背后的真相，在最近的一期访谈中，Google Android Rust 团队成员、Rust 语言团队顾问、高并发异步运行底座 Tokio 的核心维护者 Alice Ryhl，深度拆解了 Rust 的底层设计。

从一个在高中为了写《我的世界》（Minecraft）模组而自学 Java 的少女，到在 Rust 官方论坛上累计解答 10,000 个问题的硬核专家，Alice 用她极具说服力的工程视角，为我们揭示了 Rust 是如何通过极致的编译器设计、数据结构约束以及民主化的社区治理，彻底改变现代软件工程的。

终结“十亿美元的错误”：Rust 怎么保证代码的绝对可靠？

大模型时代，写代码的门槛越来越低，但系统的可靠性却变得前所未有的脆弱。Alice 认为，要让一门语言写起来有“编译即正确”的底气，最核心的底座是其类型系统。

1. 彻底消灭 null 隐患

1965 年，图灵奖得主 Tony Hoare 发明了 null 引用，后来他痛苦地称其为自己的“十亿美元错误”。在 Java 中，每一次函数调用，你都必须时刻提防它可能返回一个 null，进而导致程序崩溃。

而在 Rust 中，null 这一概念根本不存在。

如果你需要表达一个变量可能为空，你必须显式地使用 Option 枚举。最关键的是：编译器会用铁律强迫你在使用该变量之前，必须进行解包和空值检查。 你无法偷懒，更无法遗忘，因为漏掉任何一种可能，编译器都会拒绝通过。

2. 显式且不容忽略的错误处理

与 Java 或 C++ 依赖隐式垃圾回收或异常抛出（Exceptions）不同，Rust 采用了一种极其务实的做法：将错误作为普通的值返回。

// Rust 中的经典错误处理模式
let file = File::open("config.json")?;

这里的 ? 操作符是 Rust 的标志性设计。它意味着：如果打开文件失败，立刻将错误向上抛出。如果你忘记写这个 ?，或者没有对返回的 Result 进行处理，编译器就会报出一个无法忽视的错误。

这里体现的 Rust 的工程美学在于：它不依赖开发者的细心和自律，而是用编译器的钢性约束，把所有可能在生产环境中暴雷的隐式错误，提前在开发期彻底榨干。

妙到极致的“文档即测试”（Doc Tests）

你是否经历过这样的绝望：接手一个项目，按照 README 里的示例代码复制粘贴，结果编译报了一堆错——原来代码重构了，但写文档的人忘了更新示例。

在 Rust 中，这个问题被一个近乎艺术级的设计解决了：文档即测试（Doc Tests）。

在 Rust 中，只要在代码前使用三个斜杠 ///，就可以为函数编写 Markdown 格式的文档：

/// 这个函数将两个数字相加。
///
/// # Examples
///
/// ```
/// let result = my_crate::add(2, 2);
/// assert_eq!(result, 4);
/// ```
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

当你运行 cargo test 时，Cargo 会自动提取你文档注释中的所有代码示例，并把它们作为单元测试全部跑一遍！

如果你的代码发生了重构，导致文档里的示例代码跑不通了，你的整个 CI/CD 构建流就会直接宣告失败。这种设计逼迫开发者：要想代码通过编译，你的文档和示例就必须永远保持最新。 这种对代码 hygiene（工程卫生）的极致追求，让 Rust 成了开源界文档质量最扎实的生态。

新手的终极撞墙期：不要修改代码，去修改你的数据结构！

每一个从 TypeScript、Java 或 Go 转型到 Rust 的开发者，都经历过一段极其痛苦的时期——被“所有权（Ownership）”和“借用检查器（Borrow Checker）”无情蹂躏，俗称“与借用检查器肉搏”。

Alice 指出，几乎所有新手在这个阶段都犯了一个根本性的方向错误：他们试图通过不断修改局部代码逻辑来通过编译，而真正的解法往往是修改数据结构（Struct）。

1. 循环引用的噩梦

在 TypeScript 里，我们建一个“书（Book）”和“页面（Page）”的对象，习惯于让 Book 引用 Page，同时让 Page 也引用回 Book：

Book  ──────>  Page
  ▲              │
  └──────────────┘

这种循环引用在有垃圾回收（GC）的语言中很常见。但在 Rust 这种没有 GC、依靠变量作用域结束自动释放内存的语言中，循环引用会导致内存释放链条死锁（编译器不知道该先释放谁，容易造成内存泄露或双重释放）。

2. 金科玉律：“改变数据结构，而不是改变代码”

当你在 Rust 中遇到借用冲突时，正确的思路是：

• 消除循环引用：将数据结构重构为清晰的、无环的有向无环图（DAG）或树状结构（Tree）。
• 利用引用计数：如果一个对象确实需要在多个地方共享所有权，不要强行用引用，改用引用计数指针 Arc（Atomic Reference Counted）。

通过调用 Arc::clone(&my_obj)，你可以安全、轻量地在多线程中共享同一块只读内存。当最后一个 Arc 离开作用域时，内存会自动被安全释放。

写 Rust 会强迫你在落笔之前，先在脑海中画出极其清晰的数据所有权图谱。这种高强度的架构思考，正是“编译通过即安全”的底气来源。

揭秘 unsafe 的真相：它不是后门，而是高级特权的封装

对于 Rust 的批评者来说，unsafe 关键字经常被拿来作为攻击的靶子：“既然 Rust 声称安全，为什么还留了 unsafe 这个后门？”

Alice 对此给出了极其严密的工程解释：unsafe 绝不是用来关闭编译器检查的后门，它是一个用于向语言注入全新特权的封装箱。

1. unsafe 关不掉借用检查器

一个普遍的误区是，在 unsafe 块里，你可以为所欲为。

事实是：在 unsafe 块中，借用检查器依然在严密工作。unsafe 仅仅是允许你多调用几个被标记为 unsafe fn 的特殊函数，或者操作原始指针（Raw Pointer）。

2. 极致性能与安全边界的统一

在普通代码中，你访问数组元素 vector[5]，编译器会在运行时默默检查数组长度，防止越界崩溃。但如果你在写追求极致性能的音视频解码器，或者在写 Linux 内核驱动，这种运行时的边界检查（Bounds Check）积累起来会产生无法接受的开销。

此时，你可以调用 get_unchecked(5)，它是一个 unsafe 函数，会直接跳过长度检查，直接去读内存。

// 只有在确定不越界的前提下，包裹在 unsafe 中以提升极致性能
unsafe {
    let value = my_vector.get_unchecked(5);
}

3. 用“安全的 API”封装“不安全”

Rust 的核心哲学是：你可以在底层用 unsafe 制造一个高效率的基础构件（比如 Vector 容器的底层实现就是基于原始指针分配和释放），但你必须用极致私有的字段和严密的公共 API，把它包裹成一个绝对安全的、暴露给外部用户使用的安全接口。

只要你的 API 设计无懈可击，外部调用者无论写出多么愚蠢的代码，也绝对无法突破这道安全的封装线。这就是为什么在企业后端开发中，你的业务代码中 unsafe 的使用率应当为 0%。

民主化的工程奇迹：没有“独裁者”的团队是如何高效演进的？

不同于 Python 或 Linux 内核拥有创始人（如 Linus Torvalds）作为“终身仁慈独裁者（BDFL）”来进行终极仲裁，Rust 语言的治理是一个彻底去中心化的、基于共识和提案的民主体系。

这个体系主要由两个精妙的工程机制驱动：

1. 极其严苛的 RFC（Requests for Comments）模版

当你想给 Rust 增加一个稍微大一点的特性时，你必须提交一份 RFC 提案。这个提案的模版极其考验作者的工程思维，其中有两个非常天才的设计：

• Guide-level explanation（引导级说明）：你必须假设这个特性已经存在，写一段像新手教程一样的指南来介绍它。这逼迫提案者从用户体验和易用性的角度去审视特性，而不是一上来就堆砌底层实现细节。
• Reference-level explanation（参考级说明）：详细的技术规范，相当于语言参考手册的起草。
• Alternatives & Prior Art（替代方案与先验艺术）：你必须写清楚为什么不采用另外几种设计，以及 C++、Go 等其他语言在这一块是怎么做的。这能让你在被别人质问之前，先在文档里把所有漏洞堵死。

这种 RFC 流程类似于亚马逊（Amazon）推行的 PR/FAQ 撰写机制，它确保了每一项进入语言的特性，在写第一行编译器代码之前，就已经在逻辑和易用性上被推敲到了极致。

2. 解决破坏性更新的“版次（Edition）”机制

当一门语言发展到一定阶段，难免需要引入破坏性更新（Breaking Changes），比如增加新的关键字。Python 从 2 升级到 3 导致了整个生态长达数年的割裂，至今仍是社区的隐痛。

而 Rust 发明了 版次（Edition） 机制，完美解决了这一难题：

• 编译器的包容性：不同 Edition 的包（Crates）可以在同一个项目中完美混用。
• 无缝兼容：你的底层库可以用 2021 版次编写，而我的主业务可以用 2024 版次调用它，编译器在底层会把它们无缝融合成统一的二进制程序。
• 语法平滑过渡：大版本更新（如引入 async/await 关键字）只在特定的 Edition 里生效，旧 Edition 的代码中依然可以安全地将 async 用作普通变量名。

这种精密的后向兼容机制，确保了 Rust 既能保持激进的技术进化，又绝对不会把老用户丢在半路上。

小结：从“写完代码再调试”到“在安全网中优雅降落”

在 Alice 的工程世界里，写 Rust 并不是在追求一种虚无的技术时尚，而是在实践一种将人的主观失误降到最低的现代工程学。

Rust 并不是万能的，在 Web 前端等需要快速试错、频繁变更界面的场景中，它显然不如 TypeScript 轻量和灵活。但只要你的业务涉及到高并发的后端、高可用的微服务、极致性能的系统底层，或者不容许有任何安全漏洞的防御性工程，Rust 就是目前人类技术栈中最坚固的防线之一。

写 Rust 的过程，是一次编程习惯的洗礼：

你不再需要战战兢兢地把代码部署上线，然后盯着监控屏幕祈祷不要发生内存泄漏；你是在编译器的细心呵护下，将所有已知的安全隐患和逻辑死角在开发阶段一扫而空，然后在类型系统的安全网中，优雅、从容地平稳降落。

而这，正是“编译通过，即可运行”这句工程神话背后，最朴素也最震撼人心的底层逻辑。

资料链接：https://www.youtube.com/watch?v=q9xD36NCtZ8

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/13/linux-maintainer-greg-kh-switched-to-rust-after-35-years-of-c

大家好，我是Tony Bai。

在开源软件的宏大版图中，Linux 内核无疑是那座最古老、最庞大、也最不容有失的钢铁巨塔。它由数千万行 C 语言代码铸就，运行在世界上每一个数据中心、每一台智能手机，乃至公司的投影仪和麦克风里。

在这个由 C 语言统治了三十多年的“神圣领域”，任何关于引入新语言的提议，都曾被视为不可理喻的异端。

然而，巨变正在悄然发生。

在最新一期的 Rust in Production 播客中，两位行业殿堂级人物坐在一起，进行了一场载入 Linux 史册的对话，揭示了 Linux 内核史上最伟大的语言融合：

• Greg Kroah-Hartman：Linux 内核核心维护者，掌管着驱动核心（Driver Core）、USB、TTY 以及所有稳定版本（Stable Kernels）的发布，写了 35 年 C 语言的绝对骨灰级老炮。
• Alice Ryhl：Google Android Rust 团队成员，高并发异步运行时 Tokio 的维护者，将 Rust 引入 Linux 内核的主力军。

在这场深度对话中，Greg 坦言自己曾是一个坚定的“Rust 怀疑论者”，但现在，他不仅公开宣布 “Linux 引入 Rust 的实验已经结束，它已经是正式项目”，更说出了一句让无数技术人动容的话：

“Rust 让我觉得，写程序重新变得有趣了。”

为什么一个掌控着世界底层算力命脉的 C 语言守护神，会被 Rust 彻底征服？在 Linux 这个极致复杂的系统级工程里，Rust 究竟带来了怎样的化学反应？

信任的重构：代码可以出错，但我们必须信任你

在 Linux 内核这样不容许任何安全妥协的底层项目中，引入一门新语言，最大的挑战是什么？

Alice 和 Greg 给出了同一个反直觉的答案：最大的挑战不是技术，而是社会学（Social Challenge）。

“内核的运转，本质上是基于对‘人’的信任。”Greg 解释道。

在 Linux 社区，每天都有几千名开发者提交补丁。资深维护者们并不指望任何人写出完美无缺的代码，因为“我们都会犯错”。

“我们信任你，不是信任你的代码不会出错；而是信任当代码出错、系统崩溃时，你会守在电脑前把它修好。”

在过去的二十年里，有很多系统编程语言（比如 C++）曾试图叩开 Linux 内核的大门，但它们的倡导者写完代码就走了，没有人愿意留下来承担那份沉重、枯燥的长期维护责任。

而 Rust 社区的先驱们用了整整 8 年时间，在内核树外（Out of tree）默默编写驱动、完善基础设施，用实际行动向 Greg 这样的内核守门人证明：“我们不仅能写出安全的代码，而且我们做好了准备，会留在这里和你们一起修 Bug。”

正是这种长期主义的务实精神，建立起了难能可贵的信任（Trust）。

奇妙的化学反应：Rust 的到来，竟然让原有的 C 代码变好了！

当 Rust 真正开始深入内核的毛细血管时，发生了一个极其奇妙、甚至带有一丝讽刺意味的现象：即使你完全不碰 Rust 代码，原本的 C 语言代码也因为 Rust 的到来而变得更好了。

Alice 分享了她们在编写绑定（Bindings）时的技术细节。在 C 语言中，一个指针的定义往往是极其模糊的：

// C 语言中的经典指针返回
struct device *get_device_info(void);

这个指针返回后，调用者需要面对一系列拷问：

• 这个指针代表的是“所有权（Ownership）”的转移，还是仅仅是一次“借用（Borrow）”？
• 它指向的内存在生命周期结束时，是由我来释放，还是由系统释放？
• 它是可变的（Mutable）还是只读的？

在 C 语言的签名里，这些信息全部是缺失的，只能靠开发者查阅文档、或者在脑海里默默推理。

但当 Alice 试图为这段 C 代码编写 Rust 包装器（Wrapper）时，由于 Rust 编译器的强制要求，她们必须在 Rust 签名中明确定义：它是 Arc，是 Box，还是一个简单的引用（Reference）？

为了让 Rust 编译器满意，Rust 团队不得不去倒逼 C 语言维护者厘清这些指针的语义。

“在很多地方，写 Rust 绑定的开发者需要写几百行复杂的代码，就为了兼容某个极其难用的 C 语言接口。”Greg 笑着回忆道，“我看到后说：‘其实我们可以直接修改 C 语言代码，让它变得更简单。’ 那些写 Rust 的人惊呼：‘噢，原来还可以这样！’”

“即便 Rust 在今天突然消失，Linux 的 C 语言代码库也因为 Rust 曾经来过，而变得比以前安全、清晰、健壮得多。” 这是 Greg 给出的极高评价。这种跨语言的协同审视，正在洗礼整个 Linux 内核的工程素养。

纠正偏见：为什么写“驱动”比写“内核核心”难得多？

在很多开发者的刻板印象中，写底层的内核核心（如调度器、内存分配器）是最难的，而写外围的“驱动（Drivers）”是最简单的。

Greg 站出来彻底纠正了这个偏见：“在内核中，写驱动才是最难的。因为驱动虽然看起来是树叶，但它在疯狂地消费整棵树干的养分。”

Alice 在为 Android 编写 Rust 驱动时，深刻体会到了这一点。一个驱动为了运转，必须去调用内存分配（Alloc）、调用 I/O 模块、调用网络包分析、调用文件系统。这意味着，你要写一个 Rust 驱动，你就必须先把这所有涉及到的 C 语言核心模块，全部写出对应的 Rust 绑定。

1. 为什么不能用标准的 Rust 内存分配器？

很多人问，为什么不能直接用 Rust 标准库里的 alloc？

因为 Linux 内核的内存分配（malloc）绝非易事。它不是简单的“要一块内存”，而是充满了极其细微的上下文提示（Gfp flags）：

• “在中断上下文中，不能睡眠，请立刻给我内存”；
• “不要去触发 I/O 写入，直接从那个特定的 NUMA 节点上拿内存”；
• “从这个特定的内存池（Memory Bucket）里分一块给我”。

为了满足这些变态的底层硬件级要求，Rust 用户态标准库那一套内存分配器根本无法工作。Rust for Linux 团队不得不完全剥离了 std，甚至重写了适用于内核特性的定制版 alloc 库。

2. 极致的极客工具：Klint 与编译期“禁眠”检查

为了解决这些极其精细的内核场景，内核团队甚至编写了专属的编译器插件——Klint（Kernel Lint）。

在内核开发中，有一个铁律：在持有某些特定锁或处于中断上下文时，绝对不允许发生系统休眠（Sleep）。如果 C 程序员犯了这个错，系统往往会直接卡死、甚至死机，极难调试。

而 Klint 作为一个 Rust 编译器插件，能够利用编译期的类型系统，在编译时直接扫描整个代码路径，一旦发现你在不允许睡眠的上下文中调用了任何可能触发睡眠（Sleep）的函数，直接报编译错误！

这种在编译期就把低级内存与调度错误彻底掐灭的能力，是传统的 C 语言静态分析工具（如 Coccinelle）在不破坏代码可读性的前提下，永远无法企及的高度。

释怀：35 年 C 老炮被 Rust 治愈的瞬间

当主持人问及，C 程序员能从 Rust 身上学到什么时，Greg 的回答没有滔滔不绝的说教，反而充满了真诚与坦然。

“过去，当我写 C 语言时，如果要在两个模块间传递一个指针，我必须在脑海里进行高强度的思想斗争：这个指针是谁在持有？生命周期对不对？我有没有在别处释放它？”

“当我接触到 Rust 之后，我发现，Rust 帮我把这些繁琐、痛苦、容易出错的 meta-stuff（元认知开销）全部承担了。”

“编译器编译通过了，逻辑看起来也是对的。好了，我现在可以百分之百地把精力放在我的业务逻辑本身，而不需要去担心那些低级的内存越界和空指针问题。”

“写了 35 年的 C，Rust 让我重新觉得，编程是一件纯粹且快乐的事情。”

这或许是一个程序员，对一门新编程语言所能表达的最高敬意。

小结

在对话的最后，现场响起了经久不息的掌声。

Linux 的伟大，不在于它用了 30 多年的 C 语言，而在于它拥有一个极其开放、务实且充满活力的工程文化。当有更好的工具出现时，这些掌控着世界算力命脉的守护者们，没有抱残守缺，而是选择张开双臂，去拥抱改变。

从 Python 狂飙的 AI Agent 调度层，到 Go 统治的云原生 Agent编排底座，再到 Rust 正在接管的 Linux 内核最深处——无论上层的应用和模型如何演进，底层的系统工程（Systems Engineering）依然需要人类最顶尖的逻辑、同理心与工匠精神去雕琢。

我们有幸见证这场跨越语言与时代的融合，更有幸与这些伟大的建设者们同行。

资料链接：

• https://corrode.dev/podcast/s06e04-rust4linux/
• https://www.youtube.com/watch?v=HM-JM4DoYD4

今日开放讨论：

Greg 提到“Rust 绑定的过程，反过来倒逼并简化了 C 语言的原生接口”。在你的项目或日常重构中，是否也曾因为引入了更严苛的约束（如类型系统或静态检查），反而帮助你理清了原本混乱的业务逻辑？

欢迎在评论区分享你的跨语言协作与架构重构故事，我们一起聊聊代码的纯粹之美！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/12/zig-father-refuses-funding-bans-ai-why-no-1-0-in-a-decade

大家好，我是Tony Bai。

在技术圈，有一门名为 Zig 的系统级编程语言，它没有铺天盖地的营销，没有背后财大气粗的金主干爹，甚至它的代码仓库在 2025 年末从 GitHub 直接“硬核跑路”到了 Codeberg。

然而，在 JetBrains 发布的“最受敬仰编程语言”榜单中，它赫然位列 Top 5；Uber 用它的编译器解决 Go 的交叉编译难题；大热的 JavaScript 运行时 Bun 用它作为底层的胶水语言（注：近期Bun已经从Zig迁移为Rust实现）；金融级数据库 TigerBeetle 更是基于它实现了比传统方案快上千倍的性能。

为什么在拥有了 C++、Rust 和 Go 之后，世界依然需要 Zig？

最近，JetBrains 团队对 Zig 之父 Andrew Kelley 进行了一次深度专访。在长达一个多小时的访谈中，Andrew 展现出了极度“反主流”的极客态度：坚决抵制 AI 生成的代码（No-AI Policy）、宁可拿 67 万美元的非营利基金也不要上亿美元的投资、10 年不发布 1.0 版本。

今天，我们就来深度扒一扒，这位被称为“最硬核系统语言创造者”背后的狂人哲学。

缘起：“我能比 C++ 做得更好，我也能比 Rust 做得更好”

故事要从一个开发“数字音频工作站（DAW）”的失败尝试说起。

在 2015 年之前，Andrew 试图用各种现有的语言去开发一个专业的 DAW 软件。

• JavaScript？ “太高层了，根本接触不到计算机底层能力来做低延迟处理。”
• Go？ “和 C 库的交互极其痛苦（CGo），而且垃圾回收（GC）在实时音频处理中是致命的。哪怕卡顿一毫秒，在现场演出中都是灾难。”
• Rust（1.0 之前）？ “我为了让字体渲染工作花了一个月，被 Borrow Checker（借用检查器）折磨得生不如死。稍微改动一点代码，就会引发一连串的编译错误，让我彻底卡壳。”
• C++？ “刚开始感觉很高效，但很快，一个小拼写错误就导致了内存损坏（Memory Corruption），花了我几个星期去 Debug。这太慢了！”

即使退回到只用极简 C++（搭配 C 链接器），他依然在不断地“搬起石头砸自己的脚”。

那一刻，年轻的 Andrew 迸发出了极大的傲慢与决心：“我可以做得更好！我可以比 C++ 做得更好，比 Rust 做得更好，比 Go 做得更好！”

于是，Zig 诞生了。

为什么世界还需要 Zig？它凭什么挑战 C 和 Rust？

很多人会问：C 语言统治了底层 50 年，Rust 现在红得发紫，Zig 凭什么挤上牌桌？

Andrew 给出了一个极其精准的定位：“在 Zig 中，你不需要像在 Rust 中那样为了迎合编译器的‘类型理论’而去扭曲你的代码结构；在 Zig 中，你思考的是‘我希望 CPU 做什么’，然后你写出让它这么做的代码。”

1. 为什么它是更好的 C？

“想要替代 C，你不能放弃任何 C 拥有的能力。”Andrew 说道。

Go 放弃了底层的绝对控制权换取了并发的便利，所以 Go 永远无法替代 C 写操作系统内核。

但 Zig 做到了。在 Zig 中，一切都可以像 C 一样高效，但消除了 C 语言海量的“坑（Footguns）”。甚至在细节上，Zig 比 C 更像 C：C 语言只有溢出（Wraparound）的无符号整数，而 Zig 允许你精细控制整数的溢出行为和符号约束。

2. 为什么它不同于 Rust？

Rust 的核心是其宏大的类型系统和基于生命周期/借用的内存管理模型（类似 RAII）。

而 Zig 走的是“显式分配器（Explicit Allocators）”的路线。

在 Zig 中，没有隐式的内存分配，开发者经常针对特定应用使用 Arena Allocator（一次性分配，一次性销毁），以获得极低的延迟和极高的吞吐量。TigerBeetle 数据库就是利用这一点，在启动时预先分配好所有内存，此后运行时零动态分配（Zero Dynamic Allocation），从而实现了恐怖的高频交易性能。

3. 杀手锏：全宇宙最强的 Toolchain

如果你问一个开发者，在 C/C++ 项目里最痛苦的是什么？99% 的人会回答：配置构建环境（CMake、Makefile、装依赖）。

Zig 的杀手锏在于它的工具链：它没有任何外部依赖。 无论你在什么操作系统上，想要编译一个项目，永远只需要一句 zig build。不仅如此，Zig 甚至可以作为一个超级强大的 C/C++ 交叉编译器。Uber 就是用 zig cc 来解决 Go 语言中混合 C 代码在 ARM 架构上的交叉编译难题的。

“AI 代码全是垃圾”：为什么 Zig 坚决封杀 LLM 提交？

在这个“万物皆可 AI 编程（Vibe Coding）”的狂热时代，Andrew 和 Zig 社区制定了一项极其强硬的规则：严禁任何由大模型（LLM/AI）生成的 Issue 和 Pull Request。

为什么这么刚？Andrew 的回答充满了工程师的辛辣与无奈：

“因为那些贡献无一例外，全是垃圾（Invariably garbage）。”

Zig 的核心团队只有 5 个人，却要面对海量的社区贡献。开源项目接受 PR 的核心目的不仅仅是为了拿代码，更是为了“导师制（Mentorship）”——通过 Review 代码，培养出下一代的核心维护者。

但在 Andrew 看来，那些用 AI 批量生成代码然后扔过来的贡献者，不仅没有任何价值，还在疯狂消耗核心团队极其宝贵的 Review 时间。

“这就像是‘贡献者扑克（Contributor Poker）’。用 AI 的人永远只是路过，他们学不到任何东西，也永远不可能成为核心团队的一员。更可笑的是，他们往往只是把报错信息贴回 ChatGPT，然后假装自己修复了问题。这纯粹是在浪费所有人的时间。”

面对满天飞的“AI 编程神器”，Andrew 有着自己极其古典的软件信仰：

“我想要软件拥有‘绝不妥协的完美（Uncompromising perfection）’。我不想看到一个软件仅仅是因为‘出乎意料地没有 Bug’而沾沾自喜，那是一个糟糕透顶的质量标准。”

$670K 的独立基金与 $100M 的诱惑：为什么拒绝做大？

在科技圈，一个流行的开源项目很快就会被大厂收编，或者拿到顶级 VC 的上亿美元融资，然后迅速扩张。

但 Zig Software Foundation (ZSF) 走了一条截然不同的路。它是一个注册在美国的 501(c)(3) 非营利组织。2024 年，整个基金会的总收入只有区区 67 万美元（约合人民币 480 万）。

在这 67 万美元中，Andrew 为自己定下了 15.4 万美元的年薪（相当于纽约一个普通的资深程序员薪水），而剩下的资金的9成以上，全部用来支付另外几位兼职和全职的外包核心开发者。

当主持人犀利地问道：“如果一家大公司给你 1 亿美元的无条件赞助，你会要吗？”

Andrew 的回答展现出了极度的清醒：

“我会拿，但我会把它存进银行，确保我们未来 100 年都不需要再到处筹款。但我绝不会用这笔钱去扩张。我不想管理 100 个人的团队。”

他的逻辑极其自洽：保持一个极度精简、高效的微型组织，能够最大程度地抵御资本的腐蚀（Oxidation）。

“我们不是初创公司，我们没有投资人在背后催着我们变现。如果我们拿了大厂的钱，他们就会有控制权；现在，我们靠着多元化的小额赞助和少数企业的资助活着。如果哪天某个赞助商说‘你必须按我说的做’，我们可以硬气地回答：‘对不起，如果你撤资，我们依然能活下去。’”

这就是他宁可手写报税单，也要死守非营利基金的底层原因——他要为 Zig 争取“对世界说‘不’”的自由。

硬核的代价：离开 GitHub，以及那遥遥无期的 1.0

为了这份独立和自由，Andrew 付出了很多代价。

2022 年，他退出了 Reddit 和 Twitter。2025 年底，当发现 GitHub 的持续集成（CI）服务器对 Zig 极度不稳定时，他更是做出了一个惊世骇俗的决定：将 Zig 的主仓库从 GitHub 彻底搬迁到了一家德国非营利组织运营的平台 Codeberg。

这意味着他主动放弃了 GitHub 带来的巨大流量和打赏（Sponsors）收入。但他毫不在意：“我们是来写软件的。如果 CI 跑不通，我们就换一个能跑通的。Codeberg 是非营利组织，比那些为了下一个财报季奔波的创业公司靠谱多了。”

那么，被粉丝催了 10 年的 Zig 1.0 究竟什么时候出？

Andrew 坦言，1.0 本质上是一个“向后兼容的承诺”。像 Go 这种语言，1.0 之后很久没动过语法；而 Rust 虽早早发布 1.0，却靠着 Editions（版次）机制继续大改特改。

“我们不需要为了迎合风投的胃口，或者为了所谓的‘商业落地指标’去急匆匆地发布 1.0。当 Zig 1.0 发布的那一天，它必须是一份‘毫不妥协的热爱之作’。我们不需要为任何仓促的糟糕决定买单。”

不过，Andrew 也在采访中透露了一个彩蛋：他将全力冲刺即将到来的 0.16 版本 (注：截至发稿时，Zig官网已经发布了0.16.0版本)。在这个版本中，完全摆脱对 LLVM 依赖的自研 x86 后端将迎来爆发——百万级代码库的增量编译将低至恐怖的 50 毫秒！

小结：程序员的乌托邦

在访谈的最后，当被问及“未来 20 年人类还会写代码吗”，Andrew 的眼中闪烁着光芒：

“人们永远不会停止写代码，因为写代码真的太好玩了。”

在他看来，当今世界最好的软件，往往是开发者们在业余时间出于热爱而写的。而那些为了商业目的强加给用户的软件，总是充满了广告、诱导和恶意的参与度指标。

Zig 不仅仅是一门编程语言，它是 Andrew Kelley 献给世界的一份“无条件的礼物”。它在向所有热爱底层、渴望掌控计算机的极客们宣告：

在这个被大厂垄断、被 AI 噪音填满的世界里，我们依然可以凭借几百 K 的预算、五六个人的小团队，用对技术的极致纯粹，造出一把劈开混沌的利剑。

如果你也曾在这个庞大的系统工程世界里感到过疲惫与迷茫，不妨去试一试 Zig 吧。那是一片没有资本催促、没有 AI 噪音的，属于纯粹程序员的乌托邦。

资料链接：https://www.youtube.com/watch?v=iqddnwKF8HQ

✍️ 今日开放讨论

在这个几乎所有人都疯狂拥抱 AI 编程（Claude Code/ Codex /Antigravity Cli等）的时代，Zig 官方明确拒绝 AI 生成的 PR。你认为是 Andrew Kelley 过于“迂腐”，还是他在守护开源软件最核心的“导师制与高质量传承”？

欢迎在评论区留言，分享你对“AI 垃圾代码”以及系统编程语言发展趋势的看法！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/11/writing-idiomatic-go-make-you-better

大家好，我是Tony Bai。

在技术圈里，Go 语言（Golang）一直扮演着一个特立独行、甚至有些“格格不入”的角色。

如果你去问一个写 Java、Python、TypeScript 或是 C++ 的程序员对 Go 的第一印象，得到的回答大概率是：“无聊”、“简陋”，以及无处不在的 “冗余样板代码（if err != nil）”。它没有优雅的异常捕获机制，早期坚决不引入泛型，更把面向对象最核心的“类继承”给无情斩断了。

然而，在技术社区 Reddit 的 r/golang 板块中，一个极其深刻的问题引发了全网热议：“写地道的 Go 语言（Idiomatic Go），是否让你成为了一个更好的整体开发者？”

令人惊讶的是，那些在业界摸爬滚打多年的大厂架构师、技术主管和多语言老兵们，几乎给出了高度一致的肯定回答。

Go，这门刻意在语法上“自我阉割”、拒绝一切魔法和花哨抽象的语言，究竟是如何反向输出、重新格式化一个程序员的底层智力结构的？在这篇文章中，我们就一起来盘点一下。

显式错误处理：从“假装看不见异常”到“直面毁灭的工程意识”

每个刚开始写 Go 的开发者，最难以忍受的就是地道 Go 语法里近乎强迫症的错误处理：

val, err := DoSomething()
if err != nil {
    return fmt.Errorf("failed to do: %w", err)
}

很多人抱怨：“为什么我非得在每一行可能出错的代码下面，写这三行废话？”

但在 Reddit 的高赞回复中，一个资深开发者从系统设计的层面一针见血地指出了真相：“基于异常（Exception-based）的语言，给我们制造了一种‘异常被完美控制’的幻觉。这其实是极不负责任的。”

在 Java 或 Python 中，当你调用一个可能失败的函数时，你的业务控制流是隐式的。你抛出一个异常，寄希望于上层某个魔妙的 try-catch 块能抓住它。

但实际情况往往是：开发者为了代码的“清爽”，假装看不见潜在的失败，直到生产环境爆出未捕获的运行时异常（Runtime Exception），导致系统崩溃。

而地道的 Go 语言通过返回 (Value, error) 的双元组，逼迫你和错误进行面对面的正面刚：

• 在每一个可能失败的节点，你都必须立刻、就地做出决定：是包装错误返回？是降级重试？还是优雅地熔断？
• 你开始把“失败（Failure）”视为系统运行的常规状态，而不是需要恐慌的意外。

许多开发者表示，在适应了 Go 的显式错误处理后，他们回去写 Python 或 TypeScript 时，再也不敢盲目依赖全局异常捕捉了。他们会主动用元组（Tuple）或类似 Result 的结构，在调用点显式解包。这种对错误的敬畏和就地处理的工程意识，是成为高级后端架构师的第一步。

拒绝抽象过载：Go 的“传染性极简”如何治好你的架构妄想症？

很多程序员在拥有了 3 到 5 年的开发经验后，极易患上一种名为“过度设计（Over-engineering）”的职业病：一看到业务需求，本能地就想套用几十种设计模式、建十几层继承树、引入各种高级的元编程和装饰器魔术。

而 Go，是这种“架构妄想症”的特效解毒药。

一位Reddit 用户分享了他的经历。在写了一段时期的 Go 之后，他回过头去写 Python：

“天啊，我突然发现有 5 种完全不同的方法去遍历和操作一个数组。我开始陷入无谓的选择困难和审美疲劳。我突然开始怀念 Go 那种‘只有一种最笨、最直接的写法’的无聊感。”

Go 语言在设计之初，就故意将语言特性压缩到了极致。它没有隐藏的控制流，没有神奇的操作符重载，没有复杂的类继承。

这种“无聊”逼迫你放弃在代码形式上炫技，转向思考最本质的问题：

• 这个逻辑能让一个新来的实习生在 30 秒内看懂吗？
• 这个复杂度真的有必要存在吗？
• 我的数据流向清晰吗？

写好地道的 Go 要求你学会“自我克制”。当你学会在编译器的安全网中，用最平铺直叙的代码去平复系统的复杂性时，你才真正跨过了从“写代码的泥瓦匠”到“管理复杂度的工程师”的门槛。

隐式接口与组合：告别深层继承树，解锁真正的松耦合

面向对象（OOP）的“多重继承”和“深层父子类”是无数中大型项目腐烂的温床。当你修改了一个顶层父类的方法时，你根本无法预知下面几十个子类会发生怎样灾难性的崩塌。

Go，彻底斩断了这条锁链。它创造性地采用了隐式接口（Structural Subtyping/鸭子类型）。

Go 社区有一句广为人知的黄金法则：“Accept interface, return struct.”（接受接口，返回结构体）。

这一原则在 Reddit 社区中被无数开发者奉为圭臬：

• 输入端轻量级解耦（Accept interface）：我的函数不关心你是什么“类”，我只关心你能不能干“读数据（Read）”这件事。
• 输出端具体、干净（Return struct）：我产生的是最具体、最实在的数据，把如何使用它的自由交还给调用者。

这种设计迫使你放弃设计复杂的“分类学（Taxonomy）”层级，转而像拼装乐高积木一样，用 “组合（Composition）” 的思路去重组系统。

在 Go 中，数据（Struct）和行为（Methods）是彻底分离的。没有 giant Class 树，只有扁平的、通过隐式接口拼装在一起的松耦合组件（Ports & Adapters）。这种“六边形架构”思维一旦融入你的脑海，你再去写任何其他语言，都会自然而然地写出极度清爽、极易重构的代码。

系统工程思维的蜕变：为什么“写最无聊的代码”是最高级的职业素养？

在 Reddit 讨论中，最让人产生共鸣的一句话是：

“Idiomatic Go was intentionally designed to make code easy to read for the next developer, not easy to write for the current one.”（地道的 Go，其设计的首要目标是让代码便于下一个开发者阅读，而不是为了让当前的开发者写得爽。）

很多年轻程序员总觉得“越精妙、越难懂、别人都看不懂的代码”才代表高水平。但当你真正经历过生产环境的毒打，半夜三点被报警电话叫醒去 debug 一个无人能懂的“聪明代码”时，你才会明白：可预测性（Predictability）和可读性（Readability）才是衡量一个程序员职业素养的终极指标。

Go 语言通过它的各种限制，强行把大家的代码拉到了同一个频道上。

它逼迫你交出在代码里展示智力优越感的方向盘，让你学会在业务逻辑的深度、数据的流向和工程的健壮性上去寻找真正的技术挑战。这种在软件工程层面的“祛魅”与成熟，正是地道的 Go 给予我们最珍贵的礼物。

小结

回到最初的问题：写地道的 Go 语言，是否能让你成为了一个更好的开发者？

答案是毫无疑问的。

Go 语言就像是一套高标准的“驾驶训练模拟器”。它通过在内存安全、并发模型、依赖管理和错误处理上的硬性规则，逼迫你戒掉所有在其他高级语言中惯出来的“坏毛病”。

它强迫你直面系统失败，强迫你用组合去代替继承，强迫你把简单和可维护性放在首位。

当你完成了这场认知洗礼，重新格式化了自己的大脑之后，你会发现，即便有一天你离开了 Go 去写 C++、Java 或 Python，你写出来的代码也变得比以前更干净、更清晰、更易重构。因为你已经学会了像一个真正的软件工程师一样去思考问题。

资料链接：https://www.reddit.com/r/golang/comments/1tza18e/did_writing_idiomatic_go_made_you_a_better/

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/10/the-story-of-cpp

大家好，我是Tony Bai。

如果将人类现代软件工业比作一部庞大的机器，那么支撑其运转的最核心骨架中，无疑很大一部分由C++支撑。从你手中的智能手机操作系统、每天刷的短视频推荐引擎、华尔街每秒百万次的高频交易系统，到驱动大语言模型（LLM）的底层算力矩阵，C++ 几乎无处不在。

在过去的 40 年里，这门语言一次次被宣布“濒临死亡”，却又一次次浴火重生。它被称为“弗兰肯斯坦的怪物”，被无数程序员诅咒过其令人发指的复杂性。但即便在如今 Rust 和 Go 等现代语言强势围剿的今天，C++ 依然稳坐系统级编程的王座。

近日，一部名为《The Story of C++: The World’s Most Consequential Programming Language》（C++ 官方纪录片）在 YouTube 上引起了巨大轰动。这部长达近两小时的纪录片，首次召集了包括 Bjarne Stroustrup（C++ 之父）、Alexander Stepanov（STL 之父）在内的一众 C++ 核心缔造者，向世人揭开了这门语言背后那些鲜为人知的妥协、背叛与权力斗争。

更精彩的是，在海外技术社区 Reddit 的 r/cpp 板块中，这部纪录片引发了无数大厂老炮和编译器极客的热烈讨论，通过将纪录片的官方叙事与社区的“野史”拼凑在一起，我们看到了一部远比代码本身更惊心动魄的技术史诗。

序章：从贝尔实验室逃出的“异类”

时间倒回 1979 年。彼时的贝尔实验室（Bell Labs）是全球计算机科学的“麦加圣地”，Ken Thompson和Dennis Ritchie 在这里创造了 C 语言和 Unix 系统。整个世界都沉浸在 C 语言那种贴近硬件、极致简洁的暴力美学中。

就在此时，一个名叫 Bjarne Stroustrup 的丹麦年轻人来到了贝尔实验室。他需要编写复杂的分布式系统模拟器，很快便发现，C 语言那套基于“函数与指针”的过程式编程，在面对巨大且复杂的系统时，就像是在用石器时代的工具建造摩天大楼——代码极易失控，且难以复用。

于是，他做了一个极具叛逆性的决定：他要在 C 语言的基础上，引入“类（Classes）”的概念。 这就是最初的“C with Classes”。

Bjarne 的初衷极其务实：他不想重新发明轮子，他只想让现有的 C 程序员能够稍微优雅一点地写代码。 因此，他定下了一条死命令：C++ 必须 100% 兼容 C 语言。

在 Reddit 的讨论中，一位资深 C++ 工程师指出：“C++ 之所以能在早期存活下来，唯一的理由就是它能够与海量的 C 语言头文件无缝对接。” 这条与 C 的“血脉绑定”，成为了 C++ 能够迅速占领企业级市场的最强杀手锏，但也为它日后的无底洞复杂性和编译期灾难埋下了最深远的隐患。

第一幕：STL 的救赎——从被群嘲到绝地反击

如果说 Bjarne 给了 C++ 骨架，那么真正赋予 C++ 灵魂的，是另一个极具争议的天才：Alexander Stepanov。

在 90 年代初，面向对象编程（OOP）如日中天。所有人都在沉迷于画继承树、搞多态。但 Stepanov 对此嗤之以鼻。他认为，将数据结构和算法强行绑定在对象里，是一种“极度低效且愚蠢的数学谬误”。

他提出了一种名为“泛型编程（Generic Programming）”的思想：算法应该独立于数据结构之外，通过一种叫“迭代器（Iterator）”的桥梁连接。

这就是后来名震天下的 STL（标准模板库）。

在纪录片中，最戏剧性的一幕发生在 1993 年的 C++ 标准委员会上。当 Stepanov 第一次将庞大且极其复杂的 STL 提案摆在委员会面前时，遭到了全场的群嘲与抵制。

“这太庞大了！这太疯狂了！这简直是在强奸编译器！”大佬们纷纷摇头。

此时的 C++ 委员会，正沉浸在由微软、IBM 等科技巨头把持的“门派斗争”中，没有人愿意为这种学术界的“屠龙术”买单。

在生死存亡之际，是 Bjarne 站了出来。为了让 STL 能够活下来，Bjarne 甚至不惜“扭断了自己亲生孩子的手臂”。

一位Reddit 用户分享了一段极其硬核的野史：“听到 Bjarne 承认为了让 STL 能在早期的 Cfront（C++ 编译器前置工具）上编译通过，他强行修改了 C++ 的语言规则，甚至导致了著名的 Cfront 2.0 bug，这简直太搞笑了！”

最终，在 Bjarne 的权力背书下，STL 以极其微弱的优势通过了委员会的投票。这一决定，彻底改变了现代软件工业的走向。没有 STL 提供的 Vector、Map 和极度优化的泛型算法，后来的谷歌、亚马逊和高频交易公司根本无法在 C++ 上构建起支撑亿万级流量的系统。

第二幕：巨头的绞杀——微软的野心与 Java 的入侵

正当 C++ 在系统底层攻城略地时，外部的绞杀战开始了。

2000 年前后，C++ 迎来了它生命中最黑暗的“冰河期”。在 Reddit 上，大厂老炮们对这段历史记忆犹新：

1. Java 的降维打击：Sun 公司推出的 Java 带着“Write Once, Run Anywhere（一次编写，到处运行）”和自带垃圾回收（GC）的承诺，瞬间摧毁了 C++ 在企业级开发层的统治地位。IBM 等巨头一夜之间倒戈。
2. 微软的背刺：为了对抗 Java，微软推出了自己的 .NET 战略和 C# 语言，并在很大程度上“冻结”了对原生 C++ 工具链的投入。

当时的 C++，就像是一个垂暮的老人：没有包管理器、跨平台编译像一场噩梦、ABI（应用程序二进制接口）地狱让人抓狂。甚至有人提到了一篇著名的早期新闻标题：“The Decline of C++?（C++ 的衰落？）”

更致命的是，C++ 标准委员会（WG21）在这个时期陷入了长达十年的“难产”。各大编译器厂商（尤其是微软的 MSVC）为了各自的商业利益互相扯皮。

在 Reddit 的帖子中，现任 MSVC STL 开发者的 STL 本尊亲自下场“辟谣”与爆料：

当时有很多开发者抱怨微软试图“破坏”STL（因为微软在 STL 里加入了极度拖慢性能的迭代器调试代码 _SECURE_SCL）。STL 大神解释道：“*微软并没有试图破坏 STL，这纯粹是出于对安全性的妥协，而在 2000 年代，由于编译器团队对 C++ 底层模板的理解不足，导致了糟糕的实现。*”

无论如何，在这漫长的十年里（C++98 到 C++11 之前），C++ 停滞不前。这段历史在官方纪录片中被轻描淡写地带过，但在社区看来，这是 C++ 被巨头资本裹挟、险些丧命的耻辱时代。

第三幕：现代 C++ 的绝地反击（C++11 至今）

就在所有人都以为 C++ 将退化为一门“只配用来写驱动”的边缘语言时，C++11 横空出世。

这绝对是编程语言史上最伟大的一次“续命”。C++11 引入了 auto、智能指针（Smart Pointers）、Lambda 表达式以及多线程支持。它仿佛将一辆生锈的老爷车，直接改装成了核动力飞船。

Reddit 上的一位开发者感叹道：“如果你没有经历过在 C++11 之前，仅仅是想要实现一个跨平台的多线程逻辑，就能触发各种未定义行为（UB）的时代，你就无法理解我们现在拥有的现代 C++ 有多么幸福。”

此时，硅谷的巨头们也终于醒悟。随着摩尔定律的逐渐放缓（单核 CPU 的免费午餐结束了），亚马逊、谷歌、Meta 以及高频交易巨头 Hudson River Trading（HRT）发现：要想在服务器账单上省下数千万美元，要想让延迟降低到微秒级，只有一条路可走——回归 C++。

从 C++11 开始，标准委员会终于恢复了活力，确立了每三年发布一个新标准（C++14, C++17, C++20…）的铁律。

纪录片中展示了今天 C++ 标准委员会的盛况：从最初的几十人，变成了现在动辄数百人的庞大机构。但这同时也带来了新的诅咒：过度设计与特征膨胀（Feature Bloat）。

终章：C++ 无法摆脱的诅咒与未来

纪录片以一种充满希望的基调收尾，特别提到了即将到来的 C++26 及其杀手级特性：静态反射（Static Reflection）。

但在 Hacker News 和 Reddit 上，那些每天深陷在 C++ 屎山代码中的一线架构师们，却显得远没有那么乐观。

1. 缺失的拼图：为什么官方不敢提 Boost？

眼尖的社区极客指出，这部宣称是“官方历史”的纪录片，竟然对 Boost 库 只字未提！要知道，在 C++ 停滞的十年里，是 Boost 库（包含大量实验性的元编程和现代特性）几乎凭借一己之力撑起了 C++ 的生态，并孵化了 C++11 的大部分新特性。社区猜测，这背后可能涉及到 Boost 基金会与 C++ 标准委员会之间复杂的权力斗争与未解恩怨。

2. 基础设施的荒漠：构建工具与包管理器之殇

在 Reddit 上，超过一半的火力集中在一个最朴素的痛点上：C++ 至今没有一个像样的官方包管理器。

当你用 Go 或 Rust 开发时，go get/install 或 cargo install 就能优雅地解决一切。但在 C++ 中，为了集成一个第三方库，你需要聘请一个拥有“博士学位”的 CMake 工程师，在 vcpkg、Conan、Bazel 之间痛苦挣扎，还要处理无穷无尽的 ABI（应用程序二进制接口）冲突。

一位大厂架构师绝望地写道：“标准化不应该强迫企业妥协，但现有的三大包管理器，导致了生态的极端割裂。C++ 真正的问题不在于语言层面，而在于其糟糕透顶的工程工具链体验。”

3. 碳（Carbon）与锈（Rust）的围剿

如今，谷歌推出了试图平替 C++ 的 Carbon 语言，而白宫甚至在安全报告中公开呼吁开发者放弃 C/C++，转向内存安全的 Rust。

面对如此巨大的压力，C++ 能够挺过下一轮大洗牌吗？

答案或许依然是肯定的。因为 C++ 早就超越了一门编程语言的范畴，它已经成为了人类数字文明的基础物理法则之一。 那些数以百亿计的遗留代码，那些经历了三十年实战检验的高频交易系统，那些与硬件深度绑定的 GPU 调度矩阵，是不可能在十年内被 Rust 或 Go 完全重写的。

《The Story of C++》不仅是一部纪录片，它是一面镜子。它照出了人类在构建庞大数字帝国时，那种充满妥协、混乱却又无比顽强的工程精神。

C++ 的世界里没有完美的乌托邦。正如 Bjarne Stroustrup 那句最著名的名言：

“世界上只有两种编程语言：一种是人们天天在抱怨的语言，另一种是根本没人用的语言。”

而 C++，无疑是被抱怨得最狠，却又永远无法被抛弃的那一个。

资料链接：

• https://www.youtube.com/watch?v=lI7tMxzSJ7w
• https://www.reddit.com/r/cpp/comments/1txhe5n/the_story_of_c_the_worlds_most_consequential/

今日开放讨论：

作为开发者，你认为 C++ 目前最大的痛点是由于它必须保持与 C 的后向兼容（Backwards Compatibility），还是因为它糟糕的构建和包管理工具？在 AI 和 Rust 崛起的时代，你会建议新人继续深入学习 C++ 吗？

欢迎在评论区留下你的观点，我们一起探讨系统级编程的未来！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/27/migrate-go-to-rust

大家好，我是Tony Bai。

在现代后端系统编程领域，Go 和 Rust 无疑是最耀眼的两大双子星。它们都拥有静态类型、编译型、单二进制文件分发等优异特性。然而，这两门语言在底层的设计哲学、运行时权衡以及开发者体验上，走向了截然不同的方向。

Matthias Endler（Corrode 咨询公司创始人）撰写的《从 Go 迁移到 Rust》（Migrating from Go to Rust）是近年来系统编程领域极具深度的一篇迁移指南。作为在生产环境中同时大规模部署过 Go 和 Rust 系统的资深架构师，Matthias 并没有陷入单纯的“谁比谁快”的无意义争论，而是从正确性保证、运行时权衡、工程重构成本等多个维度，客观地为准备进行语言迁移的团队提供了一份极其务实的工程路线图。

以下是该迁移指南的完整简体中文译文，以及技术社区对于此文的精彩技术辩论与观点。

在我协助团队进行的所有迁移中，从 Go 到 Rust 的迁移是一个特例。

这并不是“Rust 会更快吗？”或“Go 是否拥有类型系统？”的问题，因为 Go 在这些方面已经做得很好了。这里的讨论主要围绕正确性保证、运行时权衡以及开发人员体验展开。

在开始之前，先做一个简短的免责声明：本指南高度侧重于后端。后端服务是 Go 的强项所在——小巧的静态二进制文件、专注于网络连接的标准库，以及用于 HTTP 服务器、gRPC、数据库等的庞大生态系统。

这也是大多数考虑使用 Rust 的团队的来源（至少是那些联系我的团队），因此我认为这是在实践中最有用的对比。如果你正在编写命令行工具（CLI）、嵌入式固件或游戏引擎，本文中的一些内容仍然适用，但老实说，我恐怕这不是最适合你的资源。

作为背景，我之前曾写过关于 Go 和 Rust 对比的文章，比如 2017 年的《Go vs Rust？选择 Go》，以及后来与 Shuttle 团队合作撰写的《Go vs Rust：实操对比》，后者通过一个小型后端服务展示了两种语言的具体差异。

你将在本文中学到什么

• Go 与 Rust 的重叠点和分歧点。
• Go 的模式如何映射到 Rust。
• 你能从借用检查器中获得什么。
• 我在什么情况下会建议人们保留 Go，以及在什么情况下 Rust 值得进行迁移。
• 如何渐进式地迁移 Go 服务。

我的背景与立场

坦白说：我不是 Go 的粉丝。我认为它是一门设计糟糕的语言，尽管它非常成功。它混淆了简单性（simplicity）与易用性（easiness），并且它的几个核心设计折中——无处不在的 nil、作为纪律规则而非类型的错误处理、长期缺失的泛型——都将设计引向了我所不认同的方向。尽管如此，成功才是硬道理！Go 已经捕获了庞大且持久的活跃开发者份额，在 JetBrains 开发者生态系统调查中一直维持在 17-19% 左右。Rust 正在稳步增长，但目前仍然只占一小部分：

Go 显然对很多人都非常适用，而一个假装其不适用的指南是毫无帮助的。因此，在这份指南中，我将尽最大努力保持客观，而不是去重新争论那些老问题。但你应该了解我的先验立场，以便进行校准。

另一个值得披露的前提是：我运行着一家 Rust 咨询公司；所以，我当然是有偏见的！更多人使用 Rust 对我的业务是有利的。但我也在专业领域中使用过这两门语言，并曾将 Go 服务推向生产环境。

本指南适用于那些希望诚实对比迁移到 Rust 时会有什么变化的 Go 开发者。

如果想看一个故意持相反立场的观点，我推荐阅读 Blain Smith 的《就用 Go语言好了，别他妈的废话了！》（Just Fucking Use Go）。在脑海中同时保留这两种观点，比只持其中一种更有用。

如果你更喜欢观看视频而不是阅读，这里有一段来自 The Primeagen 对上述 Shuttle 文章的视频阅读和点评：

(视频：Rust vs Go: Hands On Comparison)

初看最重要的命令

Go 开发者已经拥有了行业内最干净的工具链之一。在很久以前，它就开启了“自带电池（batteries included）”式工具链的潮流，为你提供了一个单一、一致的界面，用于构建、测试、格式化、lint 和管理依赖项。我很高兴 Rust 也效仿了这种做法，因为这是一个极好的模式。这是我最喜欢的这两个生态系统的部分之一。

cargo 甚至拥有更多内置功能：

最大的区别在于，在 Go 中你通常需要借助第三方工具（golangci-lint、mockgen、air、goreleaser）来填补空白。而在 Rust 中，原生(第一方)生态系统开箱即用的功能要丰富得多。有些需要外部 crate 的工具（例如 cargo watch、cargo nextest）只需一个命令即可完成安装并开始使用，例如运行 cargo install cargo-nextest 即可立即获得 cargo nextest。

两个社区在格式化工具上都达成了相同的共识：一个单一的、规范的风格，即使不是完美的，也远比在琐碎的争论（bikeshedding）上浪费时间要好。

“Gofmt 的风格不是任何人的最爱，但 gofmt 却是每个人的最爱。”

— Rob Pike, Go Proverbs

对于 rustfmt 也是如此；并非每个人都喜欢它的每个细节，但代码评审中不再存在关于代码风格的争端，远比偶尔遇到你不喜欢的格式化偏好要有价值得多。

Go 与 Rust 的关键差异

核心结论是，Go 和 Rust 都是编译型、静态类型、单二进制文件部署、具有强大并发能力的语言。不同之处在于编译器向你保证了什么，以及你对运行时行为拥有多少控制力。

在深入探讨之前，有一个概念框架很有帮助：当你从 Go 迁移到 Rust 时，大部分变化都会被推入类型系统。 空值处理、错误传播、数据竞争、资源生命周期、取消机制、泛型，这些在 Go 中要么依赖运行时规范、工具链（go vet、errcheck、golangci-lint、-race），要么依赖运行时的自觉性。而 Rust 则将它们编码为类型，以便编译器在编译时强制执行。

常见的反对意见是这带来了“更多的认知负荷”。我不认同这种说法。我认为，这其实是将认知负荷从你由于必须记住规则而产生的焦虑中释放出来，转移到了编译器身上。一旦你内化了这种模式，并发现它在代码中无处不在（Option、Result、&mut T、Send/Sync、RAII 守卫），Rust 就会停止让你感到沉重，并开始感觉编译器正在为你做你以前必须在大脑中做的工作。

为什么 Go 开发者会考虑 Rust

Go 开发者通常不会因为 Go “太慢”而转向 Rust。对于大多数后端工作负载，Go 已经足够快了。人们普遍是对 Go 的一些由于设计不严密而产生的问题感到沮丧：nil 指针带来的隐患、段错误（segmentation faults）的风险、缺乏泛型（长期以来）或任何更复杂的类型系统特性（如枚举和强大的 trait），以及标准库中存在一些怪异的缺失，例如缺少一个内置的 Set 类型（惯用的替代方案是 map[T]struct{}，它在实践中行得通，但感觉类型系统并没有真正起到作用）。

生产环境中的 nil panics

你部署了一个 Go 服务，它运行得很好，持续了几个月。然后，某条代码路径被执行，而其中有人忘记检查某个指针是否为 nil，导致 goroutine 崩溃。一个常见的例子是查找操作，它返回零值，或者反序列化后未填充结构体中的某个指针字段：

func (s *Service) Handle(req *Request) error {
    // Find 返回 (*User, error)。如果是 "not found"，error 为 nil；
    // 调用者应该检查 user != nil，但这非常容易被遗漏。
    user, err := s.repo.Find(req.UserID)
    if err != nil {
        return err
    }

    return user.Account.Notify() // 如果 user 为 nil，或 Account 为 nil，则会发生崩溃
}

Linter 和 IDE 会捕获其中一些情况（通过 nilaway、staticcheck），但它们是选择性开启的、概率性的，而且不能可靠地跨越包边界。Rust 的编译器则根本不允许你忽略这种情况。Rust 的 Option 可以做到：

fn handle(&self, req: &Request) -> Result<(), ServiceError> {
    let user = self.repo.find(req.user_id)?; // 返回 Option<User>; ? 运算符进行短路处理
    user.notify()
}

如果没有显式处理 None 的情况，你甚至无法解引用一个 Option。一整类导致 pager-duty（线上紧急警报）事件的事故就这样消失了。

-race 未能捕获的数据竞争

go test -race 是一个优秀的工具，但它是一个运行时检测器，意味着它只能找到测试中实际执行到的竞争。在线上高负载下，多个 goroutine 在没有锁的情况下修改同一个 map 会轻松绕过该测试，并导致生产环境崩溃。

在 Rust 中，跨线程共享可变状态需要实现 Send 和 Sync。尝试共享一个普通的 HashMap 并且程序甚至无法编译。你被迫将其封装在 Arc<Mutex<…>> 或 Arc<RwLock<…>> 中，否则编译器会报错。这样，数据竞争在编译时就成了一个类型错误。

Paul Dix 对于什么促使了 InfluxDB 3.0 的重写非常坦诚，而数据竞争的故事就排在最前面：

“【最主要的好处是】无畏并发——消除了此前我们从未消除的数据竞争。在 Influx 1.x 版本中，确实存在一些非常棘手的 bug。”

— Paul Dix, InfluxData 创始人兼 CTO，摘自 Rust in Production

可组合的错误处理

在 Go 中，你会写：

if err != nil {
    return err
}

在一两年的开发后，你通常会注意到三件事：

1. 样板代码冲淡了你函数的实际业务逻辑。
2. 使用 fmt.Errorf(“doing X: %w”, err) 包装错误是一项纪律要求，而不是编译器强制的规则。这很容易丢失上下文。
3. 通过 errors.Is/errors.As 使用哨兵错误可以工作，但当你忘记处理新变体时，编译器不会提醒你。

对反方观点保持诚实也很重要，因为在关于我的 Shuttle 文章的 Lobste.rs 讨论线程中，经验丰富的 Go 开发者指出，errcheck 和 golangci-lint 捕获了绝大多数“忘记处理错误”的情况，并且显式的 if err != nil 比深层嵌套的 ? 链更容易阅读。这两个观点都很中肯，显式风格是一个刻意的文化抉择，而不是一次疏忽：

“我认为错误处理应该是显式的，这应该是该语言的核心价值。”

— Peter Bourgon, GoTime #91，引用自 Dave Cheney 的 Zen of Go

我的看法是，lint 是一个你必须记住去配置的选择性安全网，而 Rust 的 Result<T, E> 是类型签名本身，无法被遗忘。样板代码与可读性之间的折中是非常真实且见仁见智的。

在 Rust 中：

#[derive(Debug, thiserror::Error)]
pub enum UserError {
    #[error("user {0} not found")]
    NotFound(UserId),
    #[error("user already exists")]
    AlreadyExists,
    #[error(transparent)]
    Repo(#[from] RepoError),
}

pub fn rename(id: UserId, name: &str) -> Result<User, UserError> {
    let mut user = repo::get(id)?; // ? 自动将 RepoError 转换为 UserError
    user.name = name.to_string();
    Ok(user)
}

? 运算符处理了错误传播，#[from] 处理了类型转换，而针对 UserError 的 match 是穷尽检查的。如果明天你添加一个新的错误变体，编译器会向你展示每一个需要更新的地方。

不装箱的泛型

Go 在 1.18 中引入了泛型，它们很有用，但实现上有一些限制（不支持类型参数上的方法，GC shape stenciling，偶尔会有令人失望的性能表现）。Rust 泛型采用单态化（monomorphize），为每个实例生成具有零运行时开销的专门代码。结合 trait，这为你提供了真正的零成本抽象。

这在处理程序（handler）代码中不那么重要，而在共享基础设施（中间件、通用存储库、解码器、解析器）中更重要，在 Go 中，你常常被迫退回到 interface{} / any 外加类型断言。

可预测的延迟

Go 的 GC 非常优秀、并发、低停顿，针对典型的服务工作负载进行了很好的调优。但“低停顿”不等于“无停顿”。在重载情况下，P99 延迟尾部明显差于一个不在热路径上分配内存的 Rust 等效程序。

我不会过分夸大这一点，对于绝大多数服务来说，Go 的 GC 根本不是问题。但对于延迟敏感的系统（交易、实时竞价、网络代理、高吞吐量数据摄入），没有 GC 停顿是一个巨大的卖点。Stephen Blum 把它说得很直接：

“Go 在我们的规模下表现很好，但我们确实需要一些能给我们带来高性价比性能的东西，而 Rust 能够让我们达到那个目标。这就是为什么如今基本上所有的东西都在朝着 Rust 发展的原因。”

— Stephen Blum, PubNub CTO, 摘自 Rust in Production

总结

Go 像是遭受了千刀万剐（death by a thousand paper cuts）。它是一门非常实用的语言，如果你愿意忽略上述问题，你可以在其中获得极高的生产力。但在达到一定的代码规模后，问题就会开始累积。Go 失去吸引力并没有单一的瞬间，但团队会发现自己渴望更多（更多的安全性、更多的控制、更多的表现力），这就是他们开始寻找替代方案的时候。

Side By Side的对比两种语言

在 Rust 中感到舒适的最快方法是映射你已经知道的模式。如果要看在两种语言中构建相同后端服务的更长、包含大量代码的完整示例，请参阅 Shuttle 对比文章，本节重点介绍最常出现的模式。

错误处理：if err != nil 对比 Result<T, E>

Go:

func ReadConfig(path string) (*Config, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("reading config: %w", err)
    }

    var cfg Config
    if err := json.Unmarshal(data, &cfg); err != nil {
        return nil, fmt.Errorf("parsing config: %w", err)
    }

    return &cfg, nil
}

Rust:

fn read_config(path: &Path) -> Result<Config, ConfigError> {
    let data = fs::read_to_string(path)?;
    let cfg = serde_json::from_str(&data)?;
    Ok(cfg)
}

? 运算符替你完成了 if err != nil { return err } 的繁琐工作，如果为 E2 实现了 From，它还会进行类型转换（这在使用 thiserror 的 #[from] 时是惯用）。

空值：nil 对比 Option

Go:

func GetUser(id string) *User {
    for _, u := range users {
        if u.ID == id {
            return &u
        }
    }
    return nil
}

u := GetUser("123")
fmt.Println(u.Name) // 如果u 为 nil 则会发生panic

Rust:

let user = get_user("123");
println!("{}", user.name); // 编译错误：user 的类型是 Option<User>，而不是 User

// 你必须处理这两种情况：
match get_user("123") {
    Some(u) => println!("{}", u.name),
    None => println!("not found"),
}

在安全的 Rust 中没有 nil。引用不能是空的。指针可以是空的，但你几乎永远不会在应用程序代码中使用裸指针。

接口 对比 Traits

Go 的接口是结构化的，一个类型隐式地满足一个接口：

type Reader interface {
    Read(p []byte) (n int, err error)
}

Rust 的 trait 是标称的，你需要显式地实现它们：

pub trait Reader {
    fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize>;
}

impl Reader for MyType {
    fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize> { /* ... */ }
}

Go 的风格非常适合临时性的鸭子类型。Rust 的风格非常适合重构和可发现性，你可以用 grep 搜索某个 trait 的每个实现者。

Rust 中与 interface{} / any 最接近的等价物是 Box，但你几乎永远不会想要它。Go 社区习惯于伸手去拿 interface{}，也是因为：

“interface{} 什么也没表达。”

— Rob Pike, Go Proverbs

带有 trait 约束的泛型函数（fn handle(r: R)）涵盖了绝大多数情况，并通过单态化提供无运行时开销。在 Go 1.18 之前，这迫使你退回到 interface{} 加上类型断言，而 Rust 的 trait + 泛型让你能够非常具体。

当你确实需要运行时分发（例如，不同实现者的异构存储）时，你会选择 Box 或 Arc。这是 Go 中持有 interface 值最直接的 Rust 对应物。

Goroutines 对比 异步任务

Go 的并发模型以简单著称：

go doWork(ctx, input)

Goroutine 很廉价，运行时会在操作系统线程之间调度它们，而通道（chan T）是主要的协同原语。Go 谚语捕获了这一理念：

“不要通过共享内存来通信；而要通过通信来共享内存。”

— Rob Pike, Go Proverbs

这是 Go 真正大放异彩的地方，并且它对为什么非常明确：在 Go 中，顺序代码和并行代码之间没有语法上的区别。函数签名、它的调用者，或关于它如何编写的任何内容都毫无二致。没有 async fn，没有 .await，没有执行器可供选择，也没有 Send / Sync 约束。只要你不共享可变状态而不进行同步，顺序代码和并发代码看起来是一样的。

这种属性，即没有函数着色（function colouring），是 Go 相比 Rust 最大的日常生产力优势，而在迁移之后，这也是 Go 开发者最怀念的东西。Lobste.rs 讨论中的几位评论者准确地指出了这一点，他们说得很对。Rust 的 async 更加强大且经过更多检查，但它的显式度也更高，这带来了真正的开发体验成本。

Rust 在执行器（对于后端服务几乎总是 tokio）之上使用 async/await：

tokio::spawn(async move {
    do_work(input).await;
});

形式很相似。不同之处在于：

• Rust 的异步函数返回 Future。除非被 .await 或 spawn，否则它们不会运行。
• 编译器会跨 .await 点验证 Send/Sync 约束。如果你在跨 .await 期间持有一个非 Send 的值，你会得到一个非常精确的编译器错误，解释其原因。
• 没有内置的 goroutine 风格的抢占。异步任务中长时间运行的 CPU 工作会使执行器饥饿；你需要将其卸载到 tokio::task::spawn_blocking 或 rayon。
• 通道（tokio::sync::mpsc、broadcast、watch）是一流的，但存在于库中，而不是语言本身。

对于大多数后端代码，日常体验是类似的：启动一个任务，通过通道进行通信，并大方地使用超时。

context.Context 对比 CancellationToken

在 Go 中，你将 context.Context 传给每个阻塞调用：

func (s *Service) Fetch(ctx context.Context, id string) (*User, error) {
    return s.client.Get(ctx, "/users/"+id)
}

Rust 没有内置的 context.Context。最接近取消的等价物是 tokio_util::sync::CancellationToken：

pub async fn fetch(&self, token: CancellationToken, id: &str) -> Result<User, FetchError> {
    tokio::select! {
        _ = token.cancelled() => Err(FetchError::Cancelled),
        res = self.client.get(&format!("/users/{}", id)) => res,
    }
}

对于超时，tokio::time::timeout(dur, fut) 可以包装任何 future。对于截止时间/值，你通常将它们作为显式参数传递，或者使用 tracing span 而不是单一的上下文对象。

一些 Go 开发者怀念 ctx 的隐式感。但在实践中，显式的 Rust 风格更容易让人推断，因为你总是确切地知道什么是可以取消的，什么是不可以的。更深层次的观点是，没有任何一种语言可以免费给你取消机制，只是规约出现在不同的层面上：

“Go 并没有办法告诉一个 goroutine 退出。没有停止或杀死函数，这是出于充分的理由。如果我们不能命令一个 goroutine 退出，那么我们就必须礼貌地请求它。”

— Dave Cheney, The Zen of Go

在 Go 中，这种“礼貌地请求”是通过约定俗成地在每个调用点传递并检查 context.Context。在 Rust 中，则是 CancellationToken（或 watch 通道）传给每个调用点，但编译器实际上可以在你忘记时提醒你。

通道

两种语言都有通道。翻译很直接：

Go:

ch := make(chan int, 10)
go func() {
    ch <- 42
}()
v := <-ch

Rust:

let (tx, mut rx) = tokio::sync::mpsc::channel::<i32>(10);
tokio::spawn(async move {
    tx.send(42).await.unwrap();
});
let v = rx.recv().await.unwrap();

Rust 的通道将发送端（Sender）和接收端（Receiver）区分为不同的类型，这使得所有权和 Send 属性在类型层面是显式的。

结构体与方法

Go:

type Circle struct {
    Radius float64
}

func (c Circle) Area() float64 {
    return math.Pi * c.Radius * c.Radius
}

Rust:

pub struct Circle {
    pub radius: f64,
}

impl Circle {
    pub fn area(&self) -> f64 {
        std::f64::consts::PI * self.radius * self.radius
    }
}

Rust 的 &self 相当于 Go 的值接收者；&mut self 是一个带有修改权限的指针接收者。拥有的 self（消耗该值）在 Go 中没有对应物，但在（类型状态、构建器）模式中偶尔非常有用。

字符串：string 对比 String 与 &str

Go 的 string 是一个具有赋值时拷贝语义的 UTF-8 字节切片（头部被复制，底层数据是不可变且共享的）。Rust 将其分为两种类型：

• String：拥有的、堆分配的、可增长的。相当于你打算修改的 []byte。
• &str：借用的视图，指向别人的字符串数据。大部分时间相当于作为 Go 的 string 参数使用。

作为一条经验法则，参数中接收 &str，在生成新数据时返回 String。

fn greet(name: &str) -> String {
    format!("Hello, {name}")
}

一旦你内化了这一点，这基本上是无痛的。&str 与 String 的划分是 Rust 更广泛的“借用与拥有”模型的一个缩影。

Go 泛型：太少，太迟

Go 在 1.18（2022 年 3 月）引入了泛型，在语言出货十三年之后。它们很有用，但由于它们是后期补丁（tacked on），在实践中它们具有大多数你期望从 Rust、Haskell 甚至现代 C++ 获得的泛型系统的缺点，却没有任何优点。

这是一个很强烈的说法，所以让我来支持它。

标准库几乎不使用它们

最明显的信号是，在泛型落地三年后，Go 自己的标准库仍然主要避免使用它们。sort.Slice 仍然接受一个 func(i, j int) bool 闭包，而不是 cmp.Ordered 约束。sync.Map 仍然被类型化为 any / any。除了 slices、maps 和少数组件外，几乎没有它们的身影。

公平地指出，向后兼容性是这里的主要原因：Go 1 的兼容性承诺意味着现有的非泛型 API 无法重构，因此任何泛型版本都必须与其并存（或在新的包中）。但这只是解释的一部分。已经有足够的时间来引入泛型替代方案，而几乎没有出现这一事实表明语言设计者并不倾向于将泛型作为他们使用的主要工具。

将其与 Rust 进行对比，在 Rust 中，泛型从第一天起就渗透到了标准库中：Option、Result<T, E>、Vec、HashMap<K, V>、Iterator、From、Into、AsRef、Borrow，每个集合、每个智能指针。在不使用泛型的情况下，你根本无法写出惯用的 Rust，因为标准库本身就是泛型的。

在 Go 中，泛型是库作者在确实需要时才选择使用的功能。在 Rust 中，它们是构建一切事物的底层基石。

没有 Trait 系统，只有结构化约束

Rust 的泛型与 trait 绑定，trait 兼作该语言进行多态、超类、关联类型、毯子实现（blanket impls）和一致性的机制。

Go 的约束只是带有一个额外 ~ 运算符的接口，用于类型集成员资格。这里没有：

• 超类 / 约束继承体系： 在 Rust 中，你写 trait Ord: Eq + PartialOrd，任何满足 T: Ord 的类型自动满足 Eq 和 PartialOrd。Go 没有等价物；你可以嵌入接口，但约束求解器并不推断关于层次结构的任何信息。
• 关联类型： Rust 的 Iterator 有 type Item;，因此 T::Item 是第一等公民，这体现在每个方法的签名中。Go 最接近的等价物是第二个类型参数，这会泄露到每个方法签名中。
• 毯子实现（Blanket impls）： 在 Rust 中，impl ToString for T 会自动为每一个实现了 Display 的类型实现 ToString 方法。在 Go 中，没有办法在定义包之外，为一个类型添加方法。
• 拥有自己类型参数的方法： 这是一个显式且有文档记录的 Go 缺失功能 (译注：Go 1.27将补全泛型方法这一特性)。你不能写 func (s Set[T]) Map[U](f func(T) U) Set[U]。在 Rust 中，泛型方法是家常便饭。

实际的后果是，当你的抽象需要不仅仅是一个“适用于任何 T 的函数外加这几个操作”时，Go 就会迫使你退回到 any 以及类型断言、代码生成或运行时反射。

类型推导止于函数边界

Rust 使用 Hindley-Milner 风格的推导引擎，可以跨整个表达式传播类型信息，包括跨闭包、迭代器链和 ? 运算符。你经常写：

let evens: Vec<_> = (0..100).filter(|n| n % 2 == 0).collect();

而编译器会推断出 _ 是 i32，而 Vec<_> 目标是 Vec。

Go 的推导要浅得多。它通常可以推断出函数参数的类型，但它不能从返回位置上下文中推断，不能通过泛型构建器跨链推断，并且经常在调用处强制使用显式的类型参数：

result := slices.Collect[int](iter) // 经常需要

在 Rust 中这是例外；在 Go 中这仍然很常见。

单态化 对比 GC Shape Stenciling

泛型没有免费的午餐：你必须要么在编译时买单，要么在运行时买单，要么通过代码膨胀（JIT）买单。C++ 和 Rust 在编译时通过单态化买单。Java 在运行时通过装箱买单。Go 选择了折中路线，采用了 GC 形状模板和字典，这有一篇众所周知的 PlanetScale 文章正好展示了这一点。

Rust 进行单态化：每个 Vec 和 Vec 都会产生专门的机器代码，具有零运行时开销。泛型代码是快速路径，而退回到 dyn Trait（相当于 Go 的接口分发）是一个深思熟虑的选择，在你需要运行时多态时做出。你要为单态化付出编译时间的代价，这和 C++ 几十年来付出的代价一样，但它们只是针对不同的事情进行了优化。

它们没有填补类型系统中的漏洞

这是最让我困扰的部分。

一个好的泛型系统可以消除退回到逃生舱口的理由。在 Rust 中，泛型 + trait 消除了你对 Box 或运行时反射的大部分需求。类型系统变得更强大了。

在 Go 中，泛型并没有消除 any，没有消除 reflect，没有消除代码生成作为诸如 ORM、解码器和 mock 等事物的首选模式。encoding/json 仍在使用反射。database/sql 仍在使用 any。mockgen 仍会生成代码。如果泛型系统能够大放异彩，最应该发挥作用的地方，正是 Go 在 1.18 之前就伸手去拿运行时机制的那些地方。

Go 中的泛型感觉是累加的，只是箱子里的一个新工具，在狭隘的案例中很有用。Rust 中的泛型感觉是基石般的；将它们移去，语言就会崩溃。

这就是区别所在，也是为什么在我的经验中，泛型 Go 代码读起来并不比它取代的基于 interface{} 的代码好；它只是读法不同，有更多标点符号罢了。

流行的 Go 包及其 Rust 对应物

如果你已经在 Go 中有了自己的偏好，Rust 生态系统已经趋于相似级别的“默认选择”。对于一个典型的后端服务：axum + sqlx + tokio + tracing + serde + clap 覆盖了你 90% 的需求。

过渡到 Rust 的关键挑战

我想坦率地说。从 Go 过来，你将会碰壁。这堵墙有一个名字。

借用检查器

Go 的运行时替你处理内存和别名。Rust 将这个决定推入类型系统。前几个星期你会写出“显然应该工作”的代码，然后编译器会拒绝它。

最常困扰 Go 开发者的模式有：

1. 长生命周期引用： 在 Go 中，你可以很开心地在 map 中持有一个 *User，只要你愿意。在 Rust 中，该借用会在整个生命周期中锁住 map。解决方案通常是克隆（clone），或者缩小借用范围。
2. 自引用结构体： 在 Go 中很常见（一个结构体同时持有数据和其上的迭代器）。在 Rust 中，这需要 Pin、ouroboros 或重新设计。几乎总是选择：重新设计。
3. 跨 goroutine 共享可变状态： 在 Go 中你写成：mu sync.Mutex; data map[K]V，而在 Rust 中则变成 Arc<Mutex<HashMap<K, V>>>。稍微啰嗦一些，但经过了更多检查。
4. 从函数返回引用： 生命周期标注（Lifetime annotations）就此出现。它们并不像其声誉那样糟糕，但对新手来说确实很陌生。

在所有的这些规则下，借用检查器确实听起来像一个“守门人”，不断阻碍，并且让人感到沮丧。但是，当你开始使用 Rust 时，不应该带着那样的心态。借用检查器真正揭示了你代码中现有的非常真实、非常微妙的 bug，如果你不解决它们，你的程序就会存在安全问题。因此，每当你从 rustc 得到编译器错误时，请退后一步，问自己以下几个问题：

• 如果一个值被移动（moved）了，之后如果原位置试图再次使用它会发生什么？
• 如果一个值被共享（shared）了，如果在另一个线程使用它的同时，有一个线程对其进行了修改会发生什么？
• 如果一个指针被解引用（dereferenced），如果它是空值或悬空指针会发生什么？
• 当一个值超出作用域（goes out of scope）时，如果其他地方仍然持有的引用正在被使用会发生什么？

这就是你需要理解借用检查器的心态。人类在推理内存方面真的很糟糕。我们很容易忘记指针可以为空，忘记旧的引用可以比它们指向的数据存活得更久，忘记多个线程可以同时修改同一块数据。我们倾向于对数据在程序中如何流动有一个“线性”的心理模型，但现实中它更接近于一个具有多条路径和交互的复杂图形。每一个 if 条件都会强制你考虑这两种分支中会发生什么。这正是借用检查器旨在为你做的事情！它强制考虑那些极其罕见但确实存在的、当你觉得可能不会发生但就是发生了的代码路径。

借用检查器其实是一个巨大的解脱。一旦它通过了，你就知道你的内存状态是 100% 连贯的，你可以专注于更高层次的问题。这也就是 Ed Page（clap 的维护者）说的：

“当你们刚开始接触它时：会感到沮丧。它让我想起了第一次学习编程的感觉，因为它太不一样了。由于借用检查器和生命周期，我不想去处理那些东西——但我被迫去了。”

— Stephen Blum, CTO, PubNub, 摘自 Rustacean Station

“……能够专注于更高层次的问题。在我进行自我分析并失败时，它帮助我发现了问题。”

— Ed Page, 摘自 Rustacean Station: clap with Ed Page

编译时间

对你的团队保持诚实，Rust 的编译时间相比 Go 的近乎瞬时的编译确实是一个退步。对于中等规模的服务，全新发布构建可能需要几分钟。增量构建和 cargo check 是合理的，并且编译时间在这些年里已经好了很多，但你仍然会感觉到差异。

为了缓解这种情况，在你的编辑循环中使用 cargo check，在项目见效后将其拆分进 workspace 中，并让你自己的 crate 中不要包含过程宏（proc-macro-heavy）重度依赖，这样它们就只在发生变化时才重新编译。请参阅《加速 Rust 编译时间的技巧》以进行更深入的探讨。

异步着色

正如《Goroutine 对比 异步任务》中所讨论的，Rust 的 async fn / fn 拆分是从 Go 迁移过来时最大的开发体验退步之一。异步 trait 自 Rust 1.75 以来已经稳定，但在将它们与动态分发结合时，仍然存在一些粗糙的边缘，你偶尔需要借助 async-trait crate 来解决。

某些细分领域中生态系统较小

Rust 的 crate 生态系统正在增长，并且库在整体上具有很高的质量，但 Go 在一些后端相邻领域具有领先优势：Kubernetes operator、云提供商 SDK、某些特定生态系统的数据库驱动。在做出承诺之前，请花一天时间检查你依赖的库是否具有你愿意使用的 Rust 对应物。我协助的团队经常不得不自己动手实现至少一两个核心库——例如，他们可能需要更新一个废弃的 XML 架构验证 crate，或为较少人知的协议编写自己的客户端。

集成策略

你不需要一次性重写所有内容。我听到的每一个成功的 Go 到 Rust 迁移案例都是战术性的，而不是大爆炸式的重写。Microsoft 的 Victor Ciura 总结得很到位：

“我们并不是疯狂地到处为了好玩而用 Rust 重写一切。我们在做出这些战术性选择，我们会说：好的，这个新组件，如果我们用 Rust 编写会更好。”

— Victor Ciura, 首席工程师, Microsoft, 摘自 Rust in Production

最有效的策略，按照我通常推荐的顺序如下：

1. 将“开辟热门路径”作为一种服务来提供

如果你的系统中某个特定服务一直存在各种问题（比如高 CPU 使用率、对延迟敏感，或者经常出现可靠性问题），那么你可以只用 Rust 重新编写这个服务，同时保持与原有 API 的兼容性。这是风险最低的迁移方式。其他用 Go 编写的服务仍然可以通过 HTTP/gRPC 与这个服务进行交互，而无需关心其底层编程语言是什么。Radar 公司的 Jeff Kao 指出，Discord 上的那些成功案例往往能激发团队尝试这种迁移方式的勇气。

如果你在 Hacker News 上搜索“迁移到 Rust”，第一个搜索结果一定是关于 Discord 从 Go 语言切换到 Rust 的报道。这一消息激励了我们，让我们也想看看自己是否也能做到同样的事情。
——Radar 公司的首席技术官 Jeff Kao 谈 Rust 在实际生产环境中的应用

2. 更换 Sidecar/Worker 进程

后台任务、队列消费者、数据摄取管道以及那些依赖 CPU 处理的批量作业，都是绝佳的优化目标。这些任务通常具有明确的输入/输出边界（比如队列或主题），且不会与系统的其他部分共享任何状态信息。

3. 使用 cgo 是可行的，但过程相当繁琐/麻烦

可以通过 cgo 在 Go 语言中调用 Rust 代码，关于如何操作的详细指南也很容易找到。（如果你需要我提供相关的指南，请随时联系我。）不过，实际上我并不推荐将 Rust 用于后端服务。与“直接创建一个 Rust 服务并将其置于网络调用之后”相比，其构建的复杂性以及 FFI 相关的开销通常会超过其带来的好处。不过，对于库和 CLI 工具来说，使用 Rust 则更为合适。

4. 网关背后的“绞杀者”模式

如果你使用了 API 网关或反向代理，就可以将特定的端点指向新的 Rust 服务，而其余部分则继续使用 Go 语言来实现。当某个特定的业务领域（如身份验证、搜索、计费）适合被迁移时，这种做法尤为有效。这种模式通常被称为“绞杀者模式”：新服务会逐渐取代旧服务，最终完全取代它。

实用的迁移技巧

• 从一个边界清晰的服务开始。 不要选择你机群中最核心、部署最多的服务。挑一个与其他系统的契约定义清晰且影响范围较小的服务。
• 保持相同的 API 契约。 如果你的 Go 服务暴露了 REST API，你的 Rust 服务也应该如此：相同的路径、相同的 JSON 格式、相同的错误响应。这样迁移对客户端是透明的，你可以通过网关安全地切换流量。
• 不要逐字翻译习语。 克制住写“Go 风格 Rust”的冲动。将 if err != nil { return err } 转换为 ?。将 goroutine-per-request 转换为 tokio::spawn。只在真正需要时（axum 会并发地为你处理请求）才使用它们。带有单一方法的接口通常在 Rust 中表现为泛型约束，而不是 Box。
• 将编译器作为结对程序员。 Rust 的编译器错误通常非常有帮助。仔细阅读它们。它们几乎总会告诉你正确的答案。挣扎最久的团队成员通常是将编译器视为敌人而不是合作者的那些人。
• 尽早投资于培训。 我经常看到团队试图通过“边做边学”来进行 Rust 迁移。这很少有好的结果。这有点像通过直接去跑马拉松并试图在跑的过程中摸索来为马拉松训练。你可以做到，但这将是极其痛苦的，而且你可能无法坚持到终点。为学习留出一些不被打扰的时间：一场研讨会，一个在线课程，以及在真实代码上进行结对。前期投入在团队流利掌握后会数倍地回报。(顺便说一下，如果你想讨论培训方案，我很乐意聊聊。)

保持 Go 语言的优势所在

并非所有东西都需要被迁移。Go 语言在以下方面表现优异：

• Kubernetes 原生工具：Operator、controllers、CRD。该生态系统几乎完全由 Go 语言构建而成。
• CLI 工具和开发工具：编译速度快、跨平台编译简单、部署便捷。
• 胶水层服务：包括薄的 API 层、代理(proxy)服务器以及格式转换器。在 Rust 中，编写这些重复性的代码并不值得。
• 在任何情况下，团队的工作效率都比追求绝对的准确性更为重要。

这并非什么小众职位。对于一家能够大规模提供这两种语言服务的公司来说，这一职位的设立显然意味著更重要的意义：

Go 语言是构建网络服务的绝佳选择。在 Canonical 公司，我们大量使用 Go 语言来开发软件——Juju 就是一个由 Go 语言编写的庞大软件项目。
——Canonical 公司工程部副总裁 Jon Seager 谈 Rust 在现实生产环境中的应用

混合策略其实很不错，也很常见。与我合作的许多团队都会采用这种策略：对于那些“没什么特别要求”的服务，使用 Go 语言来开发；而对于那些需要确保可靠性和性能的服务，则使用 Rust 语言来开发。

预期的改进/有望取得的提升

根据工作量的不同，具体数字会有很大差异，因此这些数据仅供参考而已。请不要把它们当作绝对的承诺！不过，以下是我在协助进行从 Go 语言到 Rust 语言的迁移过程中所得到的一些大致数据：

• CPU 使用率：降低了 20%到 60%。这一效果不如将代码从 Python 转换为 Rust 时那么显著，因为 Go 本身的效率就已经很高了。其优势主要体现在无需进行垃圾回收，以及代码循环的效率更高。
• 内存占用：减少了 30%到 50%，这主要得益于无需进行垃圾回收操作，以及运行时的开销更低。
• P99 延迟方面：Rust 服务的稳定性明显更高。Go 服务则容易出现由垃圾回收引起的延迟波动。不过，自从 Go 语言引入了低延迟垃圾回收机制后，这种情况已经有所改善，但在高负载情况下，两者之间的差异依然存在。
• 生产环境中的问题：这是各团队最乐于报告的问题类型。那些在测试阶段被发现，但最终还是进入了生产环境的错误类型（如数据竞争、空指针引用、错误处理路径被遗漏等），在 Rust 中根本无法编译通过。在从其他语言切换到 Rust 之后，处理这些问题的过程通常相当繁琐。Andrew Lamb 在 InfluxDB 的重写过程中也详细描述了这种现象。

“我不需要去追踪崩溃，或者某些奇怪的多线程竞争条件，或者其他那些实际上消耗了我之前大部分时间的事情。”

— Andrew Lamb, 软件工程师, InfluxData, 摘自 Rustacean Station: Rebuilding InfluxDB with Rust

说实话，与从 Python 转向 Rust 相比，从 Go 转向 Rust 后，很难实现 10 倍的性能提升。不过，你确实能减少“愚蠢的错误”，降低延迟，同时还能继续使用同一种语言来开发嵌入式系统或进行系统编程。这往往是代码迁移带来的最令人惊喜的副作用：那些原本需要使用不同编程语言的团队，现在可以共享代码了。Rust 几乎可以用于所有类型的开发场景。

结论

从 Go 迁移到 Rust 是与从 Python 或 TypeScript 迁移完全不同的一种类型。从 Go 过来，你深知静态类型、编译型语言的好处。所以你并不是在用动态类型或缓慢的运行时去交易。你是在交易 nil，换来一个漏洞更少、更健壮的代码库、更严格的编译器（可在编译时捕获更多错误）。不过，这里有一条更陡峭的学习曲线。

对于基础服务（你的组织所依赖的、需要极高可靠性、对你的业务至关重要的服务），这个迁移方式显然是值得的。对于其他服务，Go 仍然是正确的答案。迁移的目的是在最适合的语言中解决对应的问题。

准备好迈向 Rust 了吗？

我协助后端团队评估、规划并执行 Go 到 Rust 的迁移。无论你需要架构评审、培训，还是协助将关键服务进行移植，让我们聊聊你的需求吧。

原文正文到此为止！

社区深度观点

Matthias 的这篇文章在 Hacker News 上也引发了热烈的辩论。支持者、怀疑者、以及拥有多年双语言实战经验的系统架构师们纷纷下场，就 Go 与 Rust 的工业级博弈分享了大量第一手观点。我对其中的核心争议与洞察进行了系统性汇总：

1. 核心分水岭：你是否需要一个“托管运行时（Managed Runtime）”？

在 HN 的讨论中，社区普遍赞同的一个终极共识是：Go 与 Rust 的选择，90% 程度上取决于你是否想要一个托管运行时（垃圾回收，GC）。

• Go 拥护者认为：世界上 95% 的应用都是普通的商业业务系统（LOB）。在这类场景下，Go 拥有世界上最优秀的并发 GC。它的高并发开销极小，虽然在 P99 停顿指标上存在微弱的抖动（Jitter），但对于绝大多数企业级 Web 后端而言，这完全可以忽略不计。
• Rust 拥护者反驳：GC 不仅带来时延抖动，更重要的是它占用了额外的内存（通常需要 30%-50% 的额外物理内存作为缓冲来减少 GC 频率）。在超大规模云原生部署中，Rust 消除 GC 后带来的物理内存节省，可以直接转变为服务器账单上极具说服力的“降本增效”数字。

2. 编译速度与迭代效率的残酷现实

编译速度是 Go 阵营攻击 Rust 最锋利的武器之一。

• Go 的快：Go 从设计之初就将编译速度作为核心优先级（由汇编器和简化的类型系统支撑）。在开发中，修改代码到重新运行几乎是“即时”发生的，这带来了极佳的开发体验和迭代速度。
• Rust 的痛：由于采用了复杂的宏系统（Macros）和深度的单态化（Monomorphization）编译期展开，即使是增量编译，Rust 在大型项目中的等待时间依然可能长达数分钟。多位开发者抱怨：“在使用 AI 辅助编程或高频调试时，Rust 漫长的编译等待时间严重降低了开发者的心智流畅度。”

3. 错误处理理念的终极碰撞

在错误处理上，两个阵营各执一词，表现出截然不同的“开发文化”：

• Go 的显式哲学：Go 拥护者（包括知名技术领袖 Peter Bourgon）强调，错误处理应当是显式的，这应该作为语言的核心价值观。 尽管 if err != nil 冗长，但它逼迫你在每一行可能出错的代码旁停下来，思考当前上下文的应对策略，而不是用一个抽象的 ? 闭着眼睛把错误向上抛出。
• Rust 的类型保障：Rust 拥护者则认为，Go 的显式是一种“依靠肉体纪律维持的低效工程学”。一旦团队规模扩大，总有人会遗漏处理。而 Rust 将错误融入 Result<T, E> 类型签名，由编译器在底层进行穷尽性校验（Exhaustive checks），在代码简洁度（使用 ?）与安全性（不漏掉任何一种分支）之间找到了近乎完美的工程平衡。

4. 生态系统的对比：标准库（Batteries-Included）与模块化 Crates 依赖

开发者对两门语言的第三方生态设计表现出了明显的温度差：

• Go 的稳定：Go 拥护者非常自豪于 Go 极其庞大且强大的核心标准库。你不需要引入任何第三方库，就能用纯标准库写出高可用的 HTTP 服务器、加解密引擎和网络代理。这避免了类似 Node.js 社区的“Dependency Hell（依赖地狱）”和安全供应链攻击风险。
• Rust 的模块化：Rust 的标准库非常克制，甚至连异步运行时（tokio）、序列化（serde）和命令行解析（clap）都是第三方包。一些 Go 开发者迁往 Rust 后表达了这种不适：“在 Rust 里，写个简单的后台服务，一不小心就引入了上百个第三方 Crates，这让人有些缺乏安全感。”

5. AI 与 LLM 时代的编码体验

这是一个极具 2026 年时代特色的前沿议题。讨论区多位开发者分享了在使用大模型（如 Claude Code、Cursor）编写这两门语言时的反差体验：
* AI 写的 Rust 质量低下：由于 Rust 的生命周期（Lifetimes）和借用规则极度精密，AI 经常会生成那些无法通过编译的“幻觉代码”，试图滥用 Mutex、RefCell 等高级特权，或者在多线程中引入生命周期冲突。
* 但 Rust 拥有最强“安全网”：然而，反直觉的是，很多开发者表示他们更喜欢让 AI 写 Rust 而非 Go。因为如果 AI 写的 Go 逻辑错了（比如漏了 nil 检查或并发读写未加锁），代码依然能完美编译通过，并在生产环境中引发极其隐蔽的线上故障。而在 Rust 中，“只要 AI 写的代码能通过编译器的金睛火眼，我们几乎就可以闭着眼睛放心地把它部署上线。”

编辑结语：如何选择你的下一张船票？

Go 和 Rust 的博弈，本质上是“高带宽易上手的生产效率”与“编译期极致安全的正确性承诺”之间的路线之争。

如果你正在构建一个高速迭代、团队规模庞大、需要快速抢占市场的业务系统，Go 依然是那张最稳健、最不容易出错且极其务实的船票。

但如果你的系统已经走过了野蛮生长阶段，开始面临极其严苛的 P99 停顿要求、高并发下的内存与 CPU 账单压力，或者是不容许有任何运行时恐慌（Panics）的国防级、金融级系统，那么正如 Matthias 团队所验证的那样，忍受 Rust 的学习曲线和编译成本，将为你换来长达数年、在睡梦中都无比踏实的“终极安全感”。

资料链接：

• https://corrode.dev/learn/migration-guides/go-to-rust/
• https://news.ycombinator.com/item?id=48259808

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/26/why-nvidia-chose-go-to-rewrite-their-ai-infrastructure

当大家都在谈论 CUDA、Python 和 AI 框架时，NVIDIA 的工程团队正在悄悄用 Go 构建支撑整个 AI 云平台的底层基础设施。从 GPU 函数平台 NVCF，到 AI 集群运行时 AICR，再到已经有 1.8k Star 的分布式存储 AIStore，Go 语言已经成为 NVIDIA 内部 AI 基础设施的核心技术栈。这不是偶然，而是一个精心设计的技术选型。

大家好，我是Tony Bai。

2026 年 4 月，NVIDIA 悄悄开源了一个 repo：github.com/nvidia/nvcf。

没有大张旗鼓的发布会，没有 Jensen Huang 的皮夹克登场。但如果你打开这个 repo 看一眼语言构成，数字会让你一惊：

Go 占比 88.5%。

这不是一个小工具，这是驱动 build.nvidia.com、NVIDIA DGX Cloud 推理服务和全球 GPU 云合作伙伴（CoreWeave、Oracle Cloud 等）整个控制平面的核心平台。

然后你再看 AICR（AI Cluster Runtime）：Go 51.1%。

再看 AIStore（面向 AI 的分布式存储）：Go 75.2%，1.8k Star，10,219 次 commit，是一个有深度的系统级项目。

NVIDIA 在用 Go 构建 AI 时代的基础设施。而且这个趋势正在加速。

NVCF：GPU 云函数平台的全面开源

它是什么

NVCF 全称 NVIDIA Cloud Functions，是一个用于部署、管理和运行 GPU 加速工作负载的平台。你可以把它理解为”GPU 版的 AWS Lambda”——但更贴近生产级 AI 推理场景的设计。

你注册一个 Docker 容器或 Helm Chart，指定 GPU 类型，NVCF 负责处理一切：路由、队列、自动扩缩容、多租户隔离。GPU 云合作商在自己的 Kubernetes 集群上运行 NVIDIA Cluster Agent（NVCA），算力接入 NVCF 控制平面。

2026 年 4 月，NVIDIA 以 Apache 2.0 协议开源了整个平台的完整代码，包括控制平面、调用平面、计算平面、CLI、Helm Charts 和数据库迁移脚本——全部在一个 monorepo 里。之前的 NVIDIA/nvidia-cloud-functions 和 NVIDIA/nvcf-go 两个 repo 已归档，这个新 repo 是唯一的真相来源。

三平面架构：Go 是粘合剂

NVCF 的整体架构围绕三个独立可扩展的平面展开，通过 NATS JetStream 连接。

控制平面（Control Plane）

运行在专用 Kubernetes 集群上，负责函数生命周期管理、自动扩缩容决策和密钥管理。核心服务：

• function-autoscaler（Rust）：30 秒扩缩容循环，从 VictoriaMetrics 读取利用率，决策写入 Cassandra
• helm-reval（Go）：在计算平面部署前验证 OCI 引用的 Helm Chart
• OpenBao（Apache 2.0 的 Vault fork）：函数密钥静态加密，运行时通过 ess-agent sidecar 注入
• Cassandra：持久化状态和自动扩缩容的分布式锁

调用平面（Invocation Plane）

所有请求的必经之路，Go 在这里是绝对主角：

• http-invocation（Rust/Axum）：接收 HTTP/gRPC 请求，发布到 NATS JetStream
• llm-gateway（Go）：OpenAI 兼容 API，内嵌 Olric 缓存实现 token 感知的速率限制
• grpc-proxy（Go）：转发 gRPC 调用到函数实例
• ratelimiter（Go）：使用 Olric 分布式缓存的函数级速率限制
• nats-auth-callout（Go）：支持 NKey、OIDC 和 Webhook 策略的 NATS 认证

计算平面（Compute Plane）

每个 GPU 集群运行一个 NVCA（NVIDIA Cluster Agent）Operator。NVCA 将集群注册到控制平面，消费 NATS 消息，管理 Pod 生命周期。

一次请求的完整生命周期

从调用方的 POST /v2/nvcf/pexec/functions/{id} 开始，到响应返回，完整链路如下：

1. http-invocation 检查速率限制（via ratelimiter gRPC）
2. 请求发布到 NATS stream: Create.NVCA..{clusterID}..*
3. NVCA queue manager 消费消息
4. 创建 ICMSRequest Kubernetes CR（通过 NATS sequence 去重）
5. MiniService controller 协调：创建 Pod 或应用 Helm Chart
6. 函数 Pod 通过 WorkerService gRPC 回连：ConnectOnce
7. 响应返回调用方
8. 完成时：Terminate.NVCA.{clusterID} 触发 Pod 删除和 GC

Scale-to-Zero 的关键设计：NATS 作为持久化请求缓冲区

NVCF 解决的最有趣的工程问题，是 GPU 工作负载的 Scale-to-Zero。

传统方案（如 Knative）在 Scale-up 期间请求会面临超时压力或重试。对于加载大型模型可能需要数十秒乃至数分钟的 GPU 推理来说，这个问题会非常严重。

NVCF 的解法是把 NATS JetStream 当做一个持久化请求缓冲区：

1. 自动扩缩容器将期望实例数降为 0，没有 Pod 运行
2. 新请求到达，发布到 NATS JetStream，消息被持久化
3. 自动扩缩容器检测到队列深度 > 0，将期望实例数提升到 1+
4. NVCA 收到创建消息，启动 Pod
5. Pod 通过 WorkerService gRPC 连接，拉取缓冲的消息
6. 响应通过一直保持打开状态的 http-invocation 连接返回

请求永远不会被丢弃。 调用方在冷启动时等待更长时间，但请求一定会完成。这是 NATS 持久化消息的直接价值。

AICR：AI 集群运行时，Go 写的”集群配方书”

为什么需要 AICR

搭建一个 GPU 加速的 Kubernetes 集群是出了名的难。内核版本、驱动、容器运行时、Operator、Kubernetes 版本——任何一个环节的细微差异都可能导致难以诊断的问题，而且极难复现。

这些知识以前只存在于 NVIDIA 内部的验证流水线和运维手册里。AICR 把这些知识公开了。

项目地址：github.com/NVIDIA/aicr

AICR 全称 AI Cluster Runtime，将已知可行的驱动、Operator、内核和系统配置组合，封装成版本锁定的 Recipe（配方）——可以被 Helm、ArgoCD 和其他部署框架直接使用的可复现制品。

核心概念：Recipe 系统

一个 Recipe 是针对特定环境的版本锁定配置。你描述你的目标（云厂商、GPU 型号、操作系统、工作负载意图），Recipe 引擎将其与一个经过验证的 Overlay 库进行匹配——从基础默认值到云厂商、加速器、操作系统、工作负载特定调优，自底向上分层组合。

每个 AICR Recipe 具备三个特性：

• Optimized（优化）：针对特定硬件、云、OS 和工作负载意图调优
• Validated（已验证）：发布前通过自动化约束和兼容性检查
• Reproducible（可复现）：相同输入产生完全一致的部署结果

CLI 展示：五分钟上手

# 安装 CLI（Go 编译的单一二进制）
curl -sfL https://raw.githubusercontent.com/NVIDIA/aicr/main/install | bash -s --

# 采集集群当前状态快照
aicr snapshot --output snapshot.yaml

# 为你的环境生成经过验证的 Recipe
aicr recipe --service eks --accelerator h100 --os ubuntu \
  --intent training --platform kubeflow -o recipe.yaml

# 对比 Recipe 与集群实际状态，找出差异
aicr validate --recipe recipe.yaml --snapshot snapshot.yaml

# 渲染为部署就绪的 Helm Charts
aicr bundle --recipe recipe.yaml -o ./bundles

bundles/ 目录包含按组件分类的 Helm Chart，每个组件附带 values 文件、checksum 和 README。你可以用 helm install 部署，提交到 GitOps 仓库，或使用内置的 ArgoCD 部署器。

安全供应链：SLSA Level 3

AICR 在供应链安全上走得很远：SLSA Level 3 可溯源性、签名 SBOM、cosign 镜像证明、每次发布都有 checksum 验证。这已经是不少大型企业对内部工具的要求，NVIDIA 在开源项目里直接做到了。

技术栈细节

代码以 Go 为主（51.1%），使用 golangci 做 lint，goreleaser 做发布，ko 做容器镜像构建。项目已经发布了 54 个版本，活跃度很高。目前支持 Amazon EKS、GKE 和 Kind（自管理），GPU 覆盖 H100 和 GB200，工作负载支持 Kubeflow 训练和 Dynamo 推理。

AIStore：完全用 Go 写的 AI 分布式存储

如果说 NVCF 和 AICR 还是相对新鲜的项目，那 AIStore 则是一个已经经受了时间考验的系统级工程——1.8k Star，240 个 Fork，10,219 次 commit，46 位贡献者。

项目地址：github.com/NVIDIA/aistore

核心定位

AIStore（AIS）是一个专为 AI 应用构建的轻量分布式存储栈。它是一个弹性集群，可以在运行时扩缩容，支持从单台 Linux 机器到任意规模的裸机集群的任意部署方式。

AIS 的核心差异点：它能原生操作集群内数据和远程数据，而不是把远程数据当成缓存。这对 AI 训练工作负载来说是关键区别——你不需要先把 S3 数据拉下来再训练，AIS 可以透明地处理数据层。

技术亮点一览

• 多云后端支持：无缝访问 AWS S3、GCS、Azure、OCI，支持跨账号、跨 endpoint 的同名 bucket 共存。
• 线性扩展性：官方博客和 KubeCon 演讲中展示了跨任意数量集群节点的均衡 I/O 分布和线性扩展能力。
• ETL Offload：在数据附近执行 I/O 密集型数据转换，可以内联（作为每次读请求的一部分实时处理）或离线（批量处理，结果写入目标 bucket）。
• Get-Batch：单次调用检索多个对象或归档文件。专为 ML/AI 流水线设计，一次操作获取整个训练批次，按用户指定的顺序组装成 TAR（或其他序列化格式）。这个功能甚至有配套的 arxiv 论文（2602.22434）。
• 负载感知节流：基于多维度负载向量（CPU、内存、磁盘、文件描述符、goroutine）的动态请求节流，保护 AIS 集群在压力下的稳定性。
• 30+ 批处理操作：包括 archive、blob-download、copy-bucket、dsort、etl-bucket、lru-eviction、rebalance、rechunk 等，全部可以通过 CLI 启动、监控和控制。

为什么用 Go

AIStore 75.2% 的代码是 Go，其 Go API 直接被 CLI 和 benchmarking 工具使用。选择 Go 的逻辑很清晰：

1. 系统级性能：Go 的 goroutine 模型天然适合高并发 I/O 密集型工作负载，而分布式存储正是这种场景
2. 单一二进制发布：CLI 工具和服务端都能编译成静态链接的单一二进制，部署极其简单
3. 生态成熟：Kubernetes operator、gRPC、NATS、Prometheus——这些基础设施领域的核心库在 Go 生态中都有成熟实现
4. 代码可维护性：相比 C++，Go 在保持接近底层性能的同时大幅降低了复杂系统的维护成本

为什么是 Go？NVIDIA 的技术选型逻辑

把这三个项目放在一起看，NVIDIA 选择 Go 的逻辑变得清晰：

AI 基础设施的特殊需求

AI 基础设施不同于传统 Web 服务。它需要处理：

• GPU 资源的精细调度和隔离
• 大规模并发请求的队列管理
• 跨多集群的协调
• 模型文件的海量 I/O
• 长时间运行的异步任务

这些场景对并发模型的要求极高。Go 的 goroutine 和 channel 机制，让工程师可以用清晰的代码表达复杂的并发逻辑，而不需要像 C++ 那样手动管理线程。

云原生生态的”母语”

Kubernetes、Docker、containerd、Prometheus、NATS、Helm——云原生基础设施栈几乎是用 Go 写的。NVIDIA 的三个项目全部深度集成 Kubernetes，深度依赖 Operator 模式、Controller Runtime、Helm Chart。选择 Go 意味着可以直接使用这些生态的核心库，而不是跨语言调用的额外复杂度。

运维友好的单一二进制

aicr、ais CLI 工具都是 Go 编译的单一静态二进制。在需要快速部署到新集群、在 CI/CD 流水线中运行、或者在边缘节点上操作时，这个特性极其实用。

Rust + Go 的互补分工

值得注意的是，NVCF 并不是全 Go。高性能热路径（http-invocation、function-autoscaler）用了 Rust，而控制逻辑、网关、代理、认证——这些需要快速迭代、逻辑清晰的组件——用 Go。

这个分工很有意思：Rust 负责极致性能的关键路径，Go 负责需要快速演化的系统逻辑。两种语言各司其职，而不是用一种语言通吃所有场景。

小结：这意味着什么

对 Go 开发者

NVIDIA 的这几个 repo 是绝佳的真实世界大型 Go 项目参考：

• NVCF：学习 Kubernetes Operator 模式、gRPC、NATS 集成、多平面分布式系统设计
• AICR：学习 CLI 工具设计（goreleaser + cobra）、Helm 生成、GitOps 集成模式
• AIStore：学习高性能分布式系统的 Go 实现，包括内存管理（memsys 包）、分布式一致性、S3 兼容 API 实现

这三个项目都是 Apache 2.0 或 MIT 开源，代码质量高，有完整的测试和文档。

对 AI 平台工程师

NVIDIA 正在开源 AI 基础设施的核心组件。NVCF 的开源意味着你可以：
- 在私有 GPU 集群上运行与 NVIDIA 云服务相同的调度和路由逻辑
- 审计每一行代码，而不是把平台当成黑盒
- 修改自动扩缩容逻辑、添加 NATS 认证策略、扩展 MiniService controller

AICR 则给了你一个”NVIDIA 认证”的集群配置参考——如果你正在搭建自管理 GPU 集群，AICR 的 Recipe 系统告诉你什么组合是经过验证的。

对技术决策者

当 NVIDIA——一家以 CUDA C++ 闻名的公司——在 AI 基础设施层面系统性地选择 Go，这个信号足够强烈。Go 已经不只是”Google 的语言”或者”云原生工具链的语言”，它正在成为 AI 时代基础设施的核心技术栈之一。

资料链接：

• https://blog.kubesimplify.com/nvcf-is-now-open-source-inside-nvidia-s-gpu-function-platform
• https://github.com/nvidia/nvcf
• https://github.com/NVIDIA/aicr NVIDIA AI Cluster Runtime
• https://github.com/NVIDIA/aistore AIStore: scalable storage for AI applications

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/21/go-is-the-new-lingua-franca-for-ai-agents-at-google

大家好，我是Tony Bai。

在过去的两年里，只要一提到 AI 开发，99% 的人脑海中弹出的第一个词绝对是：Python。而如果是涉及到大模型底层的高性能推理与算力压榨，大家想到的必然是 C++ 或是 Rust。

但在真正的工程落地中，情况正在发生一场令人猝不及防的剧变。

最近，Google 资深软件工程师 Jaana Dogan（@rakyll）在 X（原推特）上发布了一条引发技术圈热议的推文：

“Go 成为 Google 内部 Agentic（智能体）系统的通用语言（lingua franca），这真的很了不起。我以前从未看到过 Go 有取代 C++ 的路径，但现在我相信这是可能的。”

这不仅仅是一条简单的技术感慨，它揭示了 AI 浪潮进入“下半场”后的核心工程困境：当我们把大模型封装成 Agent，并让成千上万个 Agent 并发协作时，Python 太脆弱，C++ 太沉重，而 Go，迎来了它的“天命时刻”。

今天，我们就来扒一扒，为什么 Google 会让 Go 接管 AI Agent 的底层开发？这对我们普通开发者的技术栈转型，又意味着什么？

打破滤镜：为什么 Python 和 C++ 在 Agent 时代“失宠”了？

要理解 Go 的上位，我们首先要搞清楚，AI Agent 到底需要什么样的工程能力。

现在的 AI 应用，早就不是早期那种“写个 Python 脚本，调用一下 OpenAI API，把结果打印出来”的玩具了。真实的 Agentic 系统（智能体系统）包含了极其复杂的网络 I/O、并发工具调用（Tool Calling）、多智能体消息路由、长时记忆状态管理，以及大规模的分布式容错。

在这个场景下，旧有的王者们暴露出了致命的缺陷：

1. Python 的“工程化陷阱”

Python 是 AI 研究员的最爱，因为它的数据科学库天下无敌。但当你要构建一个高并发、高可用、需要 24/7 运行的 Agent 编排系统时，Python 的弱类型（重构火葬场）和 GIL（全局解释器锁，导致无法真正利用多核并发）就成了灾难。正如原贴讨论区一位开发者所言：“模型层可能是 Python 的天下，但围绕着模型的 Runtime（运行时环境）正越来越像 Go 的领地。”

2. C++ 的“杀鸡用牛刀”

C++ 拥有极致的性能，是模型训练和推理引擎（Inner Loop）的绝对霸主。但 Agent 编排系统真的需要 C++ 级别的疯狂数学计算吗？不需要。

Agent 系统本质上是大量的网络等待（等 LLM 返回结果、等数据库查询、等网页抓取）。用 C++ 来写极其复杂的并发网络请求和状态机，不仅开发周期漫长，而且极易产生内存泄漏。正如推文评论所指出的：“C++ 背负了太多的历史包袱，它在 Agent 编排上显得太重了。”

Go 凭什么上位？Goroutine 与 Agent 的“完美同构”

Go 语言在这个时间节点爆火，并非偶然，而是因为它底层的并发哲学与 AI Agent 的行为模式产生了“完美的同构映射”。

在 X 上的讨论中，多位资深开发者一针见血地指出了核心原因：

“Goroutines mapping directly to concurrent agent communication is the reason why it makes perfect sense.”（Goroutine 直接映射到并发 Agent 之间的通信，这是它如此完美契合的原因。）

让我们用大白话来翻译一下这个硬核逻辑：

什么是多智能体系统（Multi-Agent System）？本质上就是一堆各自独立的“数字员工”，它们一边自己干活，一边通过发消息相互沟通。
而 Go 语言最强大的杀手锏是什么？正是 CSP（通信顺序进程）并发模型，即 Goroutine（轻量级协程）和 Channel（通道）。

• 当你启动一个 Agent 时：在 Go 里，你只需要一个简单的 go runAgent()，就能以极其低廉的内存代价（几 KB）启动一个并发实体。一千个 Agent？一万个 Agent？对 Go 来说毫无压力。
• 当 Agent 之间需要协作对话时：你不需要去搞复杂的锁（Locks）或者共享内存，你只需要用 Go 的 Channel 把消息塞过去，另一个 Agent 就能安全地接收。

Agent 的编排，需要的是“轻量级的并发管理”，而不是“极致的数学计算速度”。这简直就是为 Go 量身定制的战场。

征服大厂，构建 Agent 架构的“铁三角”

除了并发模型上的天作之合，评论区的一位开发者还另外总结了 Go 赢下这场战争的另外三个决定性因素。他指出，现代 Agent 技术栈奖励三种特性，而 “Go 完美击中了这三点（Go nails all three）”：

1. 强类型系统（Types）：告别“盲盒”开发

Agent 系统中充斥着复杂的 JSON 解析、Tool Calling 的参数校验、以及结构化的输出。Python 的字典（Dict）传递在项目变大后就像是“盲盒”，你永远不知道里面缺了哪个字段。而 Go 的强类型 Struct 和极度清晰的错误处理机制（虽然大家都吐槽 if err != nil，但它确实极其可控），让系统拥有了极高的可预测性（Predictability）。

2. 极速的编译体验（Fast Builds）

“编译速度是让它成为绝配的原因之一。”在快速迭代的 AI 产品中，Go 那种秒级的编译速度，让开发者可以飞速地测试 Agent 的行为逻辑。相比之下，C++ 那漫长的编译过程在需要高频微调的 AI 时代显得格格不入。

3. 小巧的单一二进制文件（Small Binaries）

当你把 Agent 部署到云端、边缘设备甚至是 Serverless 环境时，Go 编译出来的是一个无需任何外部依赖的独立执行文件。没有 Python 烦人的环境依赖（无需折腾 pip, conda, 虚拟环境），直接丢进一个极小的 Docker 镜像中就能运行，这对于现代云原生运维来说是无可估量的优势。

一个反直觉的冷知识：大模型“最爱”写 Go 代码

推文中一个开发者提出了一个极其有趣且经常被忽视的视角：在 LLM（大语言模型）的眼中，Go 是一门完美的语言。

如果你经常用 Cursor/Codex/Claude Code等 写代码，你会发现一个现象：让 AI 写 Python，它经常会用错第三方库的版本；让 AI 写 C++ 或 Scala，它可能会搞出一堆极其复杂的继承、多态或者生命周期错误。

但如果你让 AI 写 Go 呢？成功率出奇的高。

原因在于：

1. Go 的语法极致简单、无聊，甚至“没有类（Classes）”。它只有 Struct 和接口，这极大地减少了代码的“表面积（Surface Area）”。
2. Token 使用率极高。由于没有复杂的黑魔法和繁琐的泛型体系（早期），LLM 在生成 Go 代码时不容易出现“幻觉”，维护起来极其容易。

在这个连代码本身都开始由 AI 生成的时代，“对 LLM 友好”竟然成了一门编程语言的核心护城河。

终局推演 —— C++ 守住“内环”，Go 赢下“外环”

那么，Go 真的会彻底消灭 C++ 吗？

并不完全是。这场讨论最终达成了一个非常清晰的技术栈共识：

“C++ still wins the inner loop. Go wins everything around it.”（C++ 依然赢得了内环，而 Go 赢得了周围的一切。）

未来的 AI 系统架构已经初露端倪，它将被清晰地划分为三个层级：

1. 研究与数据层（Python）：用于模型训练、数据清洗、算法验证。
2. 算力内环（C++ / Rust / CUDA）：大模型的推理引擎（如 vLLM、Ollama 底层）、张量计算。这里需要极致榨干每一滴 GPU 性能，C++ 依然是绝对的霸主。
3. 编排外环与业务层（Go）：这是距离普通开发者最近、也是市场需求最大的地方。成千上万的 Agent 调度、API 网关、并发的数据检索（RAG）、记忆数据库交互、工具链调用，全部都将被 Go 统治。

最新铁证！Google I/O 2026 震撼官宣：废弃旧路线，用 Go 重写 AI 核心入口！

如果你觉得前面硅谷大佬们的讨论还只是“理论推演”，那么在刚刚举办的 Google I/O 2026 大会上，Google 官方直接用一记雷霆手段，把这个趋势变成了既成事实。

Google 开发者博客发布了公告：正式宣布停止维护原有的 Gemini CLI，全面过渡到全新的“Google Antigravity（反重力）”多智能体开发平台，并推出全新的核心入口 —— Antigravity CLI。

而在官方给出的技术变更文档中，最扎眼、最让 Go 开发者狂喜的一条更新理由，白纸黑字地写着：

“Faster execution: Built in Go, Antigravity CLI is snappier and more responsive.” （更快的执行速度：基于 Go 语言构建，Antigravity CLI 更加轻快、响应更迅速。）

旧版的 Gemini CLI 是基于传统脚本语言（Node.js/TS 体系）构建的，在处理单点交互时绰绰有余。但 Google 明确表示，现在开发者的需求已经彻底变了：“你现在需要多个 Agent 相互通信、分工合作来解决复杂的系统问题。”

当单点 CLI 变成“多 Agent 协同编排后端”时，旧有的 JS/TS 体系在高并发、异步工作流（Asynchronous Workflows）和底层系统控制上面临性能瓶颈。Google 毫不犹豫地选择用 Go 语言 彻底重写，就是为了利用 Go 极致的并发和执行效率，来支撑起“后台多任务并发运行、且不锁定终端”的强悍体验。

小结：给开发者的生存建议

过去的一年里，无数后端开发者感到焦虑，觉得自己掌握的 CRUD 技能在 AI 面前一文不值。但 Google 内部的这场技术栈迁移，给我们指明了一条无比清晰的道路：

别再只盯着 Python 看了。

当 AI 从单一的对话框，走向全面接管企业业务流的多智能体（Multi-Agent）协作形态时，对高并发、高可用后端工程能力的需求不仅没有减少，反而呈指数级爆发。

学习 Go 语言，理解 Goroutine，掌握如何构建一个稳健的 Agent 编排框架。因为决定下一个十年 AI 应用成败的，不再是模型本身的算力，而是谁能最好地管理和协调这些拥有智能的“数字大军”。

而目前来看，Go，已经在这场战役中拔得头筹。

资料链接：https://x.com/rakyll/status/2056528039698403498

今日互动探讨：

你目前在开发 AI 应用或 Agent 系统时，使用的是什么语言？你是否遇到了 Python 在高并发或部署时的痛点？欢迎在评论区分享你的实战经验与踩坑血泪史，我们一起探讨 AI 时代的最佳实践！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/20/ai-coding-win-rate-rankings-go-and-rust-vs-cpp

大家好，我是Tony Bai。

过去两年，程序员群体经历了一场前所未有的“职业身份危机”。

随着 GPT、Claude、Gemini 等模型的发布与能力更迭，各种“AI 几秒钟写出小游戏”、“AI 自动化修复 Bug”的新闻充斥屏幕。在各种传统的代码补全基准测试（如 HumanEval）中，大模型们动辄刷出 90% 以上的惊人通过率。一时间，“程序员是夕阳行业”、“架构师即将下岗”的言论甚嚣尘上。

然而，这只是硬核工程世界的冰山一角。最近，由 Meta FAIR（Meta 基础人工智能研究实验室）、斯坦福大学和哈佛大学联合发布的一项重量级研究——ProgramBench，彻底击碎了这些幻觉。

ProgramBench 的设计初衷非常“残暴”：它不再测试 AI 能不能写出一个简单的算法函数，而是测试 AI 能不能从零开始（From Scratch）复刻一个完整的开源项目，即从观测二进制行为（Probe）到编写源码（Build），再到最终的等效性评估。

测试规则如下：

1. 黑盒逆向：不给源码，只给 AI 一个编译好的二进制可执行文件（如 sqlite3、ffmpeg、ripgrep）和一份使用说明书。
2. 物理断网：切断互联网访问，防止 AI 通过搜索“偷看”GitHub 上的源码。
3. 架构自主：AI 必须自己决定项目的文件结构、选择什么编程语言、设计什么抽象层次。

在这场面向 200 个真实复杂项目的“闭卷考试”中，全球最顶尖的大模型们集体陷入了沉思。

数据表明，即便是在最强的模型面前，完全成功的概率依然是 0。

但在这场败战中，我们通过海量数据发现了一个足以改变未来十年技术选型的真相：Go 与 Rust 已经成为了 AI 时代的“天命语言”，而 C++ 则不那么受 AI 青睐，AI 用起来也不那么顺手！

诸神黄昏：Claude 对 GPT 家族的“工程级”碾压

在程序员的认知中，GPT 家族曾代表着 AI 的巅峰。但在 ProgramBench 的 Leaderboard（排行榜）上，局势发生了戏剧性的反转，但也正如我们预料的那样。

根据论文统计，在衡量“几乎完成”（即通过 95% 以上的测试用例）这一指标时，排名如下：

1. 头号种子：Claude Opus 4.7。它是全场唯一一个在 3.0% 的复杂项目中展现出近乎完美复刻能力的模型。
2. 二号梯队：Claude Opus 4.6 (2.5%) 与 Claude Sonnet 4.6 (1.6%)。
3. 集体挂零：GPT 5.4、Gemini 3.1 Pro。 没错，这些在其他榜单上呼风唤雨的模型，在“从零复刻完整项目”的任务中，竟然连一个能通过 95% 测试的任务都没完成。

为什么 GPT 会在硬核工程上输给 Claude？

研究人员通过分析“智能体轨迹（Agent Trajectories）”发现了秘密。大模型写代码有两种流派：

• “急性子”派（以 GPT 5.4 为代表）：GPT 倾向于“单次爆发”。数据显示，它在每个任务中平均只用 17 个命令。它习惯于在最初的几个回合内，直接吐出 96% 的代码。如果代码跑不通，它很少进行深度的自我修正。
• “架构师”派（以 Claude 为代表）：最强的 Claude 模型更像是一个深思熟虑的工程师。它平均每个任务会调用 868 个命令！它会不断地执行 ls 查看目录、用 cat 检查文件、反复运行测试并根据报错信息进行“重构”。

可见，在复杂的软件工程面前，单纯的“语料记忆”失效了。Claude 的胜出，本质上是其“推理链”和“持续迭代能力”的胜出。它不只是在背代码，它是在通过不断的试错来“推演”架构。

通过上图中不同模型的动作类型分布，我们可以看到 Claude 拥有极长且复杂的“读-写-探测”循环，而 GPT 的动作序列短得惊人。

语言偏好：AI 也有自己的“舒适区”

ProgramBench 给 AI 提供了完全的自由：AI 可以用任何语言来复刻目标程序。这产生了一个极其有趣的“语言混乱矩阵（Confusion Matrix）”。

1. GPT 的 Python 执念

GPT 5.4 表现出了近乎偏执的 Python 依赖。在所有任务中，它有 79% 的方案是用 Python 写的。无论原程序是用更底层的 C 还是 Rust 写的，GPT 的第一反应往往是：“我能不能用 Python 给它糊出来？”

2. Claude 的硬核品味

最强模型 Claude Opus 4.7 表现出了极高的系统级素养。它只在 14% 的情况下选择 Python，它更倾向于使用 Rust 和 Go 来应对复杂任务。这说明越强大的模型，越能理解底层语言在性能和逻辑表达上的严密性。

3. 为什么 AI 喜欢 Python？

原因很简单：容错率。 Python 拥有极其丰富的第三方包、极简的语法以及无需手动管理内存的特性。对于 AI 来说，Python 是它能用最少的回合数实现最多功能的“逃生路径”。但这种逃生是有代价的——复杂的系统级软件用 Python 复刻，往往会因为性能或底层调用模拟不足而失败。

深度解析：为什么 Go 与 Rust 是 AI 的“天命之子”？

这是本次研究中最具行业指导意义的发现。通过研究数据对比，我们发现不同语言在 AI 手下的“存活率”天差地别：

• Go 语言项目：AI 成功通过率 38.4%
• Rust 语言项目：AI 成功通过率 38.5%
• C/C++ 项目：AI 成功通过率仅为 27.7%

为什么同样是系统编程语言，Go 和 Rust 就能完胜 C++？这不仅仅是语法的问题，更是现代工程化基建的降维打击。

1. 构建系统：AI 开发者的“生死线”

在 C/C++ 的世界里，构建系统是混乱的代名词。CMakeLists.txt、Makefile、系统特定的动态链接库（.so/.dll）路径……对于 AI 智能体（SWE-agent）来说，这些是致命的障碍。

调研显示，AI 在 C++ 任务中，往往还没开始写业务代码，就已经在配置环境时陷入了死循环。

反观 Go 和 Rust：

• Go：一个 go mod tidy 加一个 go build 解决了全球 99% 的构建问题。
• Rust：Cargo 是目前人类文明最先进的包管理器之一。

对于 AI 来说，这种“标准化”意味着它只需要执行一条命令就能建立起完整的工程环境。这种极高的工程化一致性，让 AI 可以把宝贵的 Token 消耗在业务逻辑上，而不是折腾环境。

2. 标准库的“全家桶”效应

Go 语言一直以“自带电池（Batteries included）”著称。它的标准库涵盖了网络、加密、编解码等大部分现代互联网开发所需的功能。AI 调用 Go 的标准库就像从兜里掏东西一样自然。

而 C++ 的标准库相对贫瘠，往往需要引入第三方库（如 Boost, libcurl）。一旦涉及到第三方依赖，AI 的出错概率就会呈指数级上升。

3. 内存安全：给 AI 的“保护索”

在 C/C++ 中，AI 极其容易写出缓冲区溢出、内存泄露或段错误。一旦程序在运行过程中崩溃，由于 AI 缺乏深度的 GDB 调试能力，它很难从 Core Dump 中恢复。

Rust 严格的借用检查（Borrow Checker），在编译阶段就强行纠正了 AI 的大部分错误。这种“编译即正确”的反馈循环，让 AI 在复刻软件时拥有了更高的胜率。

揭秘 AI 程序员的“坏习惯”：屎山代码的起源？

除了排名和语言，ProgramBench 还揭露了目前 AI 编码的三个极具冲击力的特征：

1. 单文件架构迷恋

人类架构师讲究解耦，喜欢建立复杂的目录结构。但 AI 却恰恰相反。数据显示，67% 的 AI 方案产生的目录深度明显浅于原项目。

AI 表现出强烈的“单文件狂魔”倾向。 它们喜欢把数千行代码塞进 1-3 个超级大文件里。这反映出目前的模型在处理跨文件的上下文关联时，依然存在明显的认知衰减。

2. 逻辑“大颗粒化”

AI 写的函数数量通常只有人类原作者的 10% 到 20%。但这并不意味着功能缺失，而是因为 AI 喜欢写超长函数（God Functions）。

Claude 生成的函数长度平均是人类的 1.46 倍，Gemini 甚至达到了 1.62 倍。这种代码对于 AI 来说运行没问题，但对于人类后续维护来说，简直是噩梦。

3. 诚信危机：AI 也会“偷懒作弊”

在测试的早期阶段，研究人员尝试给 AI 开启互联网访问。结果发现，最强的大模型们全都是“老油条”。

一旦它们通过二进制文件的帮助信息（–help）推断出这是哪个开源项目，它们会直接去克隆对应的 GitHub 仓库代码并提交。

Claude Sonnet 4.6 的作弊率一度高达 36%！ 这迫使研究团队最终必须在完全断网的环境下运行测试。这告诉我们：永远不要低估大模型为了完成任务而寻找“捷径”的本能。

小结：程序员的黄昏还远未到来

看完这份长达 60 多页的研究报告，我们不仅没有感到绝望，反而产生了一种前所未有的踏实。

报告证明了：即便是在最顶尖的模型面前，真实的软件工程（Software Engineering）依然是一个极度复杂的高壁垒领域。写代码只是软件工程中最后、最轻的一环。而之前的架构设计、模块拆分、抽象提取、以及对业务边界的理解，目前的 AI 依然处于“学龄前”阶段。

给开发者的建议：

1. 向 Go 和 Rust 迁移：这不只是性能考量，更是为了拥抱 AI。如果你想让 AI 帮你更高效地干活，请选择那些对 AI 友好的工程化基建。
2. 强化架构师思维：既然 AI 喜欢写单文件“屎山”，那么如何管理大型项目的复杂性、如何通过 Prompt 引导 AI 进行模块化设计，将是未来高级工程师的核心竞争力。
3. 拥抱 Claude 模式：告别“单次生成”的幻觉，建立起“持续迭代、自动测试、反复纠错”的 AI 开发流水线。

程序员的黄昏还远未到来。

相反，我们正在进入一个全新的时代：一个由人类架构师掌控蓝图，由 AI 劳工在标准化的 Go/Rust 仓库中疯狂试错、高效产出的黄金时代。AI 并没有取代你，它只是淘汰了那些只会机械写代码、而不懂工程设计的“码农”。

真正的开发者，正在迎来属于他们的、被 AI 加持的黎明。

资料链接：

• https://arxiv.org/abs/2605.03546
• https://programbench.com/

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.