本文永久链接 – https://tonybai.com/2025/08/25/go-is-still-not-good

大家好，我是Tony Bai。

在技术圈，平静的湖面下往往暗流涌动。对于Go语言社区而言，这股潜藏已久的暗流，被近期的一篇名为《Go is still not good》的博文彻底引爆。作者Thomas Habets，一位自称拥有超过十年Go使用经验的资深开发者，在他的这篇文章中系统性地列举了他眼中Go语言的“七宗罪”。这篇文章迅速登上Hacker News热榜，吸引了超过700条评论，形成了一场规模空前的社区大辩论。

参与者中不乏Go的早期采纳者、贡献者和日常重度使用者。他们争论的焦点，早已超越了语法糖的优劣，直指Go语言最核心的设计哲学——那些曾被誉为“简单”和“务实”的基石，如今在一些开发者眼中，却成了束缚发展、埋下隐患的“原罪”。

在这篇文章中，我就和大家一起跟随这场激辩，逐一剖析这引发轩然大波的“七宗罪”，看看从中能得到哪些有益的启示。

第一宗罪：歧义之空——nil 的双重身份

这是Go语言中最著名的“陷阱”，也是原文作者打响的第一枪。一个持有nil指针的接口变量，其自身并不等于nil。

package main

import "fmt"

type Error interface {
    Error() string
}

type MyError struct{}

func (e *MyError) Error() string { return "my error" }

func GetError() *MyError {
    // 假设在某种条件下，我们返回一个 nil 的具体错误类型指针
    return nil
}

func main() {
    var err Error = GetError()

    // 输出: false
    // 尽管接口 err 内部持有的值是 nil，但接口本身因为包含了类型信息 (*MyError)，所以它不为 nil。
    fmt.Println(err == nil) 

    if err != nil {
        // 这段代码会被执行，然后可能在后续操作中引发 panic
        fmt.Printf("An error occurred: %v (type: %T)\n", err, err)
        // err.Error() // 若MyError的Error方法有解引用操作，此处会panic
    }
}

我们知道：Go的接口（interface）在内部实现为一个包含两部分的“胖指针”（fat pointer）：一个指向类型元数据的指针和一个指向实际数据的指针。只有当这两个指针都为nil时，接口变量本身才被认为是nil。在上述例子中，err的内部状态是(type=*MyError, value=nil)。因为类型信息存在，err != nil的判断为真，导致程序逻辑错误地进入了错误处理分支，挑战了开发者的常规直觉。

社区激辩：

• 批评者阵营：Hacker News上，有用户提供了一个经典的Playground示例，展示了这个问题如何在生产环境中导致panic，并评论道：“这确实会在生产中咬你一口，而且在代码审查中极易被忽略。”另一位用户则更为尖锐，他引用了Rob Pike关于Go是为“非研究型、刚毕业的年轻工程师”设计的言论，反问道：“一个声称为了简化编程而设计的语言，却包含如此令人困惑的nil行为，这本身就是一种讽刺。”

• 辩护者阵营：另一派观点认为，这并非缺陷，而是Go底层数据结构逻辑的直接体现。有开发者解释道：“接口值是一个包含类型和值的偶对。(&Cat, nil)当然不等于(nil, nil)。”他们认为，一旦理解了接口的内存模型，这个问题便不再神秘，甚至可以利用这一特性（例如，在nil接收者上调用方法）。然而，这种辩护本身就强化了批评者的观点：一门标榜高级和简单的语言，却要求开发者对底层的实现细节有如此深刻的理解，这是否可以看作设计上的一种失败呢？

第二宗罪：作用域之惑——被迫扩展的err变量生命周期

Go通过if err := foo(); err != nil语法，优雅地将err变量的作用域限制在if块内，这被广泛认为是最佳实践。然而，当函数调用需要返回除error之外的值时，这种优雅便荡然无存。

bar, err := foo()
if err != nil {
    return err
}
// 此处的err变量将在整个函数剩余部分都有效，即使它现在的值是nil

if err = foo2(); err != nil { // 复用err
    return err
}

// ... 大量代码 ...

return err

Go的短变量声明:=要求左侧至少有一个新变量。为了接收bar这个新值，err也被迫在函数作用域内被重新声明（或首次声明）。这导致err的生命周期被人为地拉长，污染了整个函数的作用域。

社区激辩：

