3 ms·

> Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys. That is a strange takeaway from my post. Of cour

> Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys. That is a strange takeaway from my post. Of course people care, but the difference is that one language and its toolchain was designed and built specifically to avoid these bugs and one wasn't. I have been writing C++ professionally since around 2000-2001, and have been working with Rust for about 18 months. For single threaded code, the code I write in both is about equivalent in terms of robustness and stability, but for anything multithreaded, I trust my Rust code's correctness substantially more, even with all the checkers and sanitizers enabled on my C++ codebase. Would I choose Rust for everything? Hell no, for evolutionary and fast moving code bases like in games, C++ is plenty good enough. For anything systems related that requires parallelism and robustness, I will 100% stick with Rust.

motorest 1y ago
[flagged]
- dafelst 1y ago
  It is entirely unclear to me what point you are trying to make. Is your mundane solution to just add more sanitization and analysis to C and C++? If so, that's great, more safety in any language is fantastic. My issue with that is that it is an optional addition to the language rather than the default behavior. The point I am making is that safe Rust _by default_ straight up disallows compiling code that has the potential for the vast majority of memory safety issues. Code with those issues is just a plain invalid program, and will not compile. If you want to bypass those protections, you need to explicitly opt-in with the unsafe keyword. C or C++ code with the same issues is perfectly valid, will compile and run, but it has the potential to be incorrect. You can (and should!) bolt on tools to fix that, but the issue is that the language allows that behavior by default. Until these tools are the defaults, the problem is only partially solved - you have to opt-in to a large chunk of safety features, and even if you do, you get fewer of them to boot. I'm not saying you should use Rust by any means. If you like C++, continue using it. But the fact here is that Rust solves a bunch of problems here and now today that C and C++ cannot, so it is baffling to me that people have such a visceral negative reaction to it.
  - motorest 1y ago
    [flagged]
