Rust Developers Petition for a Bigger Standard Library: Should Go Be the Model?

"The Cost of 'Small and Beautiful': The Dammocles Sword Over Every Rust Project"

Rust’s std library is intentionally minimal, offering only core functionality. For anything beyond basics—random numbers, async runtimes, serialization—developers are encouraged to fetch “blessed crates” from crates.io. This model fostered early ecosystem growth, but events like the npm left‑pad incident and supply‑chain attacks have exposed its downside.

“I don’t want to be forced to pull hundreds of third‑party dependencies I have no time to audit just to write a program. Look at Go’s standard library; you can build complex systems with almost no external packages.”

The post quickly gathered ~700 up‑votes and ~300 comments, igniting a debate about the trade‑off between a tiny core and the risk of malicious code hidden deep in dependency trees.

"Go’s 'Batteries-Included' Model"

Go ships with a large, officially maintained standard library that covers web servers ( net/http), JSON/XML handling ( encoding/json, encoding/xml), concurrency ( goroutine, channel), and random number generation ( math/rand, crypto/rand). Because everything lives in the standard library, developers can build high‑performance network services without pulling any third‑party crates, which is especially attractive for teams worried about supply‑chain audits.

Community Struggle: When "Conservatism" Becomes a Bottleneck

Rust core members identified three “locks” that hinder std expansion:

Lock 1 – Backward‑compatibility curse : Once an API enters std, it must remain compatible forever, even if design flaws are discovered decades later.

Lock 2 – Maintenance hell : Adding a crate to std transfers its long‑term upkeep to a small core team, whereas community‑maintained crates have dedicated owners.

Lock 3 – Premature rigidity : Incorporating features like async into std too early could stifle innovation; Rust’s current split between Tokio and non‑Tokio ecosystems gives developers freedom to choose the best tool for each scenario.

Potential Paths Forward: From "Unified" to "Federated"

Several compromise proposals emerged:

Proposal 1 – Semi‑official "extended" namespace : Adopt a namespace such as extd to host vetted crates (e.g., serde, rand, tokio) without inflating std. Example usage:

use extd::regex::Regex;
use extd::rand;

This gives these libraries an official seal while keeping std lean.

Proposal 2 – Incubation phase : Create an “experimental” area similar to golang.org/x where promising crates can mature before being considered for std, reducing the risk of premature inclusion.

Proposal 3 – Strengthen Cargo security : Improve the distribution mechanism of crates.io by introducing release isolation (e.g., a 72‑hour automated scan) and signed packages with trusted auditors, thereby mitigating supply‑chain attacks without expanding the standard library.

Conclusion: A Soul‑Searching Question

The debate is less about library size and more about two contrasting philosophies: Go’s monolithic, “batteries‑included” nation‑state versus Rust’s loosely coupled city‑state federation. Each offers security and convenience at different costs, and the Rust community’s petition highlights the growing importance of a robust, officially backed foundation in an era of fragile software supply chains.