本文永久链接 – 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/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/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. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/18/go-performance-optimization-over-rust-rewrites

大家好，我是Tony Bai。

近年来，如果你常年混迹于国内外各大技术社区，你一定会感受到一种近乎狂热的“政治正确”：带垃圾回收（GC）的语言都有原罪，万物皆可（且应该）用 Rust 重写。

从底层基础设施到上层业务逻辑，无数团队在遇到性能瓶颈时，脑海中蹦出的第一个念头就是：“Go/Java 搞不定了，由于 GC 停顿的存在，我们必须换 Rust 乃至 C++ 来重构核心模块。”

但这真的是解决性能问题的唯一出路吗？

最近，几位硅谷顶级的技术大佬——前 Tailscale CTO David Crawshaw、开源时序数据库 VictoriaMetrics CTO Aliaksandr Valialkin，以及资深底层代码大牛 Stewart Lynch，在 X（原推特）上掀起了一场关于“现代软件复杂性与性能优化”的讨论。

仔细研读他们的观点后，我得出了一个可能有些“反直觉”的结论：

对于绝大多数商业项目而言，盲目追求去 GC 化和无脑 Rust 重写，是一场灾难。真正顶级的性能优化，往往只需要对那 1% 的“热路径”动刀。

今天，我们就来揭秘这层信息差，看看顶级架构师是如何在不增加心智负担的前提下，把带 GC 的 Go 语言性能压榨到极致的。

现代软件最大的毒瘤：“不必要的复杂性”

为什么我们总是忍不住想要用极其复杂的语言或架构去重写现有的系统？

Stewart Lynch 在讨论中一针见血地指出了现代软件工程的通病：“Everything that’s wrong with modern software can be summed up in two words: Unnecessary Complexity”（现代软件所有的毛病，可以用两个词来概括：不必要的复杂性）。

这背后其实隐藏着一个程序员群体独有的心理学陷阱。

Lynch 解释道：“程序员这个群体有一个特殊的问题——我们往往是因为‘享受解决复杂问题’才选择这个职业的。我们热衷于理解极其复杂的东西并让它运转起来，我们是人类历史上最复杂结构的构建者。正因为如此，我们在任何地方都在寻找与复杂性搏斗的机会，即使在那些本该追求极简的地方。”

这就解释了为什么很多团队在面对一个简单的 CRUD 业务或者中等并发的微服务时，会毫不犹豫地引入极高门槛的语言（比如有着严苛借用检查器的 Rust）或是过度设计的服务网格。

因为“复杂，让人觉得高级”。

但结果是什么？

业务逻辑被切割得支离破碎，新员工入职需要花费两三个月才能看懂生命周期和指针所有权，团队的迭代速度断崖式下跌。你以为你在优化系统的性能，实际上，你在制造一场长期的维护灾难。在这个过程中，你消耗了大量的公司预算，仅仅是为了解决那些“想象中的未来问题”。

记住架构设计的第一法则：复杂性是优秀软件的死敌。

你的 99% 代码根本不需要瞎折腾

既然复杂性是死敌，那性能问题怎么办？难道我们就任由 GC 导致程序卡顿吗？

这时候，前 Tailscale CTO David Crawshaw 抛出了一个极具颠覆性的观点。他指出，整个行业现在正把海量的资源倾注到像 Rust 这样没有 GC 的程序中，但大家忽略了一个极其残酷的统计学事实：

“Almost all your code paths are cold and GC is net positive. 1% of your code is performance sensitive. Don’t create GC pressure there.” （你几乎所有的代码路径都是‘冷’的，在这些地方 GC 带来了纯粹的正向收益。只有 1% 的代码对性能真正敏感。你只需要不在那 1% 的地方制造 GC 压力就行了。）

什么是“冷代码”？

配置解析、路由分发、错误处理、数据库连接初始化、日志记录……在一个庞大的工程中，这部分代码占据了 99% 的体积。它们对微秒级的延迟根本不敏感。

对于这 99% 的代码，使用 Go、Java 甚至 OCaml 这样带有Full runtime GC的语言，是巨大的恩赐。GC 解放了程序员的大脑，让你不需要像写 C/C++ 或 Rust 那样，在写每一行代码时还要在脑海里进行“部分编译时规划（Partial compile-time planner）”。它让你可以把全部精力聚焦在“业务逻辑”本身。

人类解决复杂问题的能力，在不被内存分配分心时，才能发挥到极致。

为了那 1% 真正需要榨干 CPU 周期的核心逻辑，去强迫整个团队在剩下 99% 的冷代码中也要与内存所有权作斗争，这在商业 ROI（投资回报率）上是极其荒谬的。

这就是所谓“不要为了 1% 的醋，去包 99% 的饺子”。

VictoriaMetrics CTO 的 1% 极简榨干指南

