本文永久链接 – 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

本文永久链接 – 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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