4 ms·

Seeing 5 for Rust and 3 for Go in the Stability section is weird for me as an experienced Go developer. While null pointers and such to happen, most of them ar

Seeing 5 for Rust and 3 for Go in the Stability section is weird for me as an experienced Go developer. While null pointers and such to happen, most of them are caught in the QA phase. Most of the bugs I've encountered in production were either resource misuse bugs (some of which Rust could catch) or business logic / architecture bugs (which no programming language can ever solve). Also, I'm not sure if Rust has the same amount of tooling to diagnose these issues as Go, such as the built-in online profiler. But if it does, please correct me. Dev time getting a 3/5 in Go is also quite weird, considering both that Go is a simpler language as well as the fact that it compiles quickly, so whenever you have an issue changing the code to get more info and recompiling is literally a matter of seconds. Besides, most of my dev time isn't really spent in debugging; it's in the architecture. In making things be readable and work well together. And I'm not even sure what they mean by “Memory Safety”. Access outside of a slice's boundaries causes a runtime panic, not a memory corruption or a segfault as in C++.

ekidd 5y ago
> Seeing 5 for Rust and 3 for Go in the Stability section is weird for me as an experienced Go developer. While null pointers and such to happen, most of them are caught in the QA phase. As someone who writes a lot of production Rust code, I also find some of the ratings a bit surprising. Go is usually pretty stable in production, certainly better than 3/5. But at the same time, I am so over catching null-reference crashes in the "QA Phase." Subjectively, it just feels like shoddy craftwork, the equivalent of making wooden cabinets with doors that don't quite close correctly. We can do better than this, and we should. I have needed to debug major Go packages in production, including Hashicorp products and Pachyderm. And null-reference issues do come up, along with similar sloppiness about data types and invalid states. It's not super-common, but it does happen, and it's a lousy way to spend a weekend emergency. I'm really hoping that Go continues to evolve in this area. There's a lot that I like about Go, and there's some terrific software written in Go. > And I'm not even sure what they mean by “Memory Safety”. Access outside of a slice's boundaries causes a runtime panic, not a memory corruption or a segfault as in C++. I've spent some time fuzzing Rust code using the excellent 'cargo fuzz'. And this made me feel like Rust provides 3 major kinds of memory safety: 1. Bounds checks! This is ancient technology shared by many languages, and it's far less 'cool' than the borrow checker. Nonetheless, it seems to be the single biggest thing that turns serious attacks into controlled shutdowns. 2. Borrow-checking stuff: Use-after-free, etc. GCed languages all have solid solutions for this. Rust's only advantage here is that it provides similar safety without GC overhead (and the poor tail latency and memory usage of many GCed languages). 3. Easier concurrency. This is the one that's easiest to forget. Many GCed languages allow shared data structures to be mutated freely by multiple threads, even when doing so will corrupt data. This usually can't be turned into C-style code injection attacks, but it can cause major headaches. The only real safety advantage Rust has over GCed languages here is (3). Whether or not this matters depends on exactly how a given program uses threads.
- ainar-g 5y ago
  I agree, especially with nulls being annoying and with Rust having better protection from concurrency bugs. Re. cargo fuzz, Go is getting first-class fuzzing in Go 1.18, which should be out in just a few days, and I'm very excited about all the new null pointer dereferences it finds in my code, heh.

ekidd 5y ago

> Seeing 5 for Rust and 3 for Go in the Stability section is weird for me as an experienced Go developer. While null pointers and such to happen, most of them are caught in the QA phase. As someone who writes a lot of production Rust code, I also find some of the ratings a bit surprising. Go is usually pretty stable in production, certainly better than 3/5. But at the same time, I am so over catching null-reference crashes in the "QA Phase." Subjectively, it just feels like shoddy craftwork, the equivalent of making wooden cabinets with doors that don't quite close correctly. We can do better than this, and we should. I have needed to debug major Go packages in production, including Hashicorp products and Pachyderm. And null-reference issues do come up, along with similar sloppiness about data types and invalid states. It's not super-common, but it does happen, and it's a lousy way to spend a weekend emergency. I'm really hoping that Go continues to evolve in this area. There's a lot that I like about Go, and there's some terrific software written in Go. > And I'm not even sure what they mean by “Memory Safety”. Access outside of a slice's boundaries causes a runtime panic, not a memory corruption or a segfault as in C++. I've spent some time fuzzing Rust code using the excellent 'cargo fuzz'. And this made me feel like Rust provides 3 major kinds of memory safety: 1. Bounds checks! This is ancient technology shared by many languages, and it's far less 'cool' than the borrow checker. Nonetheless, it seems to be the single biggest thing that turns serious attacks into controlled shutdowns. 2. Borrow-checking stuff: Use-after-free, etc. GCed languages all have solid solutions for this. Rust's only advantage here is that it provides similar safety without GC overhead (and the poor tail latency and memory usage of many GCed languages). 3. Easier concurrency. This is the one that's easiest to forget. Many GCed languages allow shared data structures to be mutated freely by multiple threads, even when doing so will corrupt data. This usually can't be turned into C-style code injection attacks, but it can cause major headaches. The only real safety advantage Rust has over GCed languages here is (3). Whether or not this matters depends on exactly how a given program uses threads.

ainar-g 5y ago
I agree, especially with nulls being annoying and with Rust having better protection from concurrency bugs. Re. cargo fuzz, Go is getting first-class fuzzing in Go 1.18, which should be out in just a few days, and I'm very excited about all the new null pointer dereferences it finds in my code, heh.