The forty-five second wait
You watch the terminal spin for forty-five seconds every time you save a file. The instinct is to reach for dynamic linking. Other languages ship shared libraries to avoid recompiling everything. You expect Rust to work the same way. It does not. Rust skips dynamic linking for development speed entirely. The compiler and the package manager handle the heavy lifting through incremental compilation and dependency caching. You get fast rebuilds without touching linker flags.
How Cargo actually saves time
Rust's build pipeline relies on two separate mechanisms that work together. Incremental compilation tracks changes inside your own crate. Dependency caching tracks changes across every external library you pull from crates.io. Neither of them requires shared objects or runtime library loading.
Think of building a house. Static linking is like bringing every brick, nail, and sheet of drywall to the site yourself. You own everything. Dynamic linking is like renting a tool shed from the neighbor. You only carry what you built today, and you borrow the rest when you walk in the door. Rust chooses a different approach. It keeps a detailed ledger of every dependency you have ever downloaded. When you change a single function in your own code, Cargo checks the ledger, sees that the rest of the house has not moved, and only recompiles the room you touched. The linker still produces a single static binary by default, but the build time stays low because the compiler never re-parses unchanged crates.
Leave the [profile.dev] section out of your Cargo.toml. The defaults are already tuned for iteration speed.
The ledger behind the scenes
Cargo stores compiled artifacts in the target/debug/deps directory. Each crate gets a unique hash based on its source code, feature flags, and compiler settings. When you run cargo build, Cargo compares the current hash against the stored one. If they match, Cargo skips the download, the parsing, and the compilation. It only runs rustc on your crate and any dependencies that actually changed.
// src/main.rs
/// Prints a greeting using a helper function.
fn main() {
// The compiler only rechecks this file when it changes.
let message = format_greeting("Rust");
println!("{}", message);
}
/// Formats a simple greeting string.
fn format_greeting(name: &str) -> String {
// String allocation happens at runtime, not compile time.
// Changing this signature forces a recompile of main.rs.
format!("Hello, {}!", name)
}
The dev profile disables optimizations and debug assertions by default. This keeps the compiler pipeline short. Optimization passes like monomorphization and inlining take the most time. Skipping them during development cuts compile time by half or more. You do not need to add flags to get this behavior. Cargo applies it automatically.
Run cargo build --timings to see exactly where the time goes. The generated HTML report shows which crates dominate the pipeline. You will usually see your own crate and a few heavy dependencies like serde or tokio. The rest finish in milliseconds.
Trust the cache. Cargo only recompiles what actually changed.
A realistic project setup
Most projects pull in dozens of crates. The caching strategy scales linearly with dependency count. Adding a new library does not force Cargo to recompile the old ones. It downloads the new crate, compiles it once, and stores the artifact. Future builds reuse it.
# Cargo.toml
[package]
name = "fast-build-demo"
version = "0.1.0"
edition = "2021"
[dependencies]
# serde compiles once. Changing your code never touches it again.
serde = { version = "1.0", features = ["derive"] }
# Adding a new dependency here only compiles that crate.
# Existing cached artifacts remain untouched.
The community convention is to keep Cargo.toml minimal. You rarely need to override [profile.dev]. If you do, you usually break the incremental pipeline by forcing features that trigger heavy compiler passes. Stick to the defaults until profiling proves otherwise.
When you add a new file to src/, Cargo runs the parser and type checker on that file only. It links the new object file into the existing binary. The linker step is fast because it only resolves symbols for the changed crate. The rest of the dependency tree stays linked from the previous run.
Do not fight the default profile. It is already optimized for your edit loop.
What happens when you force dynamic linking
Some developers try to speed up builds by switching to shared libraries. They add crate-type = ["dylib"] to Cargo.toml or compile with -C prefer-dynamic. This changes the output from a static archive to a shared object. It does not make cargo run faster. It shifts work from compile time to runtime.
Dynamic linking requires the operating system to locate the .so, .dll, or .dylib file when the program starts. If the path is wrong, the runtime loader fails before your code runs. You will see a linker error like E0463 (can't find crate) during compilation, or a Library not loaded panic at startup. The compiler still has to parse and type-check every dependency. The only difference is that the final binary is smaller because it drops the object code for external crates.
// src/lib.rs
/// Exposes a public API for external consumers.
/// Marking this as a dylib changes the output format, not the compile time.
pub fn calculate() -> i32 {
// The compiler still runs all analysis passes on this function.
// Shared libraries do not skip type checking or monomorphization.
42
}
Dynamic linking also breaks the single-binary deployment model. You must ship the shared library alongside your executable. You must configure LD_LIBRARY_PATH or DYLD_LIBRARY_PATH on every target machine. You introduce ABI compatibility risks across OS updates. The compile time savings are zero. The operational cost is high.
Keep your crates static unless you have a plugin architecture. The build speed comes from caching, not from splitting the binary.
When to reach for shared libraries
Use dynamic linking when you are building a plugin system where third parties drop compiled libraries into a directory at runtime. Use dynamic linking when you need to reduce the final binary size and are willing to accept runtime dependency management and path configuration. Use static linking with Cargo's default dev profile when you want fast iteration, reproducible builds, and zero runtime path configuration. Reach for cargo build --release only when you need optimization and link-time optimization, accepting the longer compile time.
The compiler will not magically skip work just because the output format changes. Cargo's hash-based cache and incremental pipeline do the heavy lifting. Measure your build times with --timings. Fix the actual bottlenecks. Leave the linker alone.