4 ms·

In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable

In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code). In addition, you can't overflow a buffer nor unintentionally read outside the bounds of an array, that will cause a runtime panic and abort the program. Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm. Even the most novice Rust programmer who stays in the guardrails will produce programs free of these sorts of memory safety bugs. The same cannot be said about C or C++ programs.

motorest 1y ago
> In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code). Aren't most of these issues caught in C++ code by static code analysis tools, and even just flipping switches on C++ compilers? I mean, check out tools like cppcheck and address sanitizer. They exist for ages. Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.
- scott_w 1y ago
  > Even the most novice Rust programmer who stays in the guardrails I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. I’ve no experience with either language and I can safely say I’d have no idea which switches to “just flip” in the compiler and what tools I should look up to write safe C++ code. I do know that “Learn Language X” books do not include this information so as to not overwhelm the novice.
  - motorest 1y ago
    > I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. That blend of comments is at best grasping at straws. How long do you think a developer stays a "novice"? Does Rust have any problem that prevents developers from learning and improving their skills as fast as any other developers do? Are all Rust projects maintained by novice and junior devs where no one at all can claim to have any senior level skills? If that's the best argument, that's not an argument at all.
    - timeon 1y ago
      So why all the software is still so insecure?
      - motorest 1y ago
        [flagged]
    - scott_w 1y ago
      > Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm. Look, I’m not the one making these arguments, I’m just pointing out that all your objections seem to have been answered already. If you have a counter argument that shows Rust, as practiced, is no safer than C++, then I’d like to see it.
- dafelst 1y ago
  > 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.
- rcxdude 1y ago
  No, they aren't. C++ codebases, even those who make quite a big effort to use as many analysers and checkers and sanitizers as they can, are still plagued by memory safety issues. Rust has a measurably lower incidence of security bugs due to this (not zero, but lower). People have tried (and are still trying) to retrofit memory safety onto C++ and they have not in general been successful. There's too many sharp edges built into the current language and library design, and these tools cannot catch all the ways in which you can mess up. (What's more, Rust is substantially nicer to use than C++. The language, package manager, and compiler are all so much more straightforward than C++ that I would use it for that alone)

motorest 1y ago

> In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside the use of unsafe code). Aren't most of these issues caught in C++ code by static code analysis tools, and even just flipping switches on C++ compilers? I mean, check out tools like cppcheck and address sanitizer. They exist for ages. Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys.

scott_w 1y ago
> Even the most novice Rust programmer who stays in the guardrails I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. I’ve no experience with either language and I can safely say I’d have no idea which switches to “just flip” in the compiler and what tools I should look up to write safe C++ code. I do know that “Learn Language X” books do not include this information so as to not overwhelm the novice.
- motorest 1y ago
  > I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. That blend of comments is at best grasping at straws. How long do you think a developer stays a "novice"? Does Rust have any problem that prevents developers from learning and improving their skills as fast as any other developers do? Are all Rust projects maintained by novice and junior devs where no one at all can claim to have any senior level skills? If that's the best argument, that's not an argument at all.
  - timeon 1y ago
    So why all the software is still so insecure?
    - motorest 1y ago
      [flagged]
  - scott_w 1y ago
    > Doing this in C or C++ is possible, but the fact that even the best of the best programmers in these languages sometimes still make these mistakes shows the limitations of the paradigm. Look, I’m not the one making these arguments, I’m just pointing out that all your objections seem to have been answered already. If you have a counter argument that shows Rust, as practiced, is no safer than C++, then I’d like to see it.
dafelst 1y ago
> 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.
rcxdude 1y ago
No, they aren't. C++ codebases, even those who make quite a big effort to use as many analysers and checkers and sanitizers as they can, are still plagued by memory safety issues. Rust has a measurably lower incidence of security bugs due to this (not zero, but lower). People have tried (and are still trying) to retrofit memory safety onto C++ and they have not in general been successful. There's too many sharp edges built into the current language and library design, and these tools cannot catch all the ways in which you can mess up. (What's more, Rust is substantially nicer to use than C++. The language, package manager, and compiler are all so much more straightforward than C++ that I would use it for that alone)