Go语言 - Tony Bai

本文永久链接 – 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/05/brad-fitzpatrick-cachelink-reduce-go-test-wait-time

大家好，我是Tony Bai。

在维护大型 Go 单体仓库（Monorepo）时，你是否遇到过这样的场景：明明只是修改了测试的运行参数（比如 -run 的正则），或者在不同的 CI 节点上运行同一个包的测试，却发现 go test 依然在缓慢地执行“链接（Linking）”步骤？

对于代码量巨大的项目，链接过程往往是构建链条中最耗时的一环。为了解决这一痛点，Go 社区领袖、Tailscale 核心开发者 Brad Fitzpatrick 近日提交了 #77349 提案，建议引入 -cachelink 标志。这一看似微小的改动，有望在分布式测试和重复执行场景下，显著“挤出”原本被浪费的等待时间。

被忽视的瓶颈：重复链接的代价

Go 的构建缓存（GOCACHE）机制已经非常高效，它能很好地缓存编译阶段的中间产物（.a 文件）。但是，当你运行 go test 时，工具链的最后一步——将所有依赖链接成一个可执行的测试二进制文件——通常是“一次性”的。

这意味着，即使你的代码没有任何变动，只要测试指令稍有变化（例如多次运行 go test 但指定不同的测试用例），Go 工具链往往会重新触发链接器。

# 第一次运行：链接 + 执行
$ go test -run=^TestFoo$ ./pkg/

# 第二次运行（代码未变）：依然触发重新链接 + 执行
$ go test -run=^TestBar$ ./pkg/

对于依赖项数以千计的大型项目，链接过程可能长达数秒甚至更久。在本地频繁调试或 CI 流水线中，这些重复的秒数累积起来就是巨大的时间浪费。

Brad 的解法：-cachelink

Brad Fitzpatrick 的提案非常直接：允许将链接器输出的最终测试二进制文件，也写入 GOCACHE。

通过显式开启 -cachelink，go test 的行为将发生变化：

它会基于构建输入（代码、依赖、环境变量等）计算哈希。
如果发现 GOCACHE 中已经存在已链接好的测试二进制文件。
直接跳过链接步骤，复用该文件进行测试。

这样，上述例子中的第二次调用将瞬间启动，因为最耗时的构建步骤被完全省去了。

为什么不做成默认行为？

既然能提速，为什么不默认开启？Brad 在提案讨论中给出了专业的权衡分析：

空间 vs. 时间。

测试二进制文件通常包含完整的符号表和调试信息，体积比普通的中间对象文件大得多。如果默认缓存所有测试二进制文件，开发者的磁盘空间（GOCACHE）会迅速膨胀。因此，这是一个以空间换时间的策略，更适合由开发者根据项目规模手动开启，或者在 CI 环境中配置。

分布式 CI 的“加速器”

该提案真正的杀手级应用场景是分布式 CI 系统。

许多大厂使用 GOCACHEPROG 来在构建集群间共享缓存。在典型的 CI 流程中，测试任务往往会被分片（Sharding）到数十台机器上并发执行。

现状：每一台机器拉取源码后，都需要各自进行一次链接操作，浪费计算资源。
引入 -cachelink 后：第一台完成构建的机器会将二进制文件上传到共享缓存。后续几十台机器直接下载该文件并运行，全集群的链接成本降为“1”。

不仅是 go test -c

有经验的开发者可能会问：“我为什么不直接用 go test -c 手动编译成二进制文件，然后分发运行呢？”

Brad 指出，手动管理二进制文件会绕过 Go 原生的测试结果缓存。而 -cachelink 的精妙之处在于，它既复用了二进制文件，又保留了 go test 完整的缓存与输出管理体验。你不需要编写复杂的脚本来管理这些文件，一切依然由 go 命令自动处理。

小结

目前，该提案已进入活跃评审阶段，并有了初步的代码实现。对于深受“构建慢”和“测试慢”困扰的大型项目维护者来说，这无疑是一个值得期待的性能优化利器。我们有望在 Go 1.27 或后续版本中见证它的落地。

资料链接：https://github.com/golang/go/issues/77349

聊聊你的构建之苦

链接时间正在成为你的“带薪摸鱼”理由吗？在你的项目中，go test 运行一次通常需要多久？你为了缩短测试反馈周期，还尝试过哪些黑科技（比如 GOCACHEPROG）？

欢迎在评论区分享你的实战经验或吐槽！让我们一起期待 -cachelink 的落地。