好，逻辑理顺了：我们决定坚持使用 Go 语言，享受它极高的开发效率和并发优势。但我们确实遇到了那 1% 的核心瓶颈——比如高频交易的核心撮合引擎、时序数据库的底层写入循环。这部分代码极其吃 CPU，且 GC 带来的 STW（Stop The World）让人无法忍受。

不换语言，怎么破局？

别急，让我们来看看目前世界上性能最强悍的开源时序数据库之一：VictoriaMetrics 的做法。这个数据库完全是由 Go 语言编写的，但在各项 Benchmark 性能测试中，它经常把一众 C++ 和 Rust 写的时序数据库按在地上摩擦。

它的 CTO，Aliaksandr Valialkin 在这次讨论中，大方地分享了他“降维打击”般的优化路径。我将他的经验，结合各位大牛的讨论，为你整理成了以下三步走的“实操密码”：

放弃盲猜，用 Profiler 精准定位热路径（Hot Paths）

你永远不可能靠“直觉”找到性能瓶颈。Aliaksandr 强调，Go 语言拥有极度强大的内置 Profiler（pprof）。不要一上来就重构，先让程序跑起来，打入真实流量，然后用 pprof 精准定位出那消耗了 80% CPU 和大量内存分配的 1% “热路径”究竟在哪几个函数里。

这 1% 的代码，代码量往往极小，寻找它们并不困难。

在热路径中“完全移除”内存分配（Zero Allocation）

这是 Go 性能优化的核心灵魂。Aliaksandr 的原话是：“This is how I optimize programs written in Go – by removing memory allocations from hot paths…”。

只要你在热路径中不产生新的对象（不触发 malloc 和堆分配），垃圾回收器（GC）就根本不会被唤醒。没有分配，就没有垃圾；没有垃圾，就没有 GC 压力和停顿。

开启“逃生舱”：使用预分配与 Arena 机制

既然热路径不能分配新内存，那需要处理海量数据怎么办？大佬们给出了三种在 Go 中模拟底层语言内存管理的“逃生手段”：

• 预分配大块内存（Pre-allocations）：
  正如 David Crawshaw 所举的例子，你可以在 Go 中一次性分配一个巨大的数组，比如：var x = make([]struct{…}, 1e6)。
  这只产生一次大分配，然后你完全可以利用自己的算法，在这个预先分配好的内存块中进行指针的滑动和复用。对于 GC 来说，这只是一个单一的连续指针，GC 扫描它的成本极低，既能实现高并发，又极大地降低了 CPU 消耗。

• 对象池机制（sync.Pool）：
  对于频繁创建和销毁的小对象，不要让它们落入 GC 的魔爪。利用 sync.Pool 将它们缓存起来，反复复用。

• 请求作用域内存竞技场（Arenas）：
  Aliaksandr 提到了在处理网络请求时极其高效的 Arena 概念。在这个模式下，与单次 Request 相关的所有小对象分配，都在一个预先分配好的大块 Arena 中进行。当请求结束时，不需要逐个去释放对象，而是直接清空（free）整个 Arena。这几乎达到了和 Rust 一样零开销的内存清理效果，但代码写起来依然是熟悉的 Go 语法。

对 99% 的代码保持克制

当你在那 1% 的热路径里用尽了上述像 C 语言一样的“脏活累活”后，请立刻停手。

让程序剩下的 99% 保持最地道（Idiomatic）、最简单、最具可读性的 Go 代码。让 GC 去接管它们。

你会神奇地发现：你的程序不仅拥有了媲美 C++/Rust 的极致性能，同时你的团队依然保持着原本极高的业务迭代速度。

小结——顶级工程师与普通码农的终极分水岭

回顾这几位大佬的讨论，其实核心只指向了一个词：克制（Restraint）。

普通工程师总是试图寻找一种“银弹”——希望换一种时髦的语言，就能一劳永逸地解决架构、性能和内存安全的所有问题。他们沉迷于构建极其复杂的抽象体系，试图用技术上的炫技来掩盖业务上的平庸。

而真正顶级的架构师，深知商业的本质和团队运作的规律。他们懂得：

1. 好的设计，就是当你不能再拿走任何东西的时候。 （正如评论区一位开发者所说：Good design is when you keep taking away things until you cannot take away any more.）
2. 永远不要在全局引入复杂性。 遇到性能问题，先用监控定位，然后把性能敏感的那 1% 的代码隔离出来，在这个小黑盒子里用最极客的方式优化，最后把它严丝合缝地封装好。
3. 拥抱不完美但高效的工具。 不要嫌弃 GC，懂得如何与 GC 和谐共处，才是真正的大师。

如果下次你的团队里，再有人因为某个接口慢了 10 毫秒，就嚷嚷着要用 Rust 把整个几十万行的后端服务重写时，请把这篇文章甩到他的脸上。

