Rust compiler performance

Cargo disk usage & cache management

• Several comments focus on target/ bloat and cache growth (especially with many serde-using projects); some find this bad enough to avoid Rust.
• Upcoming Cargo automatic GC (1.88) cleans global caches (e.g. .crate downloads) by default but not build artifacts yet; further work is planned to reorganize target/ and eventually support shared intermediate artifacts.
• There’s active design for a global artifact cache keyed by crate instances, but complicated by build scripts, proc-macros, versioning, and avoiding cache poisoning.

LLVM, backends, and JIT-style workflows

• Many note LLVM optimizations dominate compile time in heavy projects; Feldera’s blog is cited where LLVM becomes the main bottleneck and is hard to parallelize given current rustc structure.
• There’s interest in JIT or faster backends for dev builds. Cranelift is highlighted as a Rust backend originally built for JIT; it can cut large debug builds dramatically but isn’t suitable for peak runtime performance yet.
• Targeting the JVM is seen as a poor fit because Rust’s low-level memory model clashes with the JVM object model.

Comparisons with C++, Go, Zig, others

• C++ veterans are divided: some say Rust times are acceptable or better than large C++ builds; others report “small” Rust projects compiling much slower than huge C++ codebases and vastly slower than comparable Go projects.
• Go is repeatedly cited as an existence proof that compilation speed can be a primary design goal; some argue Rust consciously traded that for a richer type system and zero-cost abstractions.
• Zig is used as a counterexample where compiler architecture and Data-Oriented Design are aggressively optimized for fast dev loops; some think Rust underestimates this payoff.

Language design vs compiler architecture

• Debate over whether Rust’s design “locks in” slow compiles:
  • One camp: fundamental choices (monomorphized generics, heavy zero-cost abstractions, proc macros, rich diagnostics) inherently generate lots of IR and work for the backend.
  • Others: parsing, lexing, and borrow checking are minor costs; big wins remain possible via compiler rearchitecture, better front-end optimizations, and parallelizing LLVM workloads without changing the language.
• Examples of problematic features for compile time: item definitions inside functions, current proc-macro model (token streams, double parsing), limited polymorphization; but many of these are seen as fixable with careful evolution.

Dependencies, ABI, and binary distribution

• Recompiling the same crates across projects is widely disliked. Suggestions range from global compiled-cached crates to PyPI-like binary distribution.
• Objections center on: lack of stable ABI, huge feature combinations, security/review of binaries, and Rust’s “pay only for what you use” philosophy.
• Some propose system-wide caches or “opaque dependencies” (prebuilt libs akin to C shared libraries), or relying on tools like sccache, Bazel, or remote build caches instead.

Tooling, hot reload, and workflows

• Many rely on cargo check and incremental compilation for fast feedback; others report needing frequent cargo clean, which makes full rebuilds painful.
• Alternative workflows: hot reload frameworks (Dioxus, some game engines), separate GUI layers (QML, Dioxus) to avoid recompiling Rust for UI tweaks, and external build systems (Bazel, distributed caching, fast linkers like mold/lld).
• Some argue interpreters, REPLs, or JIT-like dev modes (as in Dart/Flutter, Smalltalk, Lisp, Haskell/OCaml bytecode) could offset slow optimized compilers.

Rust’s priorities, governance, and future

• Multiple comments say Rust “cares” about compiler performance but not as a top-tier goal; security, correctness, diagnostics, and runtime performance often win trade-offs.
• Open-source “show-up-ocracy” is cited: large architectural compile-time improvements are hard, unglamorous, and conflict with continual evolution, so they progress slowly unless funders prioritize them.
• Concern exists that ecosystem growth (more crates, features, dependencies) outpaces compiler gains, making perception worse over time, but others note ongoing big-ticket ideas (parallel front end, better incremental, new backends) and deny that Rust has hit an unfixable “bedrock.”