• 批评者阵营：原文作者尖锐地指出，这种设计“强迫你做错误的事情”。一个本应是局部的错误变量，现在却像个幽灵一样在整个函数中游荡，增加了代码阅读者的认知负担。读者必须时刻追踪err变量最后一次被赋值的位置，这极易导致bug，尤其是在重构或修改长函数时。
• 辩护者阵营：对此的辩护声音较弱，大多认为这是个“可以忍受的小麻烦”。他们认为，这是为了保持语法一致性（:=的规则）而付出的代价。然而，这恰恰暴露了Go在追求一种形式上的“简单”时，牺牲了更重要的“上下文清晰性”。

第三宗罪：所有权之乱——append的隐式副作用

slice是Go的基石之一，但其与底层数组（backing array）的模糊关系，通过append函数暴露无遗，构成了另一个经典的“搬起石头砸自己的脚”。

原文的例子一针见血地揭示了append行为的不可预测性：

package main

import "fmt"

func main() {
    // 案例一：当容量足够时，发生“幽灵写入”
    a := []string{"hello", "world", "!"}
    b := a[:1]                 // b与a共享底层数组，且cap(b) == 3
    b = append(b, "NIGHTMARE") // 修改了b，因为容量足够，直接修改了底层数组
    fmt.Println(a)// 结果：a变成了[hello NIGHTMARE !]

    // 案例二：当容量不足时，修改“失败”
    a = []string{"hello", "world", "!"}
    b = a[:1]
    b = append(b, "BACON", "THIS", "SHOULD", "WORK") // 容量不足，分配了新数组
    fmt.Println(a)// 结果：a依然是[hello world !]
}

我们知道：append的行为取决于slice的容量（cap）。如果追加后未超出容量，它会就地修改底层数组；否则，会分配一个新的、更大的数组。这种设计不仅让append的性能变得不确定，更严重的是，它破坏了函数调用的封装性，使得slice既不像值类型（可能被远程修改），也不像纯粹的引用类型（可能因重分配而断开联系）。

社区激辩：

• 批评者阵营：Hacker News上一位获得高赞的评论是这样的：“append的例子是Go缺陷中最恶劣、最不可原谅的。”这种行为使得数据流变得难以追踪，迫使开发者必须时刻警惕slice的容量，或养成防御性编程的习惯，例如总是重新接收append的返回值。这与Go追求的“明确”背道而驰。
• 辩护者阵营：支持者认为这是为了性能做出的合理权衡，避免了不必要的内存分配。他们强调，Go官方文档已明确说明了slice的工作原理。然而，这再次回到了那个核心问题：一门标榜“简单”的语言，是否应该包含如此微妙且需要深度理解才能安全使用的核心数据结构？

第四宗罪：作用域陷阱——函数级的defer

defer是Go处理资源释放的利器，但它的作用域是整个函数，而非其所在的词法块（lexical scope）。这在循环中处理资源时会成为一个严重的资源泄漏问题。

for _, file := range files {
    f, err := os.Open(file)
    if err != nil { /* ... */ continue }
    // defer不会在每次循环结束时执行，而是堆积到函数返回时执行
    // 如果文件列表很长，将耗尽文件句柄
    defer f.Close()
    // ... process file
}

根本原因在于defer语句的执行被推入一个与当前函数关联的栈中，在函数返回前统一执行。这简化了编译器的实现，并确保了panic时资源也能被释放。

社区激辩：

• 批评者阵营：一个开发者的高赞评论代表了社区的普遍困惑：“我至今不明白defer为什么是函数作用域而非词法作用域。”这与C++的RAII或Java的try-with-resources相比，是一种设计上的倒退。公认的解决方法是使用匿名函数func(){…}()包裹循环体，但这无疑增加了代码的丑陋和复杂性。
• 辩护者阵营：有用户指出，函数级作用域也有其便利之处，例如可以在if块中有条件地注册一个defer。但总体而言，社区普遍认为，默认应该是更安全、更符合直觉的词法作用域。

第五宗罪：异常之隐——被标准库“吞噬”的panic

Go的哲学是：error用于可预见的错误，panic用于程序无法继续的灾难。然而，作者指出，标准库中的fmt.Print和net/http服务器等关键部分，会主动recover从panic中恢复，这破坏了panic的基本约定。

这意味着开发者必须编写“异常安全”的代码。你必须假设任何传递给标准库的代码都可能在panic后被恢复。因此，像互斥锁（mutex）这样的资源必须通过defer来确保释放，否则一旦发生被“吞噬”的panic，就会造成死锁。作者愤怒地指出：“所有希望都破灭了。你必须写异常安全的代码，但你又不应该使用异常。你只能承受异常带来的所有负面影响。”