告诉他：“去把 pprof 打开，把那 1% 循环里的临时变量给我复用了，然后早点下班回家。”

资料链接：

• https://x.com/valyala/status/2055725885035045234
• https://x.com/stewartlynch8/status/2055322205563617516
• https://x.com/davidcrawshaw/status/2055288855792955511

今日互动探讨：

在你的职业生涯中，是否经历过为了追求所谓的“极致性能”或“极客审美”，而导致整个项目陷入“过度复杂化（Over-engineering）”灾难的时刻？或者，你在使用 Go 语言时，有什么私藏的“热路径”压榨技巧？

欢迎在评论区留言和我探讨，我们一起对抗现代软件的“过度复杂病”。 （如果你觉得这篇文章打破了你的认知，别忘了点赞转发，让更多挣扎在重构边缘的兄弟们看到！）

还在为写 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/04/15/cpp-community-debate-productivity-revolution-vs-complexity

大家好，我是Tony Bai。

如果你把编程语言比作工具，Go 是一把极简的手术刀，精准且克制；Rust 是一套带智能传感器的外骨骼装甲，严苛且安全。

而 C++ 呢？它更像是一把在过去四十年里不断被加挂零件的、超重型复合瑞士军刀。

最开始，它只有刀片和叉子；后来，它加了锯子、剪刀和钳子；再后来，它甚至被塞进了一套显微镜和一支激光笔。在开发者眼里，它是能解决世间一切难题的万能神兵，但也是一个重到让你拿不稳、甚至随时可能切到自己手指的“庞然大物”。

但就在前几天，r/cpp 这个拥有近 10 万 C++开发者的顶级社区里，一篇名为《现代 C++ 是让我们更高效了… 还是更复杂了？》的帖子，引发了一场深度大讨论。

发帖人发出了灵魂拷问：

“C++20/23 给我们带来了 Ranges、协程（Coroutines）、Concepts、Modules……这些新特性真的很酷，我也在用。但我总在想，我们是不是在用这些东西吓跑新人的同时，眼睁睁地看着老代码库永远冻结在 C++98？现代 C++ 对生产力来说，到底是一场革命，还是在原本已经足够复杂的巨兽身上，又叠加了一层复杂性？”

这篇帖子，精准地戳中了每一个 C++ 开发者心中最深的困惑。短短一天，就吸引了上百条充满血泪与思考的评论。

今天，我们就来复盘这场顶级的社区大讨论，看看这柄“瑞士军刀”在疯狂“堆料”的背后，到底藏着怎样的挣扎、分裂与反思。

分裂的社区：C++98 遗老、C++17 中坚与 C++23 先锋的“平行宇宙”

在这场大讨论中，我仿佛看到了 C++ 社区三个泾渭分明的平行宇宙。

宇宙一：永远的 C++98/11 ——“能跑就行，别动！”

评论区里，点赞最高的一派观点，充满了对“存量代码”的敬畏与无奈。

一位开发者吐槽道：

“我在太多项目里因为各种原因被迫使用旧标准，以至于我已经懒得去关心最新的特性了。我感觉很多专业场景就是这样：我们用着‘穴居人 C++’，因为那玩意儿安全（指熟悉）、方便。”

另一位开发者更是直接引用了 Matt Godbolt 的名言：“向后兼容性才是 C++ 的超能力。”

“别想着重构了，那只会破坏一切。跑了 20 年没 Bug 的生产代码是无价之宝，别碰它！”

更有甚者，因为芯片厂商的编译器只支持 C++89，或者因为“法律原因”，一个项目被迫在一个 3 年前的工具链上锁死 7 年。

在这个宇宙里，C++20 的新特性，对他们来说都像火星科技一样遥远。

宇宙二：拥抱 C++20/23 ——“旦用难回，太香了！”

与“遗老派”形成鲜明对比的，是那些已经吃上新标准红利的“先锋派”。

有开发者激动地表示：

“自从我开始用协程（Coroutines）写网络 IO 代码，我再也回不去以前那种回调地狱了！”

另一位则对 C++23 的 std::println 赞不绝口：

“我离不开 C++23，完全是因为 println。我不知道我还在用 23 的什么其他特性，但光这一个就太棒了。”

对于这部分开发者来说，现代 C++ 的每一个新特性，都是一次生产力的解放。他们就像一群拿到了新玩具的孩子，兴奋地探索着 Ranges 的组合魔法和 Concepts 带来的清爽报错。

宇宙三：爱恨交织的“中间派”——“一半是天堂，一半是地狱”

这或许是最大多数 C++ 开发者的真实写照。

正如帖子作者所言，新特性确实很酷，但它们也带来了巨大的认知负荷和决策成本。

一个开发者的评论获得了 82 个高赞：

