←back to thread

Unexpected productivity boost of Rust

(lubeno.dev)
517 points bkolobara | 2 comments | 27 Aug 25 15:48 UTC | HN request time: 0s | source
Show context
amai ◴[28 Aug 25 08:46 UTC] No.45049911[source]▶
"I have found that Rust's strong safety guarantees give me much more confidence when touching the codebase. With that extra confidence I'm much more willing to refactor even critical parts of the app, which has a very positive effect on my productivity, and long-term maintainability."

That is usually why you have tests for your code. But if you have no tests a programming language with a strict compiler is of course more helpful. But the best is to write tests. Then you can also refactor code with confidence written in "sloppy" programming languages.

replies(4): >>45049998 #>>45050001 #>>45050061 #>>45051630 #
IshKebab ◴[28 Aug 25 09:02 UTC] No.45050001[source]▶
Nope, it's better for properties to be statically proven by the compiler where possible, rather than tested with runtime tests.

Tests should be used where you can't prove correctness statically. But it's better if you can.

The ultimate end point of this is formal verification, where you need very few - if any - runtime tests. But formally verifying software is extremely difficult, so you can't usually do that.

replies(1): >>45050101 #
1. pjmlp ◴[28 Aug 25 09:17 UTC] No.45050101[source]▶
Even formal verification requires tests though, because there may be bugs on the logic proofs.
replies(1): >>45050678 #
2. IshKebab ◴[28 Aug 25 10:59 UTC] No.45050678[source]▶
True. Well usually. In some cases the property you're writing is so simple you wouldn't need any tests, for example in a compression library you just check decompress(compress(x)) == x. If that is proven there's no need for tests.

But yeah usually it's a good idea to have a few tests anyway. You just need fewer tests the more properties you can prove formally.