社区激辩：这一点在社区中几乎没有辩护的声音。这被视为一种设计上的不一致和“伪善”。语言在表层倡导一种错误处理哲学，却在底层库中悄悄破坏它，迫使开发者为这种矛盾买单。

第六宗罪：编码之殇——对非UTF-8的“绥靖政策”

Go的string类型本质是只读的[]byte，不强制其为合法的UTF-8。这在与操作系统交互（如处理文件名）时提供了灵活性，但也埋下了隐患。

作者控诉，这种“宽松”策略是数据丢失的根源。当工具不假思索地按UTF-8处理文件名时，遇到非UTF-8编码的文件名可能会跳过或处理失败，导致在备份、恢复等关键操作中“静默地”遗漏数据。

社区激辩：

• 批评者阵营：他们认为类型系统应防止此类错误。有用户激烈地评论道：“Go让你很容易做那些看起来99.7%的时间都有效，但却是愚蠢、错误、不正确的事情……然后有一天，你的用户就因为一个非UTF-8文件名而永久丢失了数据。”
• 辩护者阵营：另一方则认为Go的做法才是务实的。有用户指出，一个强制Unicode正确性的文件接口在真实世界中是有问题的。Rust的OsStr虽然严谨，但人体工程学极差。Go的方式虽然“混乱”，但在实践中更方便。这揭示了严谨性与便利性之间的深刻矛盾。

第七宗罪：承诺之虚——伪善的“简单”与被忽视的性能

这并非单一技术点，而是对Go整体设计理念的综合批判。

• 简单性的代价是复杂性转移：许多评论者指出，Go语言层面的“简单”，是把复杂性推给开发者来承担。没有枚举、没有强大的泛型（即使1.18加入了，也限制颇多）、没有Result类型，导致开发者需要手写大量重复的样板代码和自定义数据结构。
• 内存管理的“信任危机”：原文作者提到“RAM is cheap”是危险的思维。Hacker News上有开发者分享了其在内存敏感项目中被Go的非压缩GC和堆碎片化问题折磨的经历，他们甚至不得不重写部分标准库以避免内存分配。这与Go宣称的“高性能”和“无忧GC”形成了鲜明对比。

为何着一篇文章能掀起千层浪？

这场激辩之所以如此激烈，是因为它触及了Go社区内部长期存在的深层张力：

1. “Google的Go” vs “世界的Go”：Go的许多设计源于解决Google内部特定问题的需求（C++编译慢、monorepo文化）。这种“出身”决定了它在某些方面与更广阔的编程世界存在脱节。早年对单调时钟的忽视就是典型例子。
2. 简单主义 vs 现代语言特性：Go的创造者们带着一种“回归本源”的复古主义情怀，刻意回避了过去几十年编程语言理论的发展成果，如高级类型系统、代数数据类型等。这使得Go易于上手，但也让它在处理复杂逻辑时显得捉襟见肘，迫使开发者“用代码的冗余换取语言的简单”。
3. 显式 vs 便利：if err != nil是显式的，但它不便利。Result类型和?操作符是便利的，但它在某种程度上是隐式的。Go坚定地站在了“显式”这一边，但社区中渴望“便利”的声音从未停止。

小结

将Go的这些“罪状”简单归结为“错误”也是片面的。它们是Go强硬的、自洽的设计哲学所带来的必然产物。

• 这是一门有“历史”的现代语言：Go的设计深受其创造者们在C、Unix、Plan 9上的经验影响。它继承了C的简洁，但也继承了其对底层细节的暴露。
• 承认权衡，理解其生态位：Go在“开发效率”、“运行性能”和“语言简单性”之间做出了明确的取舍，在云原生、微服务领域找到了无与伦比的“甜蜜点”。
• 缓慢的进化也是一种承诺：Go团队对语言的改变极为谨慎，以维护其著名的向后兼容性承诺。但它并非一成不变。泛型的加入、for range循环变量作用域的修正，都表明Go在倾听社区的声音。

《Go is still not good》及其引发的激辩，为我们提供了一个宝贵的窗口，去重新审视这门既年轻又充满“历史感”的语言。它提醒我们，没有完美的语言，只有充满权衡的工具。

对于Go开发者而言，理解这“七宗罪”的来龙去脉，不仅能帮助我们写出更健壮、更地道的代码，更能让我们清晰地认识到Go的优势与边界。与其无休止地争论它是否“足够好”，不如深入思考：它是否是解决我们当前问题的正确工具？ 而这，或许才是这场大辩论给予我们的最大启示。

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/08/21/go-rust-official-voices