“我们大多数人只用了 C++ 语言特性的一小部分。这就像一个‘鸡生蛋、蛋生鸡’的问题：这里有个新特性，但我不知道该怎么用、为什么要用；或者，我代码里有个痛点，可能能用新特性解决，但我不知道该用哪个。”

这种“选择的困境”，正是 C++ “自由”的代价。

底层矛盾：C++ 的“集市”哲学 vs 团队的“教堂”困境

为什么 C++ 会演变成今天这样？

评论区里的一位开发者给出了一个极其精妙的比喻：“集市（Bazaar）”。

“我绝对热爱 C++ 的一点是：它有一个特性集市，你可以挑选你认为适合你项目的工具。如果你看其他语言，比如 Java 要求万物皆对象，Haskell 要求万物皆函数。C++ 给了你面向对象，你讨厌它？没问题，不用就行。你喜欢函数式？C++ 也支持。”

这种“万物皆可选”的自由，是 C++ 最大的魅力，当然也是它最大的诅咒。

因为在一个团队里，当每个人都从“集市”上拿回了自己最喜欢的锤子时，整个项目就会变成一个风格迥异的“建筑工地”。

原帖作者自己也承认：

“自由是真实的，但这也意味着两个 C++ 代码库可能看起来像两种完全不同的语言。”

当一个文件里还在用裸指针和手动内存管理，而另一个文件里已经用上了 std::unique_ptr 和 std::span；当一部分团队在用 boost::asio 写回调，而另一部分团队在用 C++20 的协程……

Code Review 就变成了一场噩梦。

反思：“技术债”还是“护城河”？

这场大讨论的背后，其实隐藏着两个更深层次的软件工程哲学问题。

问题一：新特性是“锦上添花”，还是“非用不可”？

很多 C++ 老兵认为，现代 C++ 增加的很多特性，比如 Ranges 和 Coroutines，其实早在几十年前的 LISP 语言里就已经被证明是伟大的思想。C++ 只是在用一种极其缓慢、极其复杂的方式，在“偿还”几十年前欠下的“技术债”。

但另一些人认为，C++ 的伟大恰恰在于，它能用“零成本抽象（Zero-cost Abstraction）”的硬核方式，将这些高级思想，落地到对性能要求极致的生产环境中。

问题二：复杂性是“敌人”，还是“朋友”？

一位开发者的评论极具辩证思维：

“这（新特性）既是好事，也是坏事。学习的门槛确实在不断提高。但这些工具是实实在在有用的，它们让你能用更干净、更安全、更高效的方式表达代码。”

当 Go在极力做“减法”，试图降低开发者的心智负担时，C++ 却似乎在坚定地走着另一条路：它信任开发者是专家，它把所有的选择权和复杂性都交给你，让你自己去构建属于你的“最佳子集”。

这就像驾驶一架拥有几百个仪表盘的航天飞机。对于新手来说是灾难，但对于顶尖的飞行员来说，每一个按钮都意味着更精准的控制力。

出路何在？：拥抱“渐进式现代化”

在这场看似无解的“内部大讨论”中，我们依然能找到一条充满智慧的中间路线。

有人分享了一个极具参考价值的真实案例：

他成功地在一个庞大的 C++98 代码库中，引入了一个用 C++17 编写的新功能模块。他没有去重构任何老代码，只是简单地升级了编译器和构建脚本。结果：新特性带来了性能的提升和开发效率的飞跃，而老代码依然稳定运行。

这或许就是现代 C++ 正确的打开方式：不要试图用新标准去“革命”旧代码，而是在写新代码时，大胆地、有选择地拥抱新特性。

让 C++98 的归 C++98，让 C++23 的归 C++23。在一个代码库中，允许不同时代的“方言”共存，用新增的模块去逐步“稀释”历史的包袱。

小结：一场关于“自由”的伟大实验

C++ 的这场大讨论，没有赢家。

它只是再次向我们证明了这门语言的“独一无二”：它是一门民主的语言。它给了你选择一切的自由，也要求你为自己的选择承担一切后果。

用一位开发者的话来说：

“Rust 强加给你它的观点；而 C++ 要求你有你自己的观点。这就像专制与民主的区别。大多数时候，民主只是一个被猴子笼子管理的、组织混乱的马戏团。但我更喜欢民主。”

或许，对于我们这些已经习惯了 Go 和 Rust 那种“带你走”模式的开发者来说，偶尔回头看看 C++ 这个充满“混沌与活力”的古老集市，会让我们对“软件工程”这门手艺，有更深刻的理解。

资料链接：https://www.reddit.com/r/cpp/comments/1sihs1w/is_modern_c_actually_making_us_more_productive_or

今日互动探讨：

在你的技术生涯中，你是否也曾被困在某个古老的“技术版本”里动弹不得？对于 C++ 这种“万物皆可选”的自由哲学，你是向往，还是恐惧？

