Speeding up the Rust edit-build-run cycle

Original Article ↗ Hacker News Discussion ↗

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.