Rust - Tony Bai

本文永久链接 – https://tonybai.com/2025/10/19/flask-creator-choose-go

大家好，我是Tony Bai。

Armin Ronacher，这个名字在 Python 世界如雷贯耳。作为广受欢迎的 Web 框架 Flask 的创造者、Sentry 的首批工程师之一，他被公认为 Python 社区最具影响力的开发者之一。然而，最近在一场深度访谈中，他透露了一个足以让许多人感到惊讶的决定：

在他的新 AI 创业公司中，Go 成为了核心的后端语言。

为什么一位浸淫 Python 和 Rust 生态多年的顶尖开发者，会在 AI 创业的浪潮中，最终将信任票投给了 Go？这个选择的背后，并非一时兴起，而是一场关于务实主义、生态位和 AI 时代生产力的深刻权衡。

在这篇文章中，我们就来看看这位 Python 大师在 AI 时代技术选型的心路历程。

被放弃的“旧爱”——Python 的复杂性与 Rust 的“摩擦力”

要理解为什么选择 Go，我们必须先理解 Armin Ronacher 放弃了什么。他将自己比作一个拥有“分裂大脑”的程序员：一面是追求极致工艺的开源匠人，另一面是追求快速迭代的创业者。对于后者，他曾经深爱的 Python 和 Rust，都显得不再完美。

Python：深爱但日趋复杂

作为 Armin 的“母语”，Python 的务实和灵活性毋庸置疑，尤其是在数据处理和 ML 领域。但他坦言，随着时间的推移，Python 语言本身变得越来越复杂。“对于一众工程师来说，Go 反而比 Python 更容易写了，” 他在访谈中说道。对于一个需要快速构建、易于团队协作的后端服务来说，现代 Python 并非总是最佳选择。

Rust：开源世界的“瑞士腕表”，创业公司的“巨大摩擦力”

Armin 对 Rust 充满了敬意，称其为打造精密、高性能开源库的“瑞士腕表”。他在 Sentry 引入 Rust 处理二进制文件和解决性能瓶颈，取得了巨大成功。然而，当场景切换到需要快速迭代的初创公司时，Rust 的优点却可能转化为“摩擦力”：

极慢的编译速度：“这是一个巨大的因素。”
陡峭的学习曲线：借用检查器 (borrow checker) 等概念虽然强大，但也极大地增加了心智负担，拖慢了开发速度。“Rust 解决了许多‘Rust 形’的问题，” Armin 总结道，“但并非所有问题都是‘Rust 形’的。”

Go 的胜出——务实主义者的最终选择

正是在 Python 的日益复杂和 Rust 的高摩擦力之间，Go 以其独特的定位脱颖而出，成为了 Armin 创业之路上的务实之选。

精准的生态位：“为 Web 服务而生”

Armin 对 Go 的定位评价极其精准：

“我认为 Go 就是一门构建 Web 服务的好语言，而且基本上只专注于 Web 服务（可能还有一些命令行工具）。”

这看似一句“限制”，实则是一种褒奖。它意味着 Go 在其核心领域——网络编程和分布式系统——拥有一个高度专注、极其成熟且无与伦比的生态系统。对于一家构建网络服务的初创公司而言，这种专注性远比语言的“全能性”更有价值。

“它不会超级性感，” Armin 补充道，“但你可以期待它会长久存在。” 这种稳定性和可预测性，对于需要构建长期产品的公司来说，是至关重要的技术资产。

AI 时代的“超能力”：对 AI 编码助手更友好

这可能是整场访谈中最令人振奋的发现。作为一个重度 AI 编码工具的使用者，Armin 进行了一项实验：让 AI 用不同语言编写同一类程序，然后评估其成功率和代码质量。

他的结论是：Go 的表现远超 Python 和 Rust。

他分析其原因为：

“因为 Go 的抽象非常薄 (abstractions are very thin)。”

这句评价一语中的。Go 语言的小关键字集、简洁的语法、无隐式转换、明确的错误处理……所有这些被一些人批评为“不够强大”的设计，在 AI 模型眼中，恰恰成为了最清晰、最无歧义的指令。AI 更容易理解和生成地道的 Go 代码，因为语言本身留下的“灰色地带”和“魔法”最少。

在 AI 驱动开发的时代，Go 的“简单”，正从一种设计哲学，演变为一种实实在在的生产力优势。

Sentry 的教训——错误处理的隐性价值

