小型标准库意味着传递依赖性的爆炸式增长。更全面的标准库可以帮助您最大限度地减少依赖性。不要误解我的意思：在现实世界的项目中，零依赖几乎是不可能的。
Armin Ronacher呼吁程序员之间的氛围转变，我认为这实际上已经存在。就这个主题与我交谈过的每个人都同意最小化依赖性是理想的。
Rust 和 JavaScript 及其令人难以置信的最小标准库与这种理想背道而驰。相比之下，Go、Python、Java 和 C# 拥有不错的标准库，这有助于最大限度地减少传递依赖项的爆炸。
示例
我认为标准库应该合理地包括：
- JSON、CSV 和 Parquet 支持
- HTTP/2 支持（包括 TLS、压缩、随机数生成等）
- 支持异步IO
- 日志抽象
- SQL 客户端抽象
- 关键抽象数据类型（BTree、哈希图、集合和可增长数组）
- 用于处理 Unicode、时间和时区的实用程序
但我认为它不需要包括：
- Excel支持
- PostgreSQL 或 Oracle 客户端
- 平面缓冲区支持
- 利基数据结构
这些都不是完整的列表，只是示例。
有围墙的花园
最小标准库迫使公司在发展过程中尽早建立自己的内部“标准库”集合。这使得大公司可以避免传递依赖随着时间的推移而爆炸。随着时间的推移，随着时间的推移，所有公司都可能会这样做。但同样，较小的标准库会激励公司尽早构建这个内部标准库。
相比之下，较小的组织没有资源来培育这样的内部生态系统。较小的组织和整个社区不会从较大组织的内部标准库中受益。
也许它会催生像 Boost for JavaScript 和 Rust 程序员这样的库。这可能没问题。
版本控制
全面的标准库并不妨碍语言开发人员发布标准库的新版本。通过命名来做到这一点很简单，就像 Go 对v2模式所做的那样。 math/rand/v2就是一个例子。
结论
我对标准库的担忧并没有阻止我使用 Rust 和 JavaScript。此外，他们可以随时选择投资标准库。我们已经开始看到Bun和Deno正是这样做的。但这显然是 Rust 和 JavaScript 需要改进的领域。并避免其他语言重复的错误。
虽然零依赖性实际上是不可能的，但与我交谈过的每个人都同意最小化依赖性是理想的。 Rust 和 JavaScript 违背了这一理想。但他们随时可能改变。 Bun 和 Deno 就是这样的例子。 https://t.co/qkSh6oW1Yd pic.twitter.com/mY1MNErZG7
— Phil Eaton (@eatonphil) 2025 年 1 月 25 日
原文： http://notes.eatonphil.com/2025-01-25-an-explosion-of-transitive-dependencies.html