Speeding up the Rust edit-build-run cycle

Original Article ↗ Hacker News Discussion ↗

Efforts to speed up Rust’s edit–build–run cycle highlight trade‑offs between build performance, debuggability, and tooling choices. Commenters debate stripping debug symbols and relying on `println!` logging versus using full-featured debuggers, with opinions shaped by language ecosystems, project size, and constraints such as embedded or WASM targets. The thread also touches on linker options like mold and split debug info, and briefly veers into Unix home-directory hygiene and XDG conventions triggered by Cargo’s default paths.

Debug info, debuggers, and build speed

  • Major contention around disabling debug info to speed up Rust’s edit-build-run loop.
  • One camp argues debug symbols are essential: debuggers are more powerful and often faster than iterating with println; stripping debug info for dev builds is seen as pointless or harmful.
  • Others accept disabling debuginfo in fast-iteration builds, enabling it only when they actually need a debugger. They emphasize that many developers rely mostly on println/logging, making full debug info a cost with little benefit.
  • Several point out that compile time vs. debugging style is highly workflow-dependent (language, project size, startup cost, IDE integration).

Printf/logging vs. interactive debugging

  • There’s an extended “printf vs debugger” divide:
    • Pro-debugger side: step-debugging, breakpoints, state inspection, time-travel tools, and IDE integration (especially in Java/IntelliJ, Visual Studio, CLion) are described as massive productivity boosts.
    • Pro-printf side: logging is universal, works across languages and environments, survives timing-sensitive and distributed setups, and can better show the evolution of state over time; many say they use debuggers only rarely.
  • Some say logs are best for application-level flows, debuggers for low-level or tricky issues. Others emphasize that thinking about the bug is more important than the tool used.
  • Concurrency, async code, real-time constraints, and distributed systems often make interactive debugging harder or distort behavior; for these, logging or custom tracing is preferred.

Embedded and WASM constraints

  • Embedded developers describe debuggers as unreliable, expensive, or disruptive to timing and power behavior; logging, ring buffers, or serial interpreters are favored.
  • For WASM targets, incremental debugging via debugger is often not an option; rebuilds with added prints are still required.

Rust-specific notes

  • Rust’s runtime overflow checks differ between debug and release; compile-time checks are always on.
  • Some report rarely needing debuggers in safe Rust, relying on panics with backtraces and logging; unsafe code or library issues are the main debugger use cases.
  • Split debug info (split-debuginfo = "unpacked" / -gsplit-dwarf) is proposed as a compromise to keep debuggability while reducing link times.

Tooling and ecosystem points

  • Mixed feedback on alternative linkers like mold/sold; one user saw no measurable gain on macOS.
  • A side thread criticizes tools like Cargo for cluttering $HOME with dot-directories instead of using XDG base directories; others defend simple dotfiles or dislike XDG’s complexity.
  • Some curiosity about ongoing work on the “wild” toolchain, with links to its repository and blog posts.