Better Batteries / 更好的“电池”

One of the eternal schisms in programming is over the question of whether the standard library should be minimal or encompassing. This is the wrong question to ask. The right one is: Which social architecture creates a high-quality standard library? 在编程界，一个永恒的分歧在于：标准库究竟应该是“极简主义”还是“大而全”？但这其实是个错误的问题。真正值得探讨的是：什么样的社会架构才能打造出高质量的标准库？

Python is always brought up as example of leaky batteries exploding in slow motion, but this has nothing to do with size. The problem with Python’s stdlib is its, ahem, uneven quality. Some standard library modules don’t follow language naming conventions! You know which unittest module I am talking about :-) Python 总被当作“电池漏液并缓慢爆炸”的反面教材，但这与库的大小无关。Python 标准库真正的问题在于其（咳咳）参差不齐的质量。有些标准库模块甚至不遵循语言本身的命名规范！你应该知道我说的是哪个 unittest 模块吧 :-)

But even that is not a mistake. It’s actually Python core’s advantage — that it makes functionality available early, not thinking about the future too much. That’s how we ended up with ossified cAPI which makes CPython the language, but that is also how we ended up with Python powering data scientific revolution. 但即便如此，这也不算是个错误。这实际上是 Python 核心的优势所在——它能让功能尽早落地，而不必过多纠结于未来。正因如此，我们才有了僵化的 C API，它定义了 CPython 这门语言，但也正是这种模式，让 Python 能够驱动数据科学的革命。

The Go standard library is similarly encompassing, but it is held in a high regard. Go team has institutional capacity to deliver well-designed API for the standard library, and then some: https://pkg.go.dev/golang.org/x Go 语言的标准库同样非常全面，但它却备受推崇。Go 团队拥有足够的组织能力，不仅能为标准库提供设计精良的 API，还能在此基础上进一步扩展：https://pkg.go.dev/golang.org/x

Rust is an interesting case. The 1.0 standard library APIs are brilliant. Collections and iterators are a work of art. But it also feels that, while the current team has the capacity to preserve existing APIs and fill in some gaps, the capacity to execute design decisions is limited. While golang.org/x captures excess capacity, rust-lang-nursery is a graveyard. Rust 是一个有趣的案例。其 1.0 版本的标准库 API 非常出色，集合（Collections）和迭代器（Iterators）简直是艺术品。但给人的感觉是，虽然目前的团队有能力维护现有 API 并填补一些空白，但在执行重大设计决策方面的能力却显得有限。当 golang.org/x 能够承载多余的开发产能时，rust-lang-nursery 却成了项目的坟墓。

Maybe I am over-indexing on my favorite hobby-horse, but it seems that the reason for Rust not having an API to get a stream of random bytes from the OS in 2026 is that, while it is an easy technical problem, it requires tricky organization architecture (including getting money in peoples’ pockets, of course) to actually get solved in the high-stakes environment of a world-wide coordination problem called a programming language. 也许是我太执着于自己的偏见，但 Rust 到 2026 年还没能提供一个从操作系统获取随机字节流的 API，原因似乎在于：虽然这在技术上是个简单问题，但在“编程语言”这种涉及全球协作、高风险的环境下，要真正解决它，需要复杂的组织架构（当然，也包括如何让开发者获得报酬）。