本文永久链接 – https://tonybai.com/2026/02/08/go-boilerplate-code-vs-rust-data-refutes-stereotypes

大家好，我是Tony Bai。

在编程语言的鄙视链中，Go 语言常常因为其“繁琐”而饱受诟病。

“if err != nil 写断手”、“缺乏语法糖”、“到处都是重复的样板代码”…… 这些似乎已经成为了 Go 的标签。

相比之下，Rust 往往被视为“表达力”的代表，拥有强大的宏、模式匹配和类型系统，能够用更少的代码做更多的事。

然而，Ben Boyter 最近的一项硬核研究，通过分析 GitHub 上各语言 Top 100 仓库（总计约 4 亿行代码），得出了一个令编程语言社区大跌眼镜的结论：

在代码重复率和“样板代码”密度上，Go 和 Rust 几乎处于同一水平线。

不仅是行数：ULOC 指标

传统的 SLOC（源代码行数）往往无法真实反映项目的复杂度和冗余度。Ben Boyter 使用了他开发的工具 scc 中的一个特殊指标：ULOC (Unique Lines of Code，唯一代码行数)。

ULOC 指标并非简单的“全量去重”，而是通过剥离“结构性噪音”来更精准地衡量系统的真实复杂度。其计算逻辑如下：

• 剔除结构化冗余：不仅排除了空行，还排除了单纯的闭合大括号行（}）以及在不同文件中大量重复出现的公共引用代码（如 include 或 import）。
• 过滤文件级模板：有效识别并扣除在项目中每个文件顶部几乎完全相同的 License（许可证）声明头，避免这些非逻辑性的“样板文字”虚增代码总量。
• 计入注释成本：与传统 SLOC 不同，ULOC 会保留注释统计。作者认为，注释与代码一样需要同等的维护精力，反映了开发者的思考过程，因此属于“有效工作量”。

通过这种方式计算出的 Dryness（干度），代表了剔除“语法支架”和“版权模板”后，真正的业务逻辑与注释在代码中的占比。百分比越高，说明重复代码越少，信息密度越高；百分比越低，说明“样板代码”或重复结构越多。

令人震惊的对比：Go vs Rust

让我们直接看数据（数据来源：GitHub Top 100 仓库分析，2026年2月）：

发现了吗？Rust (60.5%) 和 Go (58.78%) 的差距微乎其微，甚至可以说在统计学上是等价的。

Ben Boyter 在文章中坦言，他之前也持有“Go 的样板代码比 Rust 多得多”的刻板印象。但数据表明，虽然两者的“啰嗦”方式不同，但结果是一样的：

• Go 的啰嗦：体现在显式的错误处理、显式的循环结构，以及为了简单性而不得不写的重复逻辑。
• Rust 的啰嗦：体现在复杂的类型系统设置、Trait 的实现（impl blocks）、以及为了满足借用检查器而编写的“仪式性”代码。

正如作者所总结的：

Go 狂热者：“Go 很简单！” -> “是的，简单到你需要把同一件事写很多遍。”
Rust 狂热者：“Rust 完美表达！” -> “是的，但你花了 40% 的时间在写 setup 代码和 trait 实现。”

其他颠覆性的发现

除了 Go 和 Rust 的“握手言和”，这份报告还有几个极具冲击力的发现：

1. Lisp 家族是“干度之王”

Clojure 以 77.91% 的惊人密度位居榜首。Haskell 紧随其后。

这验证了一个古老的观点：如果你想要最高的“人类思想 vs 击键次数”比率，Lisp 和函数式语言依然是王者。它们几乎每一行代码都是纯粹的业务逻辑。

2. Java 居然比 Go 和 Rust 都“干”？

Java 的得分为 65.72%，显著高于 Go、Rust 和 C#。

这听起来反直觉，毕竟 Java 以 PublicStaticVoidMain 这种冗长著称。但这可能说明：

• 现代 Java 及其生态（Spring 等）通过注解等方式极大地消除了样板代码。
• 或者，Top 100 的 Java 项目多为成熟的业务系统，核心逻辑占比大，而 Go/Rust 项目中系统级代码（通常包含更多底层重复逻辑）较多。

