本文永久链接 – 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/2025/12/07/zootopia-2-perfect-architecture-lie-exposed

大家好，我是Tony Bai。

还记得昨天那篇文章里，我还在为那个“标题党”的题目（《如果〈疯狂动物城〉是一个分布式系统…》）向大家“真诚致歉”吗？

当时，带着重温第一部的滤镜，我信誓旦旦地跟大家吹牛，说动物城简直就是 Go 语言构建的云原生架构典范——高效、隔离、完美。

但这周六下午看完《疯狂动物城2》，我不得不承认：草率了，这次“打脸”来得太快。

如果说第一部展示了架构师眼中的“理想国”，那么第二部则残忍地揭开了“完美架构”背后的谎言。

看着银幕上那条被大家畏惧、却掌握着关键线索的蛇（Gary），以及那个被冰雪掩埋的真相，我脊背发凉。这哪里是童话？这分明就是一部《大型遗留系统（Legacy System）维护血泪史》。

作为架构师，我在这部电影里看到了三个关于“新老技术”的扎心隐喻。

被埋葬的“爬行动物”：那些我们不敢碰的 Legacy Code

在电影里，我们得知了一个惊天秘密：动物城引以为傲的“温控系统”和城市规划，并非现在的创始人（林雪猁, Lynxley）设计的，而是源自一位爬行动物——Agnes（Gary的曾祖母）。

但为了打造一个看似光鲜、只有可爱哺乳动物的“新城区”（Tundratown），管理者选择了掩盖历史。他们直接把爬行动物的家园（Reptile Ravine）埋在了厚厚的冰雪之下，假装它们从未存在。

这一幕，像极了我们对待“遗留代码（Legacy Code）”的态度。

在现代化的 Go 微服务、Kubernetes 集群（Tundratown）之下，往往深埋着一套跑了20年的、由 C/C++ 甚至 Fortran 编写的核心交易系统（爬行动物）。
* 它们古老、丑陋（代码风格甚至没有缩进）；
* 它们看起来危险（改一行代码可能崩全站，就像蛇会咬人）；
* 所以，我们选择“封印”它。我们用一层又一层的 Wrapper、API 网关把它包裹起来，假装我们已经拥有了一个全新的、完美的系统。

但电影告诉我们：物理掩埋解决不了问题。 当危机来临，那些被忽视的底层逻辑，终将“破土而出”。

Gary 的热感应：老技术独有的“超能力”

电影里有一段非常精彩的情节：朱迪和尼克束手无策时，是蛇 Gary 利用响尾蛇特有的“热感应”能力，看透了迷雾，找到了线索。

这让我想起，每当新技术（如 AI、Web3）甚嚣尘上时，我们往往会轻视那些“老古董”。

• 我们觉得 Go/Rust 这种现代语言无所不能。
• 我们觉得 C 语言指针复杂、汇编晦涩、SQL 存储过程老土。

但真到了极端场景——比如需要极致的性能优化、极底层的硬件交互时，我们发现，还得靠那些“老家伙”。Gary 代表的，正是那些虽不时髦、但拥有独特“底层视角”的技术能力。

正如 Go 语言之所以强大，不是因为它切断了过去，而是因为它通过 CGO、通过汇编支持，保留了与底层世界对话的能力。

不要傲慢地认为新技术能替代一切。有时候，解开死锁的钥匙，藏在一行 10 年前写的 C 代码里。

创始人的日记：文档与“去伪存真”

(以下内容涉及核心剧透)

电影的高潮，是朱迪必须找到 Agnes 留下的日记本和专利书，才能揭穿谎言，拯救城市。

这本日记，不就是我们梦寐以求的“核心架构文档”吗？

在很多大厂里，随着人员流动（老一辈架构师离职），系统的“设计初衷”往往丢失了。后来的维护者（Lynxley）为了 KPI，可能会歪曲系统原有的设计，堆砌不合理的“补丁”，甚至把系统改造成一个不可维护的怪兽。

朱迪和尼克的冒险，本质上是一次“考古式重构”：

1. 阅读源码（寻找日记）；
2. 理解上下文（Agnes 的初衷是共存，而不是隔离）；
3. 修正架构（打破冰墙，让爬行动物回归）。

这给所有 Go 开发者提了个醒：写代码时，请留下你的“日记”。 好的注释和文档，是连接过去与未来的纽带。不要让后来者通过“猜谜”来维护你的系统。

写在最后

电影结局，爬行动物回到了动物城，与哺乳动物和谐共处。

二宝问我：“爸爸，蛇和兔子真的能做朋友吗？”

我说：“能啊，只要它们互相尊重。”

技术世界也是如此。我们推崇 Go 的简洁、云原生的弹性，但这并不意味着我们要鄙视那些运行在角落里的单体应用或老旧语言。

真正的“完美架构”，不是推倒重来（Rewrite），而是包容与演进（Evolve）。

它能容得下时髦的微服务（朱迪），也能接纳古老的遗留系统（Gary）。它承认系统的复杂性，并用工程化的手段管理这种复杂，而不是掩耳盗铃。

走出影院，看着手里 2025 年的新技术，再想想公司里那堆跑了 10 年的老代码，我突然多了一份敬畏。

原来，致敬历史，才是通往未来的捷径。

互动话题：

在你的职业生涯中，有没有哪一次“挖坟”经历（维护极老的遗留代码），让你意外地学到了很多东西？或者，你有没有遇到过像 Gary 一样看似可怕、实则核心的“祖传代码”？

欢迎在评论区分享你的“考古”故事！

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

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

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

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

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

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

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

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

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