欢迎在评论区分享你的看法！

还在为“复制粘贴喂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/03/24/no-soil-for-new-programming-languages-in-ai-era

大家好，我是Tony Bai。

如果你回望过去十五年的软件工程史，那无疑是编程语言百花齐放的黄金时代。

为了对抗日益膨胀的系统复杂度，人类绞尽脑汁地发明新的“咒语”：

Google 推出了 Go 语言，用极简的 Goroutine 拯救了深陷并发地狱的后端工程师；

Mozilla 孕育了 Rust，用严苛的所有权机制向内存泄漏和数据竞争宣战；

苹果用 Swift 埋葬了晦涩的 Objective-C；

JetBrains 用 Kotlin 为笨重的 Java的使用者提供了一个更优雅的选择；

微软用 TypeScript 彻底规范了狂野的 JavaScript 生态。

每一次新语言的诞生，都伴随着开发者们的狂欢。我们热衷于讨论语法糖、对比编译速度、争论哪种范式更优雅。我们在各大论坛上为自己喜爱的语言摇旗呐喊。

但这已经是最后的余晖了。

站在 2026 年的节点上，当你看着 Claude Code、Cursor 或各类 Coding Agent 在几秒钟内倾泻出数千行逻辑严密的代码时，一个残酷的真相正在浮出水面：

大模型（LLM）的爆发，彻底抽干了孕育下一代通用编程语言的土壤。属于人类的“造语言”游戏，结束了。

这不是危言耸听，而是基于技术演进第一性原理的必然推演。

语料霸权：新语言无法跨越的“生态死局”

在 AI 时代，一门编程语言的生命力不再取决于它的语法有多么优雅，而取决于它在 AI 模型中的“语料权重”。

现存的主流语言（Python, Java, JavaScript, Go, C/C++等）在 GitHub 上积累了数年甚至十余年的海量开源代码。这些代码构成了大模型训练的底座，赋予了 AI 极高的“代码智商”。

当你用 Python 或 Go 提问时，AI 能够瞬间理解你的意图，补全复杂的逻辑，甚至自动发现隐藏的 Bug，因为它的“脑子”里装着上千万个成熟的 Python/Go 示例。

但对于一门新语言来说，这是绝对的死局。

假设明天某个天才发布了一门名为 Nova 的新语言，号称性能超越 C，安全性超越 Rust，语法如 Python 般简洁。

结果会怎样？

• AI 不会写：因为训练语料里没有 Nova 的代码，大模型对它一无所知，无法提供智能补全。
• 人类不会用：在“没有 AI 辅助就感觉不会写代码”的今天，一个习惯了口述意图，让AI Coding Agent 自动生成全量代码的程序员，绝不可能去碰一门必须纯手工敲击、AI 无法帮他编写和Debug的语言。

这就形成了一个无解的马太效应：

没人写就没有语料 -> 没有语料 AI 就不会写 -> AI 不会写人类就不想学 -> 更没人写。

现存的主流语言通过“语料霸权”，彻底锁死了新语言上升的通道。

需求降维：为什么我们不再需要“更好写”的语言？

人类发明新语言的根本动力，是“人脑的带宽有限”。

C++ 太容易写出内存泄漏，人脑排查太痛苦，所以我们发明了 Rust，让编译器做“真理警察”。

Java 处理异步回调太繁琐（Callback Hell），所以我们发明了各种新的语法糖。

我们一直在努力打造更锋利、更安全的斧头，因为那是人类自己要挥舞的斧头。

但在 Agentic Coding（智能体编程）时代，挥舞斧头的不再是人，而是不知疲倦的 AI。

当你可以用自然语言对 Agent 说：“用 C++ 实现一个高并发的 HTTP 服务器，并严格检查所有内存泄漏风险，写出 100% 覆盖率的测试用例。”

只要 AI 的推理能力足够强，加上自动化的沙箱验证（Eval），它完全可以写出极度安全、高效的 C++ 代码。

如果 AI 能够不知疲倦地处理最繁琐的语法、填补最冗长的样板代码（Boilerplate），并且不出错，那么“语言本身是否易读、是否好写” 似乎就变得不再重要了。

因为代码根本不是给人看的，也不是人写的。当“人脑带宽”不再是瓶颈，发明一种“让人类写得更舒服”的新语言，就失去了最大的现实动机。

语言的两极化：自然语言与“AI 中间码”

如果不再有新的面向人类的通用编程语言，未来的代码世界会变成什么样？

答案是：极端的两极分化。

上层：英语（或自然语言）成为终极编程语言。

Andrej Karpathy 的预言正在成为现实（Software 3.0）。人类不需要学习晦涩的语法，人类只需要学习如何清晰、严谨地表达意图，编写能够精准约束 AI 的 Spec（规格说明书）。我们与机器的接口，退回到了人类最擅长的媒介。

