I Improved My Rust Compile Times

Original Article ↗ Hacker News Discussion ↗

Efforts to speed up Rust compile times—such as using faster linkers like mold, alternative backends like Cranelift, and build caches—highlight both real gains and persistent pain points, especially for larger projects. Commenters note that CPU speed matters far more than large amounts of RAM, and that while incremental compilation has improved, multi‑second to multi‑minute rebuilds still hinder iteration compared with web tooling and JIT-based languages. Many see Rust’s strict type system and safety guarantees as worth the upfront compilation cost, but there is ongoing concern that long build times and heavy hardware requirements may limit adoption, particularly outside well-resourced environments.

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.