大家好，我是Tony Bai。

最近，在阅读 Rust 核心团队负责人 Niko Matsakis 庆祝十周年的系列博文时，我注意到了一个有趣的现象。我下意识地将他的文字，与我长期关注的 Go语言之父Rob Pike以及Go 团队前技术负责人 Russ Cox 的文章放在一起对比。

这时我发现，两者窗外的风景截然不同。

一边，Niko Matsakis 这样写道：

“Graydon（Rust创始人）为我们设定了正确的‘北极星’……‘是的，我们可以拥有好东西’，我常这么想。这句话也捕捉到了 Rust 的另一种特质，那就是试图挑战关于‘权衡’的传统智慧。”

另一边，Russ Cox 在一篇关于 Go 模块依赖的重要文章中，开篇即是：

“本文定义了 Go 模块，这是对 go get 命令支持的版本化依赖的提议。这篇文章是七篇文章中的第一篇，描述了一个关于版本化 Go 的全面提案。”

可以看到，一种声音像一位哲学家，在讨论愿景和原则；另一种，则像一位总工程师，直接给出工程计划。

这并非偶然的文笔差异。

一门编程语言核心团队的写作风格，不只是表面的文字选择，而是其设计哲学、治理模式和社区文化的直接反映。 它在很大程度上预示了这门语言的演进方向，以及它最终会吸引哪一类开发者。

今天，我想和你一起分析这两种迥异的“官方之声”，并尝试回答一个核心问题：

在 Rust 的哲学思辨与 Go 的工程决断之间，究竟隐藏着怎样的语言灵魂与未来？

Rust 的“探索式叙事”——在复杂世界中寻求赋能

如果你长期阅读 Rust 官方博客或 Niko Matsakis 的个人博客，会发现一种独特的叙事模式：愿景驱动，讨论权衡，社区对话。

Niko 的“Rust 2025”系列，开篇并非罗列要实现的功能，而是先定义 Rust 的“核心使命”——赋能基础软件。他花了不少篇幅来构建一个叙事框架，用“北极星”来比喻指引方向的技术与文化原则，用“大力水手菠菜”来形容类型系统的作用，用“平滑的迭代式深化”来描述理想的用户体验。

这种风格的背后，是对一个根本事实的承认：系统编程本身是复杂的。

Rust 的设计哲学，不是回避这种复杂性，而是正视它，并提供一套强大的工具去驾驭它。这套工具，就是其所有权系统、生命周期和 Trait 系统。

这些工具无疑是复杂的，也带来了陡峭的学习曲线。但 Rust 官方文章的字里行间，总是在传达一个核心信念：这种复杂性，是为了换取一种前所未有的“赋能 (Empowerment)”。

当你掌握了这些工具，你便能在编译器的帮助下，编写出兼具高性能、内存安全和高度抽象的代码。这是一种“先难后易”的设计。Rust 的文章，就像一位向导，它不否认前路复杂，但会耐心解释工具的用法，并清晰地展示目标达成后所能获得的能力，让你相信这种投入是值得的。

这种“探索感”也体现在 Rust 的社区文化和治理模式上。

Niko 在文章中反复使用 “我们 (we)” 这个词，而这个“我们”，指代的通常是整个 Rust 社区和所有贡献者。他乐于讲述 ACM 获奖名单难产的故事，以此来证明 Rust 的成功是“集体所有”的。

这种对话式的风格，与其开放的 RFC (Request for Comments) 流程是一致的。任何重大的语言变更，都必须经过漫长、公开的社区讨论。Rust 的进化，是一个由全球开发者共同参与、自下而上推动的过程。

所以，当你阅读 Rust 的“官方之声”时，你其实是在了解一个公开的设计讨论。它邀请你一起思考“什么是更好的软件”，并相信通过集体的智慧，能够不断接近理想的答案，哪怕过程充满思辨与权衡。

Go 的“工程化叙事”——在现实世界中追求简洁

现在，让我们切换到 Go 的世界。

如果你阅读 Russ Cox 或 Rob Pike 的文章，会立刻感受到一种截然不同的气息：问题驱动，逻辑清晰，方案明确。

Go 的文章，几乎总是以一个具体的、待解决的工程问题开篇。无论是包管理的混乱，还是泛型的缺失，他们会用严谨的逻辑，一步步地分析问题背景、评估现有方案，最终给出一个经过深思熟虑的官方提案。

这里没有宏大的比喻，取而代之的是清晰的数据、代码示例和对各种边界情况的分析。他们追求的不是思想的深邃，而是方案的“显而易见 (obvious)”。