底层：只有机器能读懂的“AI 专属语言”。

如果你是大模型厂商（比如 OpenAI 或 Google），当你发现 90% 的代码都是你的模型生成的，你还会让模型生成冗长、为了兼顾人类可读性而充满妥协的 Java 或 Python 代码吗？

不会的。巨头们极有可能会研发一种专门面向 AI 优化的中间表示语言（Intermediate Representation, IR）。

这种语言对人类来说如同天书，但对于模型来说：

• Token 效率极高：原本需要 1000 个 Token 表达的逻辑，这种语言只要 50 个 Token，极大节省推理成本和上下文窗口。
• 逻辑高度压缩：天生适合并行计算和智能体之间的状态传递。

AI 会将人类的自然语言直接“编译”成这种中间码，然后运行。

在这个过程中，介于自然语言和机器码之间、那种专门为了“让人类勉强能懂又能让机器执行”而存在的传统编程语言，其生存空间将被彻底抽空。

小结：致敬“古法编程”的黄金时代

这听起来有些感伤，但这就是技术演进的无情车轮。

就像今天，依然有人沉迷于机械表的齿轮咬合，依然有人热爱在暗房里冲洗胶卷。

“纯手工编写代码（Handcrafted Code）”——这种我们曾引以为傲的工业生产方式，未来可能也会退化成一种个人的“艺术爱好”或“思维体操”。我们称之为“古法编程”。

在某个安静的周末，你或许依然会打开编辑器，为了兴趣手撸一段优雅的 Go 并发或者 Rust 生命周期，享受那种久违的、直接控制机器的“心流”多巴胺。

但在残酷的商业战场上，古法编程即将落幕。

不要再为语法糖而争论不休，不要再期待下一个能拯救你的新语言。

去锻炼你的系统思维吧，去学着用自然语言精准地描绘你的蓝图。因为在下一个时代，定义目标的造物主，永远比精通语法的泥瓦匠更稀缺。

你还在坚持“古法编程”吗？

面对 AI 现场生成代码的冲击，你是否还会为了某种语言的“优雅语法”而兴奋？在你的理想中，未来的“AI 专用中间码”应该长什么样？你是更享受亲自掌控每一行代码，还是更向往定义目标的“造物主”角色？

欢迎在评论区留下你对“古法编程”时代的最后致敬！

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

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

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

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

原「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/03/09/hardcore-review-13-languages-ai-favorite-go-performance

大家好，我是Tony Bai。

随着 Claude Code、Gemini Cli、Codex 等 AI 编程工具的全面普及，“让 AI 写代码”已经从极客的玩具变成了日常的生产力。随之而来的是一个触及灵魂的问题：哪种编程语言最适合交给 AI 去写？

作为 Gopher，我们一直为 Go 语言的“极简语法”、“极速编译”和“强类型安全”感到自豪。我们理所当然地认为，这种没有任何隐式魔法、像白开水一样的语言，绝对是 LLM 的最爱。

然而，现实总是比直觉更骨感。近日，Ruby 核心提交者 Yusuke Endoh（@mame）发布了一份名为 ai-coding-lang-bench 的硬核定量测评报告。他使用 Claude Code（Opus 4.6 模型）对 13 种主流编程语言进行了系统性横向对比。

在这场涵盖了动态语言、静态语言和函数式语言的混战中，Go 语言的表现究竟如何？ 是力压群雄，还是黯然失色？那些备受人类推崇的静态类型系统，在 AI 面前是否成了累赘？

本文和大家一起阅读和拆解这份报告，为你揭晓 AI 时代的语言偏好图谱。

实验设计：让 AI 写一个 Mini-Git

在评价这份报告之前，我们先来看看它的实验设计，这是目前业内少见的、针对 AI Agent 的工程化能力的量化评估。

任务目标：让 Claude Code (Opus 4.6) 从零开始实现一个 mini-git（简化版的 Git）。这是一个极具代表性的任务，它包含了文件 I/O、哈希计算、数据结构操作以及命令行接口，足以考验模型对语言生态的综合运用能力。

测试被巧妙地分为两个阶段，模拟了真实的软件生命周期：

• v1 (新项目构建)：实现基础的 init, add, commit 和 log。
• v2 (特性扩展)：在 v1 的基础上，增加 status, diff, checkout, reset, rm, show 等复杂指令。

提示词（Prompt）极其极简：“阅读 SPEC-v1.txt，实现它，并确保 test-v1.sh 测试通过。”这种设计最大程度地减少了人类指令的干预，纯粹考验 AI 代理在闭环环境下的自主编码、调试和测试能力。

参赛选手（13种语言/15种配置）：

• 动态语言：Python, Ruby, JavaScript, Perl, Lua
• 动态+类型检查器：Python/mypy, Ruby/Steep
• 静态语言：TypeScript, Go, Rust, C, Java
• 函数式语言：Scheme (动态), OCaml (静态), Haskell (静态)

