> Once your code compiles, you’ll find (at least I have) that it is much more likely to be correct (i.e., do the right thing) than if you tried to write similar C, C++, or Go code.
What issues in Go do this sentence refer to?
What issues in Go do this sentence refer to?
Guess you would normally run your tests with it, and maybe compile a dev / beta / RC version with race detection enabled?
Never used it in prod, but it did find a problem for me.
But obviously for any other language (C,Go,etc) you can use a compiler + static analysis + dynamic analysis to have the same confidence.
What I like with Rust is that implicitly you know that every one has to run the equivalent of analysis tool to release/deploy the code.
Not quite. There's certain types of issue which its type system won't detect - you can, in fact, easily get into a race condition, just not what's known as a data race - and there's no promise that what you've written actually does what you expect it to do, just that it'll do something without use-after-free and other memory-related bugs, and if you've written your program well it's more likely than e.g. Python that it does what you intended (in my personal experience).
Getting closer to "if it compiles, it works", but still not entirely there, there'd be the likes of Idris and other systems with proofs embedded into their type systems - but even then you still have to verify that the proof matches what you're actually trying to do in the real world.
Sometimes it's used too much by people coming from other language, deploying those patterns to Go