2026年8月20日 编程中的一个永恒分歧是关于标准库应该是最小化的还是全面的。这个问题问错了。正确的问题是：哪种社会架构能够创造高质量的标准库？ Python 总是被拿来作为漏电池慢动作爆炸的例子，但这与规模无关。 Python 的标准库的问题在于其，嗯，不均匀的质量。有些标准库模块并不遵循语言命名约定！你知道我在说哪个 unittest 模块 :-) 但即使那也不是错误。实际上，这是 Python 核心的优势 —— 它使功能尽早可用，而不太考虑未来。这就是我们为什么最终得到了僵化的 cAPI，使 CPython 成为语言，但这也是 Python 驱动数据科学革命的原因。 Go 的标准库同样是全面的，但它在业内享有很高的声誉。 Go 团队有能力提供良好设计的标准库 API，还有更多：https://pkg.go.dev/golang.org/x Rust 是一个有趣的案例。 1.0 标准库 API 非常出色。集合和迭代器堪称艺术品。但感觉上，现在的团队虽然有能力保留现有的 API 并填补一些空白，但执行设计决策的能力是有限的。虽然 golang.org/x 捕捉到了过剩的能力，但 rust-lang-nursery 就像一个墓地。也许我在过度强调我最喜欢的兴趣点，但似乎 Rust 在 2026 年没有一个从操作系统获取随机字节流的 API 的原因，是尽管这是一个简单的技术问题，但它需要复杂的组织架构（当然，包括把钱放到人们口袋里的能力）才能在全球协调问题的高风险环境下得到解决，这个问题叫做编程语言。