Armin 在 Sentry 十年的经历，让他对错误处理有了深刻的理解。他指出，许多语言和运行时为了追求性能，往往会牺牲掉在生产环境中获取丰富错误信息的能力。

“许多语言的运行时经常忽略错误……它们没有携带正确的信息，而应用和库开发者也根本不考虑错误。”

这段话让我们不禁反思 Go 的 error 接口和错误包装 (error wrapping) 机制。虽然 if err != nil 常被诟病为冗长，但它强制开发者在每个环节都直面错误，并通过错误包装链，为我们提供了在生产环境中保留完整上下文的可能性。

Armin 的经验告诉我们，这种对错误信息的执着，并非“啰嗦”，而是在构建可观测、可维护系统时，一项极其宝贵的投资。

小结：为什么是 Go？

回到最初的问题：为什么是 Go？

Armin Ronacher 的选择，为我们提供了一个清晰的答案。他选择 Go，不是因为它拥有最前沿的特性，也不是因为它能解决所有问题。他选择 Go，是因为在一个充斥着复杂性和不确定性的 AI 创业时代，Go 提供了最宝贵的东西：

务实：它专注于解决 Web 服务的核心问题，不多也不少。
简洁：它的“薄抽象”使其在与 AI 协同工作时效率惊人。
健壮：它的错误处理哲学，以及在并发、部署上的优势，为构建可靠的系统奠定了基础。

一位来自 Python 世界的大师，最终用自己的技术选型，为 Go 的设计哲学投出了最宝贵的一票。这提醒我们，Go 的成功并非偶然，而是其核心设计原则在真实世界工程需求下，不断被验证的必然结果。

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

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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

本文永久链接 – https://tonybai.com/2025/09/22/go-team-gave-up-on-features

大家好，我是Tony Bai。

在 GopherCon Europe 2025 的 Go 团队座谈会上，Michael Stapelberg(负责go protobuf)、Damien Neil(负责Go安全相关)、Michael Pratt(负责Go运行时和Go性能相关) 和 Jonathan Amsterdam(log/slog作者，负责Go工具相关) 四位核心成员与社区进行了一场坦诚的对话。他们不仅分享了诸如官方 MCP SDK、“裸金属”Go 等激动人心的进展，更以一种罕见的坦率，正面回应了社区长期以来关心的多个“老大难”问题——包括不可变类型、泛型错误处理和非 nil 指针。其中最引人注目的一句“我们放弃了”，几乎为 Go 语言在某些方向上的演进画上了句号。

本文将带你深入这场座谈会的核心内容，一探 Go 语言的现在与未来。

语言设计的哲学——“不做什么”比“做什么”更重要

座谈会最精彩的部分，莫过于对多个长期存在的语言功能提案的讨论。Go 团队的态度清晰而一致：为了维护 Go 的核心价值——简洁性和易读性，他们愿意对许多看似“美好”的功能说“不”。

不可变数据类型 (immutable)

社区的期待：为 Go 增加类似 immut和const(修饰变量的) 的关键字，以增强代码的安全性和可预测性。
团队的困境：Michael Pratt 承认，这是“可能做的最好的事情之一”，但他紧接着说，“我们不知道该如何实现它”。内部曾有多个提案，但都未成功。核心问题在于，任何这类功能都会像病毒一样在代码库中蔓延，迫使所有 API 都需要考虑 const 和非 const 两种版本，这与 Go 的设计哲学背道而驰。
结论：在社区提出一个绝佳的、能保持语言简洁性的提案之前，官方不会主动推进。

泛型错误处理 (减少 if err != nil)

社区的期待：引入 try/check 等机制，减少错误处理的冗余代码。
团队的“投降”：在经过长达数年的思考和无数次讨论后，Go团队给出了一个爆炸性的结论：“我们放弃了 (we give up)。” 团队承认，他们找不到任何一种能让所有人都满意的、既能减少冗余又不损失清晰性的方法。
新的焦点：这一“投降”反而让团队感到“极度兴奋”。因为它意味着可以停止在“冗余”这个问题上内耗，转而思考其他更重要的错误处理问题。Damien 明确指出，如何在错误中加入堆栈跟踪才是当前错误处理最大的痛点，也是团队更愿意投入精力去探索的方向。

非 Nil 指针 (non-nil)

