Most of the errors can already be caught by running `cargo check` which is substantially faster than rust.

Coming from C++ rust's compile times don't feel extraordinarily long.

When I write Rust code most of my errors typically get caught by my language server. Unfortunately, this doesn't help much with making builds faster, though it may reduce the number I may have to do.

Useless for graphics and GUI programming.

For GUI programming, you can use a toolkit that have a preview extension that updates in real time as you type. For example, Slint does that.

It doesn't do that for Rust code being called from UI.

Not nearly as much as chasing bugs that do not happen in Rust.

That would depend on what you're doing, of course :)

No not at all.

…perhaps you lack experience of a time where fixing bugs that cannot be effectively discovered using tools available in other languages took less time than the equivalent code in Rust would take to compile?

Yet all the tools that exist still don't prevent memory safety bugs found regularly in pretty much any C codebase. Using safe rust will be a productivity boon because of its type system, crate ecosystem and memory safety.

> Yet all the tools that exist still don't prevent memory safety bugs found regularly in pretty much any C codebase.

They can help, but I am well aware of which kinds of bugs existing C tooling cannot catch. I still take issue with your opinion, which hold through this thread, that claims that productivity gains from not having to track these down necessarily outweighs Rust's compile times.