更优的电池
摘要
本文探讨了编程语言社区的社会架构如何影响标准库的设计与质量，并比较了Python、Go和Rust的方法。
<header>
<h1>更优的电池</h1>
<time class="meta" datetime="2026-08-20">2026年8月20日</time>
</header>
<p>编程中一个永恒的分歧在于标准库应该是最小化还是全面化。这是错误的问题。正确的问题是：</p>
<figure class="blockquote">
<blockquote><p>哪种社会架构能创造出高质量的标准库？</p>
</blockquote>
</figure>
<p>Python 常被作为‘电池漏液缓慢爆炸’的例子，但这与大小无关。Python 标准库的问题在于其不均匀的质量。有些标准库模块不遵循语言命名约定！你知道我指的是哪个 <code>unittest</code> 模块 :-)</p>
<p>但这甚至不是错误。这实际上是 Python 核心的优势——它尽早提供功能，不太考虑未来。这就是我们最终有了僵化的 cAPI，使得 CPython 成为语言，但这也是 Python 推动数据科学革命的原因。</p>
<p>Go 标准库同样全面，但备受推崇。Go 团队有能力为标准库提供精心设计的 API，甚至更多：<a href="https://pkg.go.dev/golang.org/x" class="display url">https://pkg.go.dev/golang.org/x</a></p>
<p>Rust 是一个有趣的案例。1.0 标准库 API 非常出色。集合和迭代器堪称艺术。但感觉上，尽管当前团队有能力保留现有 API 并填补一些空白，但执行设计决策的能力有限。虽然 <code>golang.org/x</code> 捕获了过剩容量，但 <code>rust-lang-nursery</code> 却是坟场。也许我过于关注<a href="https://matklad.github.io/2023/01/04/on-random-numbers.html#True-Randomness">我钟爱的话题</a>，但似乎 Rust 在 2026 年还没有一个从操作系统获取随机字节流的 API 的原因是，虽然这是一个简单的技术问题，但在一个名为编程语言的高风险全球协调问题环境中，需要复杂的组织架构（当然包括让人们口袋里有钱）才能真正解决。</p>
查看缓存全文
缓存时间: 2026/08/21 03:34
# 更优的电池
来源: https://matklad.github.io/2026/08/20/better-batteries.html
2026年8月20日
编程领域一个永恒的分歧，围绕着标准库应该追求精简还是包罗万象。但这问错了问题。真正该问的是：
> 何种社会架构能打造出高质量的标准库？
Python 常被举例为「泄漏的电池缓慢爆炸」的典型，但这与规模无关。Python 标准库的问题在于其参差不齐的质量——某些模块竟不遵循语言命名规范！您知道我说的是哪个`unittest`模块对吧 :-)
但这甚至算不上失误。这恰恰是 Python 核心团队的优势：快速提供功能，不过分担忧未来。正是因此，我们获得了固化难改的 C API，让 CPython 成为一门「语言」；也正是因此，Python 推动了数据科学革命。
Go 的标准库同样包罗万象，却享有崇高声誉。Go 团队具备制度性能力，既能为标准库设计高质量 API，更能持续扩展：https://pkg.go.dev/golang.org/x
Rust 则是个有趣的案例。1.0 版本的标准库 API 精妙绝伦，集合与迭代器堪称艺术品。但另一方面，虽然现有团队有能力维护已有 API 并填补部分空缺，其执行重大设计决策的能力却显不足。`golang.org/x` 能够承接溢出的开发需求，而 `rust-lang-nursery` 却沦为「坟场」。或许我过度执着于自己的心头执念（https://matklad.github.io/2023/01/04/on-random-numbers.html#True-Randomness），但 Rust 截至 2026 年仍未提供从操作系统获取随机字节流的 API，其原因似乎正在于此——尽管技术实现简单，但在需要全球协作、涉及资金调度等复杂组织架构的高风险环境中，这类需求难以真正落地解决。
相似文章
Rust语言的性能
本次演讲分析了Rust相较于C++的性能优势与劣势，提供了基准测试和最佳实践。附有幻灯片和阅读材料。
为何常见的Rust包依赖C代码？（2023）
本文探讨为何许多常见的Rust包依赖于C代码，可能讨论技术原因及其对生态系统的影响。
命名参数和可选参数非常优秀
本文批判了Rust对命名参数和可选参数的缺失，对比了Dart、C#、TypeScript与Python的实现方式，并展望了Rust未来的潜在解决方案。
引用 Mitchell Hashimoto
Mitchell Hashimoto 评论编程语言日益增强的可替代性，以 Bun 从 Zig 重写为 Rust 为例，表明语言已不再是锁定效应的来源。
参数之争
本文探讨了在编程语言中使用命名参数和灵活参数风格的权衡，比较了 Rust 的简洁性与 Ruby 的简练性，并对在 Rust 中采用类似功能表示怀疑。