社区的期待：通过语言机制在编译期防止 nil 指针解引用。
团队的权衡：Jonathan Amsterdam 解释道，虽然非 nil 指针很好，但它会引入两种指针类型，让一切都变成两倍。或者需要引入复杂的流式类型分析，这会使代码更难阅读和理解。
一个反直觉的洞见：“Nil 指针错误是最好的运行时错误”，因为它有确定性的堆栈跟踪，易于定位。团队更关心那些非确定性的、只在生产环境中出现的并发 bug，比如 goroutine 泄漏。

枚举 (enum)

社区的期待：提供比 iota 更强大、更类型安全的枚举支持。
团队的困惑：Damien 指出，社区对 enum 的需求至少有两种截然不同的解读：一种是“整数的枚举”，另一种是“类型的枚举”（即代数数据类型），两者差异巨大。在社区就“到底想要什么”达成共识之前，团队很难推进。

标准库的“新陈代谢”——演进、维护与“瘦身”

标准库是 Go 生态的基石，但随着时间的推移，一些包也显现出历史的痕迹。

哪些包应该被“移除”？

团队成员们“点名”了一些他们认为设计不佳或已不再主流的包：

text/tabwriter: Damien 认为其设计不佳，如果现在重来，会做一个 v2 版本。
运行时的诊断(diagnostic) API: Michael Pratt 认为现有的 API “有点陈旧，难以使用”，希望能有更好的 API，但不确定是否值得为此做一个 v2。
net/rpc: 被 gRPC 全面超越。
expvar: 非常小众，很少有人使用。
syscall: 正在被 golang.org/x/sys 逐步取代，以实现更灵活的更新。
net/mail, syslog: 社区已经有了功能更强大、更受青睐的替代方案，标准库的实现已沦为“鸡肋”。

虽然因为 Go 1 的兼容性承诺无法真正移除它们，但团队的态度表明，未来的发展重心将不会在这些包上。

拥抱 v2，但极其审慎

json/v2 和 math/rand/v2 的出现，标志着 Go 团队愿意为那些存在根本性设计缺陷的包创建 v2 版本。但团队强调，这是一个极为例外的手段，只有在“现有 API 框架内无法做出改进”时才会考虑，因为 v2 会带来生态的分裂和迁移成本。

Go 在新时代的定位与机遇

面对 AI、裸金属(bare metal)等新兴领域，Go 将如何定位自己？

Go 在 AI 与数据科学领域的角色

清晰的边界：Go 团队不会去开发一个与 LangChain 或 Genkit 竞争的官方 AI 框架，也不会深入数值计算（社区的 gonum 已经很出色）。
专注“生产化” (Productionization)：团队认为，Go 的核心优势在于将 Python 中训练和设计的模型，部署到高性能、高并发的生产环境中。这是 Go 想要“拥有”的领域。Jonathan Amsterdam 更是直言：“你用 numpy 把东西搭起来，但你不会想用 Python 把它部署到生产环境。这时候你就该用 Go 了。”
提供核心 SDK 支持：团队将致力于为重要的 AI 规范和平台（如 MCP, Gemini, Genkit）提供高质量的官方 Go SDK。

“裸金属” Go (Bare metal Go)

进展：Michael Pratt 确认，一项由 Tamago 项目推动的新提案正在讨论中，旨在为 Go 运行时提供一个更稳定的内部 API，使其能更好地与底层系统交互。
价值：这将使 Go 在嵌入式、unikernel 等领域的应用变得更加容易，并且其设计是通用的，不局限于特定 CPU 架构。

激动人心的地平线——运行时与工具链的前沿探索

座谈会也透露了几个正在进行中的、令人兴奋的底层项目：

官方 MCP SDK：Jonathan Amsterdam 确认，官方的 Go MCP SDK 随时可能发布正式版，它吸取了社区现有实现的经验，设计更清晰，旨在成为官方标准。
Green Tea GC：Michael Pratt 提到，Michael Knyszek 正在进行一项名为“Green Tea”的 GC 改进提案，旨在提升 GC 在超多核（如 256 核）机器上的可扩展性和局部性 (locality)，以应对现代服务器硬件的发展。
Goroutine 泄漏检测：团队正在与 Uber 的工程师合作，计划将一项利用 GC 来动态检测部分死锁（即 goroutine 泄漏）的技术引入 Go。这项技术能找出那些“永远等待”在一个无人能触及的 channel 上的 goroutine，并将其报告出来。
WASM 的原生 GC 集成：团队希望未来能让 Go 编译的 WebAssembly 使用宿主环境（如浏览器）的原生 GC，但这面临着 Go 严重依赖“内部指针”（interior pointers）而 WASM GC 不支持的巨大技术挑战。
结构体对齐优化：David Chase 正在推动一个“个人激情项目”，目标是让编译器自动优化结构体字段的顺序，以减少内存空洞和提高空间效率。未来开发者将不再需要手动调整字段顺序。相关的提示功能已在 gopls 中提供。