3. 脚本语言的特异性

Shell Script 的密度极高（72.24%），但这主要是因为 Shell 脚本通常很短且高度定制化（Bespoke），很难复用，因此“唯一性”很高。

小结：复杂度的守恒

这个研究告诉我们一个道理：语言特性（Features）并不一定能消除复杂度，它往往只是转移了复杂度。

Go 选择了少量的特性，导致逻辑必须通过显式的重复代码来表达；Rust 选择了丰富的特性（宏、泛型、Trait），导致开发者必须编写大量的结构性代码来支撑这些特性。

对于 Gopher 来说，这或许是一种宽慰：别再为 if err != nil 感到羞愧了。隔壁写 Rust 的兄弟，虽然代码看起来很酷，但他们为了让编译器开心而敲击键盘的次数，并不比你少。

毕竟，软件工程没有银弹，只有取舍。

资料链接：https://boyter.org/posts/boilerplate-tax-ranking-popular-languages-by-density/

聊聊你的“啰嗦”体验

看完这个数据，你是感到“意料之中”还是“大吃一惊”？在你的实际开发中，你觉得 Go 的 if err != nil 更磨人，还是 Rust 的类型体操和 Trait 实现更让你头大？你认同“复杂度守恒”这个观点吗？

欢迎在评论区留下你的看法，让我们来一场理性的“语言之争”！

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

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2026/02/06/go-2-dont-become-a-frankenstein-monster

大家好，我是Tony Bai。

“Go 2, please don’t make it happen.”

近日，一张充满讽刺意味的老梗图在 r/golang 社区又炸开了锅。图片的上方，是我们熟悉的 Gopher 吉祥物——那只呆萌、简单、甚至有点傻气的蓝色地鼠，它象征着 Go 语言纯粹而克制的灵魂。

而在图片的下方，这只 Gopher 发生了一场令人毛骨悚然的“变异”：它长出了巨大的龙翼，上面写着“Generics”（泛型）；它生出了锋利的机械利爪，标签是“Try/Catch”；它的身体变得臃肿不堪，缝合了“Mixins”（混入）、“Lambda 表达式”、“操作符重载”、“多态方法”等各种来自其他语言的特性。

这只被缝合得面目全非的怪兽，被标注为——“Go 2”。

时隔多年，这幅图再次引爆了社区，获得了数百个点赞和近百条激烈的评论。尽管 Go 语言的掌舵人 Russ Cox 在2023年的一篇名为“Backward Compatibility, Go 1.21, and Go 2”的博客文章中就早已明确表示“Go 永远不会有破坏性的 Go 2”，但这个话题依然像一根敏感的神经，触动了无数 Gopher 内心深处最隐秘的恐惧：我们热爱的这门语言，会不会最终也难逃“熵增”的宿命，变成另一个臃肿复杂的 C++ 或 Java？

今天，就让我们借着这场社区激辩，再次探讨一下 Go 语言的过去、现在与未来。如果 Go 真的变成了那个“缝合怪”，你还会爱它吗？

恐惧的根源：当“简单”成为一种罪过

帖子下的最高赞评论，道出了许多资深 Gopher 的心声：“想要 Go 2 的人，能不能去玩别的语言？”

这句话听起来充满火药味，但它背后隐藏着 Go 语言最核心的价值观冲突。在编程语言的鄙视链中，Go 常常因为“特性贫乏”而遭到嘲笑。

• “为什么没有三元运算符？写 if-else 手都酸了。”
• “为什么没有 map、filter、reduce？手写 for 循环太原始了。”
• “为什么没有异常处理？满屏的 if err != nil 简直是精神污染。”

对于习惯了 Python 列表推导式、Java 注解魔法或 Rust 模式匹配的开发者来说，初见 Go 语言简直就像是从现代文明回到了石器时代。这种“匮乏感”是真实的，也是痛苦的。

然而，对于另一群人来说，这种“匮乏”恰恰是 Go 最大的特性。

有位Go拥趸在评论中就犀利地指出：“Go 的表现力不来自于模仿 Turbo Pascal 或其他语言的语法糖，而来自于开发者对自己构建内容的清晰愿景。”