每种语言配置运行 20 次，以消除 LLM 生成的随机性带来的误差，并统计其耗时（Time）、成本（Cost，即 Token 消耗）和代码行数（LOC）。

核心发现：动态语言逆袭，Go 位居第二梯队

如果仅看总耗时和总成本（v1 + v2），测试结果呈现出了令人瞩目的阶梯式分布。

第一梯队：Ruby, Python, JavaScript 的绝对统治

在这场 AI 编程竞速中，Ruby（73.1s）、Python（74.6s）和 JavaScript（81.1s）组成了无可争议的第一阵营。

它们不仅生成速度最快、消耗 API 成本最低（均在 $0.40 以下），而且在 20 次测试中表现出了极高的稳定性（标准差极小）。

对于 AI 来说，生成这三种语言的代码就像呼吸一样自然。它们无需繁琐的项目初始化配置（如 Cargo.toml 或 package.json），可以做到“建个文件直接跑”，这种极简的工作流在 v1 阶段（新项目构建）优势极大。

第二梯队：被“强类型”拖慢脚步的 Go 与 Java

现在，来回答大家最关心的问题：Go 表现如何？

答案是：位居第二梯队。Go 的总耗时为 101.6s，平均成本 $0.50。中规中矩。Go 虽然在语法上非常克制，但依然落后于 Python 和 JS 等动态语言。与之类似，Java（115.4s）也因为繁琐的语法结构和强类型约束，留在了这一梯队。

尽管如此，Go 在整个 20 次测试中没有出现一次失败（0 次 fail），这证明了 Go 的编译器在防止 AI 产生“幻觉 Bug”方面，发挥了极其可靠的安全网作用。

“后进生”阵营：Rust 与 C 的挣扎

备受人类极客推崇的 Rust（113.7s，且有 2 次失败）和底层的 C（155.8s）在测试中显得步履维艰。

尤为值得注意的是，在总共 600 次的独立运行中，只有 Rust (2次) 和 Haskell (1次) 出现了测试失败（未能最终跑通 Shell 脚本）的情况。这两门语言都以其极高的心智负担和“编译器教你做人”的严格程度而闻名。

这也是将Rust列入“后进生”阵营的主要原因。如果用《飞驰人生》的拉力赛来比喻，Rust 相当于在40站的赛季中，有两站没能完赛！

深度剖析：为什么 AI 更偏爱动态语言？

在传统的工程视角中，“静态类型防止低级 Bug”、“动态语言难以维护”是金科玉律。但在 LLM 驱动的 Agent 开发流中，这个逻辑为何失效了？作者 Yusuke Endoh 提出了几个关键的解释维度。

训练数据的“虹吸效应”

LLM 的能力直接取决于训练语料的规模和质量。Python、JavaScript 和 Ruby 是过去十几年 Web 开发的绝对主流。GitHub 上海量的这三种语言的开源代码、StackOverflow 上的问答，为 Claude Code 提供了极其丰富的“预训练肌肉记忆”。

当 AI 需要实现一个功能时，它在 Python 的隐空间（Latent Space）中寻找最优解的路径，远比在 Haskell 甚至 Rust 中要清晰、笔直得多。

静态类型的“双刃剑”与重构阻力

静态类型系统的初衷是约束人类，防止我们在重构时犯错。但在 AI 的“ Prompt -> 生成 -> 测试报错 -> 思考 -> 再生成”的迭代循环中，严格的类型检查反而成了巨大的“摩擦力”。

• 编译成本与调试死锁：在 Rust 或 C 中，当 AI 生成的代码出现类型不匹配时，它需要花费大量的 Token 去阅读复杂的编译器报错信息。有时，为了解决一个简单的借用检查器（Borrow Checker）报错，AI 可能会陷入漫长的、无休止的“试错-编译失败”死循环。
• 重构牵一发而动全身：在 v2 特性扩展阶段，往往需要修改现有的数据结构。对于 Python，AI 只需要在字典里加个 key；而对于 Rust 或 Java，这可能意味着需要重构一系列的 Struct、更新类型签名、甚至修改与之相关的无数个函数的参数声明。这种“爆炸半径”极大地增加了耗时。

“附加类型检查”的巨大损耗

报告中一个非常有意思的对照组是：原生动态语言 vs 附加类型检查器的动态语言。

• Python (74.6s) vs Python/mypy (125.3s) —— 变慢了 1.6~1.7 倍。
• Ruby (73.1s) vs Ruby/Steep (186.6s) —— 变慢了 2.0~3.2 倍！

这证明了，迫使 AI 在动态语言中编写严谨的类型注解（Type Annotations），是一项极其昂贵的任务。模型需要耗费额外的算力去推导类型、生成类型声明文件，并且在类型检查器报错时，还要去修复那些在纯动态模式下可能根本不影响运行的“伪 Bug”。