开发者的日常——工具、协作与社区

座谈会的最后，团队成员分享了他们作为开发者的工作日常和对社区的看法。

AI 工具的使用：团队成员普遍开始使用 LLM。Jonathan Amsterdam 发现它是学习 OAUTH2 这类复杂规范的“极有耐心的老师”；Michael Stapelberg 则用它来学习 NixOS。Damien 更是认为 LLM 在处理 Go 代码时表现出色，因为 Go 的简洁性和向后兼容性为模型提供了高质量的训练数据。
编辑器之争：Michael Stapelberg 坦诚自己已从 Vim 叛逃至 Emacs，引发了现场的善意哄笑。
对 Go 社区的信心：当被问及“如果 Google 不再支持 Go，社区能否接手”时，团队成员们毫不犹豫地表示肯定。他们认为 Go 社区非常强大且自给自足，拥有大量非 Google 的核心贡献者（并以 Filippo Valsorda 为例），社区的繁荣并不完全依赖于 Google。

拾遗——关于性能、安全与其他语言的思考

除了上述重大议题，座谈会还触及了许多开发者关心的具体问题，这些简短的问答同样充满了来自 Go 团队的深刻洞见。

Go 与 Rust：灵感的源泉

当被问及对 Rust 等其他语言的看法时，团队表现出开放和欣赏的态度。

并发安全：Jonathan Amsterdam 坦言，Rust 提供的并发安全模型是他们“都希望在 Go 中拥有”的东西，因为它能极大地提升程序的可靠性。但他同时指出，在不让 Go 变得像 Rust 一样复杂的前提下，目前还没有找到实现路径。
不同的演进道路：团队也关注 OCaml 在并发安全上的探索。Jane Street 采用了一种与 Rust 完全不同的方法来实现并发安全，这表明解决同一问题可以有多条路径，Go 也在持续观察和学习。

性能：一个“双峰分布”的社区

Michael Pratt 对 Go 的性能有一个有趣的观察，他认为社区对此的感受呈现“双峰分布”：

一端是极其满意的用户：他们可能从 Python 等动态语言迁移而来，享受到了数十倍的性能提升，对现状非常满意。
另一端是要求极致性能的用户：大厂在海量部署下，对性能的渴求永无止境，任何微小的优化都能带来巨大的成本节约。

Go 团队的性能优化工作，主要聚焦于服务后一类用户，例如 json/v2、新的 map 实现以及 Green Tea GC。

安全：API 优于“模式开关”

对于“能否为 Go 增加一个‘高安全模式’开关”的问题，团队更倾向于通过改进 API 来解决安全问题。

**Damien ** 提到，一个可能的方向是为 net/http 包增加一个“高安全服务器”标志，该标志将启用一系列更安全的默认配置（例如，更严格的超时），以修正十年前设定的一些已过时的默认值。
Michael Stapelberg 补充道，Go 已经提供了像 os.ReadDirFS 这样更安全的路径遍历 API，并且 Go 程序与 Seccomp、Landlock 等 Linux 沙箱技术能很好地集成。从 API 和系统层面入手，是比引入一个全局的、模糊的“安全模式”更精细、更合理的做法。

io_uring：令人兴奋但为时过早

对于 Linux 下备受瞩的 io_uring，Michael Stapelberg 表达了谨慎的乐观。他承认 io_uring 性能惊人，但其复杂的 API 和过去暴露出的严重安全问题，使得 Google 内部服务器完全禁用了该功能。他认为，在它变得更成熟、更安全之前，考虑将其大规模引入 Go 还为时过早。此外，Michael Pratt 补充说，Go 的运行时和调度器已经通过 goroutine 隐藏了大部分 I/O 异步的复杂性，因此 io_uring 能带来的部分核心优势，Go 已经通过不同的方式实现了。

Go 作为 DevOps 脚本语言

当被问及 Go 能否取代 Python 成为 DevOps 脚本语言时，团队成员们几乎异口同声地表示：“在 Google 内部，这已经发生了。” Michael Stapelberg 分享说，他自己现在会避免编写任何中等复杂度的 shell 脚本，而是直接从 Go 开始，因为 Go 的强类型和工程化能力，能避免脚本在变复杂后迅速变得难以维护。