- anextio 1y ago
  > mainstream compilers provide support to detect and throw warnings/errors for some of these issues You cannot detect all of these issues with static analysis. Rust does it by requiring the programmer to annotate lifetime dependencies in the source code. Without this additional semantic information, static analysis cannot fully reason about the lifetimes of variables. There are efforts by some to introduce lifetime annotations to C++ (https://news.ycombinator.com/item?id=30888172 https://news.ycombinator.com/item?id=30888172), but any changes to the core language face a very steep uphill battle with the C++ standards committee, so any movement on this is likely to be compiler-specific attribute-based systems, adopted largely by companies invested in a particular compiler ecosystem (such as Apple or Google) to annotate their proprietary code. On top of this, Rust is a very expressive language, with its features (like enum sum-types, traits etc) making it very easy to implement patterns such as compiler-checked state machines and polymorphism that doesn't involve the recognized downsides of class hierarchies. It is not for everyone, and not for every kind of project, but its features resonate positively with a lot of people in systems programming because of their experiences with other systems languages and their downsides. This is why Rust is popular today, particularly in certain communities.
  - motorest 1y ago
    [flagged]
- anextio 1y ago
  Replying to your other comment. > You are claiming that static code analysis tools extensively used in C++ cannot detect all conceivable and hypothetical memory issues. The weasel words in here is that it is possible to detect them, but some can conceivably slip through. No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem. > To drive the point home, there are already a few CVEs even from use-after-free bugs in Rust code. What does that make out of the all assertion? Would this be a reasonable argument to reject Rust as an unsafe language? The CVE that you referenced in the other comment was Rust calling into unsafe C code, as I pointed out. If you have a real example feel free to post it. > The problem with these claims is that they rely on weak strawmen arguments and a very superficial analysis of the problem space. I get the need to do marketing, but if the audience is technical them don't you think arguments should stand on solid technical ground? The views I have laid out here are the consensus among compiler engineers and in theoretical computer science. You only have to look at the compiler group at Apple: - heavily invested in static analysis - maintains the clang static analyzer - maintains number of runtime memory analysis tools in Xcode - not invested in rust at all and seemingly not interested Yet they are adding lifetime dependency annotations to Swift, making it more like Rust: https://github.com/swiftlang/swift-evolution/blob/ef71df4158f1cd9ded3a2adba946a96afe190b45/proposals/NNNN-lifetime-dependency.md https://github.com/swiftlang/swift-evolution/blob/ef71df4158... The reason for this is that static analysis simply cannot do it when the semantic information about lifetimes is lost, even for a group that knows how to write strong static analysis tools. Program flow is too ambiguous without it, so it becomes impossible to detect such memory vulnerabilities without running the program and fuzzing it – an expensive, time consuming, and probabilistic process.
  - motorest 1y ago
    > No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem. This is the sort of goalpost-moving that lays bare how superficial and misleading these accusations are. You're trying to argue that some very specific types of memory vulnerabilities can't be detected with static code analysis tools. That is different than claiming that it's not possible to detect memory vulnerabilities in languages such as C or C++, isn't it? But somehow this strawman is used to imply that Rust is invulnerable whereas developers using any other language are prevented from ever learning that standard FLOSS compilers support out of the box things such as detecting use of uninitialized variables. So what is it then?

motorest 1y ago

[flagged]

dafelst 1y ago
It is entirely unclear to me what point you are trying to make. Is your mundane solution to just add more sanitization and analysis to C and C++? If so, that's great, more safety in any language is fantastic. My issue with that is that it is an optional addition to the language rather than the default behavior. The point I am making is that safe Rust _by default_ straight up disallows compiling code that has the potential for the vast majority of memory safety issues. Code with those issues is just a plain invalid program, and will not compile. If you want to bypass those protections, you need to explicitly opt-in with the unsafe keyword. C or C++ code with the same issues is perfectly valid, will compile and run, but it has the potential to be incorrect. You can (and should!) bolt on tools to fix that, but the issue is that the language allows that behavior by default. Until these tools are the defaults, the problem is only partially solved - you have to opt-in to a large chunk of safety features, and even if you do, you get fewer of them to boot. I'm not saying you should use Rust by any means. If you like C++, continue using it. But the fact here is that Rust solves a bunch of problems here and now today that C and C++ cannot, so it is baffling to me that people have such a visceral negative reaction to it.
- motorest 1y ago
  [flagged]
anextio 1y ago
> mainstream compilers provide support to detect and throw warnings/errors for some of these issues You cannot detect all of these issues with static analysis. Rust does it by requiring the programmer to annotate lifetime dependencies in the source code. Without this additional semantic information, static analysis cannot fully reason about the lifetimes of variables. There are efforts by some to introduce lifetime annotations to C++ (https://news.ycombinator.com/item?id=30888172 https://news.ycombinator.com/item?id=30888172), but any changes to the core language face a very steep uphill battle with the C++ standards committee, so any movement on this is likely to be compiler-specific attribute-based systems, adopted largely by companies invested in a particular compiler ecosystem (such as Apple or Google) to annotate their proprietary code. On top of this, Rust is a very expressive language, with its features (like enum sum-types, traits etc) making it very easy to implement patterns such as compiler-checked state machines and polymorphism that doesn't involve the recognized downsides of class hierarchies. It is not for everyone, and not for every kind of project, but its features resonate positively with a lot of people in systems programming because of their experiences with other systems languages and their downsides. This is why Rust is popular today, particularly in certain communities.
- motorest 1y ago
  [flagged]
anextio 1y ago
Replying to your other comment. > You are claiming that static code analysis tools extensively used in C++ cannot detect all conceivable and hypothetical memory issues. The weasel words in here is that it is possible to detect them, but some can conceivably slip through. No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem. > To drive the point home, there are already a few CVEs even from use-after-free bugs in Rust code. What does that make out of the all assertion? Would this be a reasonable argument to reject Rust as an unsafe language? The CVE that you referenced in the other comment was Rust calling into unsafe C code, as I pointed out. If you have a real example feel free to post it. > The problem with these claims is that they rely on weak strawmen arguments and a very superficial analysis of the problem space. I get the need to do marketing, but if the audience is technical them don't you think arguments should stand on solid technical ground? The views I have laid out here are the consensus among compiler engineers and in theoretical computer science. You only have to look at the compiler group at Apple: - heavily invested in static analysis - maintains the clang static analyzer - maintains number of runtime memory analysis tools in Xcode - not invested in rust at all and seemingly not interested Yet they are adding lifetime dependency annotations to Swift, making it more like Rust: https://github.com/swiftlang/swift-evolution/blob/ef71df4158f1cd9ded3a2adba946a96afe190b45/proposals/NNNN-lifetime-dependency.md https://github.com/swiftlang/swift-evolution/blob/ef71df4158... The reason for this is that static analysis simply cannot do it when the semantic information about lifetimes is lost, even for a group that knows how to write strong static analysis tools. Program flow is too ambiguous without it, so it becomes impossible to detect such memory vulnerabilities without running the program and fuzzing it – an expensive, time consuming, and probabilistic process.
- motorest 1y ago
  > No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem. This is the sort of goalpost-moving that lays bare how superficial and misleading these accusations are. You're trying to argue that some very specific types of memory vulnerabilities can't be detected with static code analysis tools. That is different than claiming that it's not possible to detect memory vulnerabilities in languages such as C or C++, isn't it? But somehow this strawman is used to imply that Rust is invulnerable whereas developers using any other language are prevented from ever learning that standard FLOSS compilers support out of the box things such as detecting use of uninitialized variables. So what is it then?