▲ | lmm 9 hours ago | |||||||
> There’s a reason you should still be writing unit tests and hypothesis/property tests in Rust, to catch issues the compiler can’t catch at runtime which is a huge surface area. It would be irresponsible to suggest that Rust eliminates a large enough proportion of common errors that you can YOLO anything that compiles and achieve an acceptable defect rate... but it does happen to be true in my experience. | ||||||||
▲ | dlahoda 8 hours ago | parent [-] | |||||||
yes. tests test what? logic. logic = types (proven). so stronger type system less test needs to be written. more, if proc macro or build.rs can execute logic, based on parsed """types"""(partial info only), we can extend type systems with custom logic (and panic at compile time and/or startup time if usage violation detected). on top of that, add fail fast (fail at compile time, build time or start up time) and newtype and errors-part-of-api culture; and lack of late binding (dyn is very limited use, no runtime reflection), and we get even less reasons to write tests. some examples of industrial """typing"""(eDSLs, construction time) solutions in rust : - https://github.com/elastio/bon - https://github.com/contextgeneric/cgp - https://github.com/paritytech/orchestra - https://git.pipapo.org/cehteh/linear_type.git sure we need write tests, and tests like antithesis helps with. but list of tools helping with tests exactly as antithesis does(and more of others) is huge. that is built on top of absolutely strong supply chain audit, quality and security. there is even """levels""" of determinism tooling to decide how much to pay for cloud compute. | ||||||||
|