试想一下，如果 Go 真的引入了所有这些特性，它会变成什么样？

// 一个想象中的“变异版” Go 代码
try {
    var result = list.filter(x => x > 0).map(x => x * 2).reduce((a, b) => a + b);
    result ? process(result) : throw new Error("Empty result");
} catch (e) {
    logger.error(e);
}

这段代码看起来很“现代”，很“简洁”，对吧？但它还是 Go 吗？当你看到这段代码时，你能一眼看出它的性能开销吗？你能确定 filter 和 map 中是否有隐藏的闭包分配？你能确定 throw 会跳过哪些资源释放逻辑吗？

不能。 Go 的核心哲学之一是“所见即所得” (What you see is what you get)。Go 代码可能写起来啰嗦，但读起来极其清晰。没有隐藏的控制流，没有魔法般的隐式转换。如果为了迎合所有人的口味，把 Rust 的枚举、Java 的注解、Python 的语法糖都塞进 Go 里，那么 Go 就不再是 Go，而变成了一个拙劣的模仿者。

正如另外一位开发者所言：“如果我想要繁琐和过度设计，我为什么不去用 Java 呢？”

渴望的呼声：那些“不得不爱”的语法糖

然而，硬币的另一面是，社区的呼声并非全无道理。大家虽然嘴上说着“不要 Go 2”，身体却很诚实地想要一些具体的改进。在激烈的辩论中，有几个特性的呼声高居不下，它们代表了 Go 语言目前最真实的痛点。

真正的枚举 —— 呼声最高的“刚需”

这是目前 Go 社区最大的痛点之一。Go 现在的枚举实现方式是 const 加上 iota：

const (
    StatePending = iota
    StateRunning
    StateFailed
)

这本质上只是给整数起了一个别名。它最大的问题是缺乏类型安全。你完全可以把一个 State 类型的变量赋值为 100，编译器不会有任何怨言。而且，你无法像 Rust 或 Swift 那样，在枚举中携带额外的数据（Sum Types / Tagged Unions）。

一位开发者的评论获得了大量赞同：“我只想要真正的枚举。现在的枚举感觉像是黑客拼凑出来的。”

想象一下，如果 Go 有了类似 Rust 的枚举，我们的错误处理和状态机代码将会变得多么优雅和安全。这不仅仅是语法糖，这是对类型系统的一次重要补全。

空值安全 —— 生产环境的“救命稻草”

虽然 Go 有了泛型，但 nil 指针解引用依然是生产环境中的一大杀手。在 Java 和 C# 都在引入 Optional 或可空类型的大趋势下，Go 的 nil 处理显得有些落伍。

有人希望能引入 ?? (空值合并) 或 ?. (可选链) 运算符。

• 一位开发者提及：“只要给我空值合并和可选链，我就满足了。”
• 但反对的声音同样强烈。另外一位开发者惊恐地喊道：“别！我刚从 JS 的陷阱里逃出来，不想再跳进另一个。”

这种分歧展示了 Go 设计的艰难：每一个看似微小的语法糖，都可能引入新的复杂性和不可预知的副作用。

错误处理的简化 —— if err != nil 的审美疲劳

尽管 if err != nil 是 Go 的标志，但在业务代码中，它确实占据了大量的视觉空间，有时甚至掩盖了核心逻辑。

社区中一直有关于 try() 提案或 ? 操作符的讨论。大家希望能在保留“显式错误处理”这一核心语义的前提下，减少一些键盘敲击次数。但至今为止，并没有一个提案能完美地平衡“简洁”与“清晰”。甚至Go官方都不得不宣布，先将错误处理的语法糖改进放一放，缓一缓。

历史的镜鉴：Java 的教训与 C++ 的警示

为了理解为什么 Go 社区对“增加特性”如此警惕，我们需要把目光投向历史。

在评论区中，Java 成为了被反复提及的反面教材。许多从 Java 转过来的 Gopher 对 Java 的“过度设计”深恶痛绝。

• 注解地狱：Spring 框架中的注解虽然方便，但它让代码的运行时行为变得极其难以预测。你看着代码，却不知道它到底在干什么。
• 层层抽象：为了所谓的“灵活性”，Java 社区习惯于构建一层又一层的抽象，导致调用栈深不见底。

