Prefer small crates
Prefer small crates that do one thing well.
Cargo and crates.io make it easy to add third-party libraries, much more so than in say C or C++. Moreover, since packages on crates.io 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
urlcrate 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
urlcrate has both versions 1.0 and 0.5. Since the
url:0.5are different types, an HTTP client that uses
url:0.5would not accept
Urlvalues from a web scraper that uses
- Packages on crates.io 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.
url crate provides tools for working with
num_cpus crate provides a function to
query the number of CPUs on a machine.
ref_slice crate provides functions
&[T]. (Historical example)