Prefer small crates


Prefer small crates that do one thing well.

Cargo and make it easy to add third-party libraries, much more so than in say C or C++. Moreover, since packages on cannot be edited or removed after publication, any build that works now should continue to work in the future. We should take advantage of this tooling, and use smaller, more fine-grained dependencies.


  • Small crates are easier to understand, and encourage more modular code.
  • Crates allow for re-using code between projects. For example, the url crate was developed as part of the Servo browser engine, but has since found wide use outside the project.
  • Since the compilation unit of Rust is the crate, splitting a project into multiple crates can allow more of the code to be built in parallel.


  • This can lead to “dependency hell”, when a project depends on multiple conflicting versions of a crate at the same time. For example, the url crate has both versions 1.0 and 0.5. Since the Url from url:1.0 and the Url from url:0.5 are different types, an HTTP client that uses url:0.5 would not accept Url values from a web scraper that uses url:1.0.
  • Packages on are not curated. A crate may be poorly written, have unhelpful documentation, or be outright malicious.
  • Two small crates may be less optimized than one large one, since the compiler does not perform link-time optimization (LTO) by default.


The url crate provides tools for working with URLs.

The num_cpus crate provides a function to query the number of CPUs on a machine.

The ref_slice crate provides functions for converting &T to &[T]. (Historical example)

See also

Last change: 2024-06-11, commit: 3aa5c21