这种风格背后，是对另一个根本事实的坚守：大规模软件工程的核心挑战，是控制复杂性。

Go 的设计哲学，可以概括为“规定性的简单性 (prescriptive simplicity)”。它相信，通过提供一个更小的工具集，并制定严格的工程规范（如 gofmt），可以显著降低团队协作的认知成本，从而提升整体生产力。

Go 团队清楚，每一个新加入语言的特性，都是一种“复杂性预算”的支出。因此，他们对此极为审慎。泛型这个功能，Go 社区讨论了近十年，核心团队才最终拿出一个他们认为足够简单、不会破坏 Go 核心价值的方案。

在这种哲学下，Go 的文章读起来就像一份工程白皮书。它不展示所有可能的路径，而是直接告诉你那条经过专家团队验证过，被认为最平坦、最宽阔的道路。它传递的核心信念是：“相信我们，这条路最简单直接，最能规模化。”

这种“决断感”也体现在 Go 的治理模式上。

Go 的演进，更多是由一小群核心专家（很多来自 Google）主导的“自上而下”模式。虽然他们也会通过提案流程征求社区反馈，但最终的决策权高度集中。文章中，“我们 (we)”这个词，更多时候指代的是 Go 核心团队。

这种模式保证了 Go 的稳定性和向后兼容性，但也意味着语言的演进会更加保守。Go 的进化，更像是一系列精准解决现实问题的“外科手术”，而非一场开放式的探索。

所以，当你阅读 Go 的“官方之声”时，你其实是在看一份来自顶级工程团队的技术报告。它不侧重于邀请你参与设计权衡，而是直接为你提供一个经过验证的、旨在解决你当前问题的最佳实践。

文字的岔路口，语言的未来

这两种截然不同的叙事风格，如同两条岔路，清晰地预示了 Rust 和 Go 在未来演进道路上的不同选择。

Rust 的未来，将是一场对语言能力边界的持续探索。

它会继续在“可扩展编译器”、“语言互操作”、“函数Traits”等领域，尝试为开发者提供更强大的“赋能”工具。它的进化过程将继续是思辨性的、社区驱动的，充满思想碰撞。这也可能意味着，它的学习曲线在短期内不会变得平缓，而重大的新特性，依然需要较长的讨论和共识周期。

Go 的未来，则是一场稳健的工程建设。

它将继续保持克制和实用主义。下一个重大变更，几乎可以肯定是为了解决大规模工程中出现的下一个具体痛点（比如，可感知NUMA的GC、对SIMD指令的内置支持等）。Go 会极力捍卫其“简单”的核心价值，避免任何可能导致语言心智模型复杂化的改动。它的进化将是可预测的、问题驱动的。

在这里，我想提出一个或许能概括两者差异的观点：

Rust 试图通过提供复杂的工具，让你成为一个思考更周全、能力更强的程序员；而 Go 则试图通过提供简单的工具，让你立即成为一个在团队中高效协作的程序员。

一个是授你以渔，但渔具复杂；一个是直接给你一条标准化的、足够好用的鱼竿。

小结：开发者如何选择？——聆听与你共鸣的声音

到这里，我们已经清晰地看到，Rust 和 Go 的“官方之声”背后，是两套截然不同的世界观。

• Rust 的世界观是赋能与驾驭： 它相信通过赋予开发者强大的工具，可以驾驭固有的复杂性，构建出理论上最优的软件。
• Go 的世界观是约束与纪律： 它相信通过设定清晰的约束，可以消除不必要的复杂性，构建出工程上最稳健、最易于维护的软件。

那么，作为开发者，我们该如何选择？

我的建议是，超越那些性能跑分和“Hello World”的语法对比，去读一读他们核心团队的文章吧。

问问你自己：

• 你是更倾向于一场开放式的、关于“可能性”的哲学讨论，还是更需要一份逻辑严密、直指问题核心的工程方案？
• 你是在寻找一个与你一同探索复杂问题的“伙伴”，还是一个为你提供清晰建造指南的“总工程师”？

这个问题的答案，可能比任何技术指标都更能决定你的项目能否成功、你的团队是否快乐。

因为最终，我们选择一门编程语言，远不止是选择一个编译器和一套库。我们是在选择一个与之共鸣的社区，一套解决问题的世界观，一种塑造我们思维方式的技术文化。

而这一切，早已写在了他们的字里行行间。

你，听到了哪种声音的回响？

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

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

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

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

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

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