6 ms·
> 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
by namelezz 10y ago
> 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?
- seren 10y agoI don't think that Go can detect race condition errors at compile time. So it could compile and sometimes fails mysteriously. In Rust, as long as you don't use unsafe block, the compiler should detect it. This is not really a Go issue, rather that Rust is much more stringent on what it "correct" code compared to C, C++ and Go.
- gizzlon 10y agoI think you're right. Go has a race detector, but it work on run time: https://golang.org/doc/articles/race_detector.html https://golang.org/doc/articles/race_detector.html 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.
- seren 10y agoI believe this is one of the main promise of Rust, even if it is not stated like that, if it compiles it works and it is safe. 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.
- vertex-four 10y ago> I believe this is one of the main promise of Rust, even if it is not stated like that, if it compiles it works and it is safe. 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.
- seren 10y agoI agree that "it works" is an overstatement. It is more akin to if it compiles it won't segfault. (Arguably this is not unique to Rust, but there is no overhead in runtime to achieve that).
- oconnor663 10y agoApart from actual race conditions, there are a lot of tricky ownership situations that Rust's model helps with. When you have lots of different objects referring to one another, it's easy for one of them to make a mutation that the others don't expect. Even if all this is happening on one thread, and it isn't strictly speaking a race condition, it can cause confusing bugs. Languages like Python and JS tend to address this by making some objects immutable. Rust addresses this by being very explicit about ownership, and by forcing you to use RefCell etc. in cases where shared objects can be mutated. If you have a shared reference to regular data, you know it can't be mutated out from under you in safe code.
- legulere 10y agoI'm not a Go programmer, but I guess forgetting to check if a pointer is nil is one example.
- dbalan 10y agoRuntime errors are easy to happen in Go, main culprit being the typesystem. If you are writing some non trivial abstractions (e.g db calls), you'll almost always end up with passing interface{} types, which destroys the compile time type safety.
- gizzlon 10y agoYeah, passing interface{} is for special occasions only and should be avoided if possible. Sometimes it's used too much by people coming from other language, deploying those patterns to Go