有人评论道：“Java 并没有强迫你写得那么繁琐，是‘企业级 Java’的文化导致了这一切。” 但问题在于，语言的特性往往会塑造社区的文化。当你提供了复杂的抽象能力，开发者就会忍不住去用它。

Go 的创始人 Rob Pike 曾说过，Go 是为了解决 Google 的软件工程问题而设计的。在 Google，有数万名工程师在同一个代码库上工作，人员流动频繁。代码的可读性、一致性和可维护性，远比“写得爽”更重要。

Go 通过“限制”开发者的能力（比如不支持继承、不支持重载），强迫大家写出风格一致、简单直白的代码。这是一种“防御性”的语言设计，它牺牲了上限（极致的表达力），保住了下限（代码不会烂得太离谱）。

现实：Go 2 其实已经发生了

在讨论的喧嚣中，有一个冷静的声音提醒大家：其实，我们已经身处 Go 2 的时代了，只是它不叫 Go 2。

回顾过去几年，Go 并非一成不变，而是在经历着一场惊心动魄的、却又润物细无声的进化。

• 模块化 (Go Modules)：从 GOPATH 到 go.mod，Go 的依赖管理经历了一次彻底的重构，解决了困扰社区多年的“依赖地狱”问题。
• 泛型 (Generics) 的落地：这是 Go 诞生以来最大的语言变动。经过长达十年的争论、数个方案的推翻重来，Go 团队最终在 1.18 版本中，以一种极其克制、与现有语法高度兼容的方式引入了泛型。它没有破坏现有的代码，也没有引入过度的复杂性。这是一个奇迹。
• for循环变量语义修复、函数迭代器、结构化日志 (slog)、工具链升级、性能优化…

Go 正在遵循 Russ Cox 当初提出的“渐进式演进”路线图。它没有像 Python 2 到 Python 3 那样，通过一个破坏性的“Go 2.0”版本来割裂社区，造成长达十年的痛苦迁移；而是选择了向后兼容这条最为艰难的道路。

正如一位开发者所言：“我爱 Go 的一点是，我可以拿着 10 年前的项目代码，用最新的编译器直接编译通过。这是一个疯狂的成就。”

这种稳定性，是商业公司敢于将核心业务押注在 Go 上的根本原因。

小结：在此刻，爱上“不完美”

这场关于 Go 2 的辩论，本质上是两种价值观的碰撞：“特性的丰富” vs “工程的克制”。

我们必须承认，Go 不是完美的。它确实有一些恼人的地方，有一些需要体力和耐心的重复劳动。但正是这些“不完美”，构成了 Go 独特的性格。

Go 注定不会成为一个拥有所有炫酷特性的语言。它就像那辆你从父辈那里继承来的老本田车：

它可能没有最先进的自动驾驶功能，没有最豪华的内饰，也没有令人血脉偾张的加速推背感。

但是，它极其可靠、结构简单、易于维修，并且总能把你安全地送到目的地。

当你在深夜维护一个高并发的微服务时，当你面对一个由离职同事留下的陌生代码库时，你会感谢 Go 的“简单”。你会庆幸没有那些魔法般的隐式转换，没有那些层层叠叠的抽象，只有一行行清晰、直白、甚至有点笨拙的代码，告诉你程序到底在做什么。

所以，与其期待一个面目全非的“缝合怪” Go 2，不如在当下，享受这种“简单”带来的确定性与安宁。

Go 2，请不要发生。因为现在的 Go，已经足够好。

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

你的“底线”在哪里？

Go 语言的简洁与克制，让它成了我们心中的那辆“本田车”。但如果真的有一次机会，你最希望 Go 引入的一个“语法糖”是什么？又或者，哪个特性的引入会让你觉得它彻底变了，让你决定弃坑？

欢迎在评论区留下你的“真爱宣言”或“退坑预警”！让我们一起探讨 Go 的未来模样。

如果这篇文章说出了你作为 Gopher 的心声，别忘了点个【赞】和【在看】，转发给你的伙伴，看看他们的“底线”又在哪里！

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

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

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

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

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

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

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

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

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