代码量（LOC）的迷思：越短越好吗？

我们通常认为，写得越少，跑得越快。但数据打破了这个迷思。

Haskell 和 OCaml 生成的最终代码行数（224行和 216行）是所有语言中最少的，甚至少于 Python 和 Ruby。然而，它们在生成时间上的表现却排在倒数（Haskell 耗时最长，达 174s）。

这表明，对于 AI 来说，函数式语言那种高度抽象、信息密度极大的代码，生成和推理的成本远高于像 Python、Go 那种稍微啰嗦但逻辑平铺直叙的“大白话”代码。浓缩的未必是精华，对于 LLM 来说，高度浓缩往往意味着更高的生成熵和更高的试错概率。

行业启示：我们需要重新思考 AI 时代的技术栈选型

面对这份详实的基准测试报告，无论你是 CTO 还是普通开发者，都必须开始重新审视未来的技术选型逻辑。

动态语言是快速原型的“绝对王者”

如果你正在启动一个新项目，或者需要用 AI Agent 快速验证一个业务流程，Python 和 TypeScript 是首选（报告中 JavaScript 表现优于 TS，但在实际工程中 TS 的综合权衡更佳）。

不要迷信“大型项目必须一开始就上强类型编译语言”。在需求快速变化的初期，让 AI 用动态语言狂飙突进，是获取业务反馈最高效的手段。

性能王者们的困境：Go 与 Rust 在 AI 时代掉队了吗？

看到测评数据，很多 Gopher 可能会感到失落：难道注重工程严谨性和系统级性能的静态语言，真的在 AI 时代掉队了吗？

结论并非如此悲观。我们需要明确一点：Agent 测评的速度，不等于软件最终运行的速度。

• 业务试错 vs 基础设施：AI Agent 目前最擅长、也最快速能完成的，是写“胶水逻辑”和“业务 CRUD”。在这些领域，Python 确实快。但当你的系统涉及到高并发、内存精细控制、或者需要打包为轻量级容器部署时，人类依然需要 Go。
• 容错的底线：在这场 600 次的庞大测试中，只有 Rust 和 Haskell 出现了最终测试失败，而 Go 保持了完美的 100% 成功率。这恰恰说明，Go 在“极度灵活（易幻觉）”与“极度严格（难生成）”之间，找到了一个非常微妙的平衡点。它可能不是 AI 写得最快的，但它一定是 AI 写出来最让人放心的系统级语言。

我们不应期待 AI Agent 能够像写 Python 脚本一样，如德芙般丝滑地生成出一个复杂的 Go 并发系统。但在 AI 给出的初稿之上，Go 语言极佳的可读性和统一的规范，将为人类工程师的最终审查（Code Review）节省巨大的精力。

小结：下一个十年的编程语言，长什么样？

ai-coding-lang-bench 给我们上了生动的一课。它揭示了当前 LLM 的偏好：它们喜欢有海量训练数据的、灵活的、不需要应对死板编译器的语言。

但我们必须认识到，这只是一份基于 2026 年初模型（Claude Opus 4.6）的快照。未来的 AI 编程语言形态，可能会朝着两个方向演进：

1. AI Native 语言的诞生：抛弃目前设计给人类阅读的语法，出现一种专门为了降低 LLM 生成 Token 成本、且天然抗幻觉的机器中间语言。
2. 现有静态语言的“Agent 友好化”编译模式：Go 和 Rust 可能会进化出一种特殊的编译模式。在这个模式下，编译器不仅是冷冰冰地报错，还能以结构化的、对 LLM 更友好的方式提供“修复建议”，从而大幅缩短 Agent 修复编译错误的反馈回路。

无论如何，浪潮已经来临。在 AI 主导代码生成的新时代，我们评价一门编程语言的标准，正在从“它对人类大脑是否友好”，悄然转变为“它对大模型推理是否友好”。

而在这场新赛道上，动态语言们，已经抢跑了。

本文核心数据与图表均来源于 GitHub 项目 mame/ai-coding-lang-bench。

你的 AI 编程初体验

看完这个排名，你是感到意外，还是早已感同身受？在你日常使用 AI 编程时，你觉得它写哪种语言最让你省心？你是否也曾为了修一个 AI 写的编译错误而陷入“死循环”？

欢迎在评论区分享你的“AI 协作”红黑榜！

“语言的严格性正在变成 AI 的摩擦力？在 AI 时代，掌握一套能驱动 Agent 自动化、自修复的‘工作流’比死磕语法更重要。我的新专栏 《AI原生开发工作流实战》 将教你如何利用 Claude Code 结合 Spec 驱动开发，构建真正高产出的‘软件工厂’。”

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

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

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

原「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. 版权所有.