I Improved My Rust Compile Times

Rust compile times & iteration speed

• Many agree Rust builds are still slow: even after a 75% improvement, 4–5s incremental on a powerful machine is seen by some as too high, especially for small static sites.
• Others consider 4–5s acceptable and emphasize the value of Rust’s strong compile-time guarantees versus fast-but-error-prone hot module reload (HMR) in JS/TS.
• Some report projects taking minutes to compile on modest hardware, worrying that Rust effectively requires expensive machines and may hinder adoption.
• Several posters stress that short edit–run cycles (1–2s) strongly affect productivity; others argue that in Rust the primary loop is “edit, wait for rust-analyzer,” reducing reliance on full builds—though rust-analyzer is reported as slow on larger repos.

Hardware: CPU vs RAM vs storage

• Benchmarks shared in the thread indicate compile time scales with core count; extra RAM beyond ~1 GB per build doesn’t help typical crates, though memory speed might.
• High-RAM machines (64–128 GB) are considered overkill for Rust specifically but useful for VMs, sanitizers, and local LLMs.
• Experiences with RAM pressure differ: some Linux users hit OOM/hard reboots with 32 GB, others say Linux memory usage is efficient if configured (swap, zram etc.). Causes are disputed/unclear.
• Laptop RAM pricing is contentious; soldered RAM and premium brands make 32 GB costly, but upgradable or non-premium laptops can be cheaper.

Tooling: linkers, caches, backends

• Discussion of mold/sold: sold is essentially mold under a commercial license; mold is now permissively licensed but still lacks macOS support. Apple’s new parallelized linker is reportedly fast enough that sold is mostly obsolete.
• Cranelift as an alternative backend can speed builds (anecdotal claims of 20–30% gains), but some see this as modest relative to overall slowness.
• Suggestions include using sccache and firebuild; firebuild can cache linking and build scripts and claims >90% speedups in some Rust builds (Mac support is experimental).
• cargo-leptos’s separate-front-target-dir setting is now always enabled and deprecated as a user option.

Language and compiler design tradeoffs

• Multiple comments note that the borrow checker contributes little to compile time; the main culprits are monomorphization and macro expansion, which produce large LLVM workloads but yield fast runtime code.
• Rust’s compilation unit is a crate (allowing intra-crate circular deps), limiting parallelism compared to C/C++, where each source file is a unit.
• Some argue Rust front-loads effort (strict types, ownership) to reduce runtime debugging; others counter that over-investing in types before seeing behavior can waste time and that rapid runtime iteration remains crucial.
• Observers note years of steady but incremental compiler-speed work; profiles are now “flat,” implying most low-hanging fruit is gone, and big further gains may require deep architectural changes.

Front-end workflow and templates

• Front-end developers debate whether Rust fits rapid UI iteration: long rebuilds are seen as unacceptable for quick CSS/markup tweaks.
• Others counter that Rust’s safety is “worth the wait,” especially compared to legacy JS where many errors only surface at runtime.
• One commenter questions why HTML template edits trigger full Rust rebuilds, suggesting using external templates or a design that doesn’t require recompilation; details of the article’s setup are unclear.

Other discussion points

• Some wish the article had covered sccache explicitly.
• There’s curiosity about CPU benchmarks specifically for compiling Rust; phoronix/openbenchmarking are mentioned as relevant sources.
• AI-generated hero images on blogs are widely criticized as distracting and often undisclosed; several admit they stopped to inspect artifacts instead of reading.