7 ms·

My favorite thing about rust is that it has no magic "don't look behind the curtain and your programs will be safe" guard - instead, you define the guard yourse

My favorite thing about rust is that it has no magic "don't look behind the curtain and your programs will be safe" guard - instead, you define the guard yourself; it's just unnecessary for 99% of code, and within the 1% where you are defining your own curtain the borrow checker et al still try to uphold outside guarantees, making it difficult to shoot _anything_ besides the correct target with rust.

pjmlp 5y ago
You can still get it wrong, careful with the advocacy. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
- littlestymaar 5y ago
  You can still get it wrong, it's just way rarer. (95% of the CVEs listed here are simply “program can trigger UB”, which in the C or C++ land isn't worth a CVE in itself)
  - pjmlp 5y ago
    Rare is not never, hence why the advocacy message should be done in a better way.
- lijogdfljk 5y ago
  I'd be curious to see how many of those are actually safe code though, eh? I've written hundreds of thousands of lines of Rust. Can we estimate how much UB i've introduced?
- tialaramex 5y ago
  So let's take a closer look at the fairly recent CVE-2022-21658. Rust's standard library provides std::fs::remove_dir_all("/some/dir"), in C++ you will find the very similar std::filesystem::remove_all("/some/dir") As you might anticipate, these functions get rid of the directory /some/dir if necessary deleting sub-directories and files recursively in order to achieve that. They both explain that they won't delete other things, even if there's a symlink in /some/dir or some child that points to those outside things, the symlink gets deleted but not the thing it pointed to. What kind of terrible unsafety was discovered in CVE-2022-21658? Until Rust 1.58.1 you could exploit a TOCTOU race condition to blow away other people's stuff using symlinks when they made this call. And where is the CVE for the same bug in C++? There isn't one. C++ standards people argued that the C++ standard already actually says that none of their filesystem API is safe to use if you have a "concurrent environment" in which such races are possible. Standard C++ programs are only intended to run on a machine where they have exclusive control over the entire system for the entire length of their runtime and so when your C++ program deletes files you thought it couldn't delete that was actually your fault for not being familiar with every caveat and ruling in the entire C++ standard. What should you do about that? I believe the answer is obvious: Use Rust
  - ncmncm 5y ago
    It is a choice between (1) acknowledge it is an OS problem the library can't fix, or (2) pretend the library can fix it. C++ chose one; Rust, you say, chose the other. The Posix file API is shot through with races. Patching around them is a game of whack-a-mole. C++ cannot fix Posix. Rust cannot fix Posix. It is dishonest to assert that "C++ programs are only intended to run on a machine where they have exclusive control over the entire system". The system a program is a part of is expected to have enough control over what it operates on that its semantics are well defined. No Standard can do more. Rust can do no more. I doubt Rust pretends to more.
    - tialaramex 5y ago
      The C++ standard does not, in fact "acknowledge it is an OS problem the library can't fix" in respect of remove_all it plainly says this function doesn't remove files resolved to by symbolic links even though sometimes it does. The extent of its "acknowledgement" is that it says elsewhere in the standard that if there's any filesystem race you get Undefined Behaviour. C++ programmers can't do anything with this except, as I explained, insist on exclusive control over the system where their program runs during the entirety of its runtime to avoid this Undefined Behaviour.
      - ncmncm 5y ago
        C++ programmers rely on definitions from a wide variety of places, not limited to the ISO C++ Standard, and not even limited to Standards. Just writing "#include <unistd.h>" is Undefined Behavior as far as the ISO C++ and C Standards are concerned, but ISO Posix defines it. Linux, the BSDs, MSVC, iOS, Intel, AMD, ARM, and NVidia provide numerous additional definitions programmers rely on. A C++ program's behavior is defined by the aggregate of all of them as they apply to the runtime environment of the program. ISO Standards do not editorialize about things they do not define; they simply do not define them. For what the ISO C++ Standard does not define, you must look elsewhere if you want a definition. Often there is one, elsewhere. Every last jot and tittle of what a Rust program does is Undefined Behavior as far as every ISO Standard is concerned, but Rust coders rely on other definitions, too, including a specified binding to ISO Posix where relevant, and the various CPU and OS specs. It is generally advisable not to pontificate on things you do not understand to people who do.
- pcwalton 5y ago
  This is why it's more useful to talk about blame: http://blog.pnkfx.org/blog/2022/02/09/what-is-rusts-hole-purpose/ http://blog.pnkfx.org/blog/2022/02/09/what-is-rusts-hole-pur... Regarding memory safety, C++ says: "It's your fault if you get it wrong." Rust says: "It's our fault if we get it wrong in safe code." There is an enormous qualitative difference (in terms of ease of programming) and quantitative difference (in terms of number of bugs) between the two.
  - pjmlp 5y ago
    Sure, my point was that problems might still happen, and selling Rust as if they don't happen at all doesn't help for advocacy.
    - kaba0 5y ago
      I really don’t think people advocate for Rust as it being capable of producing only correct programs. But in the niche it occupies it is objectively gives much higher safety guarantees than the previous generation of languages, much much more so than C, and somewhat more than C++.
      - pjmlp 5y ago
        They do, I started this thread because of "...making it difficult to shoot _anything_ besides the correct target with rust.", irked me. Lets advocate Rust yes, but not as it is flawless.

pjmlp 5y ago

You can still get it wrong, careful with the advocacy. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

littlestymaar 5y ago
You can still get it wrong, it's just way rarer. (95% of the CVEs listed here are simply “program can trigger UB”, which in the C or C++ land isn't worth a CVE in itself)
- pjmlp 5y ago
  Rare is not never, hence why the advocacy message should be done in a better way.
lijogdfljk 5y ago
I'd be curious to see how many of those are actually safe code though, eh? I've written hundreds of thousands of lines of Rust. Can we estimate how much UB i've introduced?
tialaramex 5y ago
So let's take a closer look at the fairly recent CVE-2022-21658. Rust's standard library provides std::fs::remove_dir_all("/some/dir"), in C++ you will find the very similar std::filesystem::remove_all("/some/dir") As you might anticipate, these functions get rid of the directory /some/dir if necessary deleting sub-directories and files recursively in order to achieve that. They both explain that they won't delete other things, even if there's a symlink in /some/dir or some child that points to those outside things, the symlink gets deleted but not the thing it pointed to. What kind of terrible unsafety was discovered in CVE-2022-21658? Until Rust 1.58.1 you could exploit a TOCTOU race condition to blow away other people's stuff using symlinks when they made this call. And where is the CVE for the same bug in C++? There isn't one. C++ standards people argued that the C++ standard already actually says that none of their filesystem API is safe to use if you have a "concurrent environment" in which such races are possible. Standard C++ programs are only intended to run on a machine where they have exclusive control over the entire system for the entire length of their runtime and so when your C++ program deletes files you thought it couldn't delete that was actually your fault for not being familiar with every caveat and ruling in the entire C++ standard. What should you do about that? I believe the answer is obvious: Use Rust
- ncmncm 5y ago
  It is a choice between (1) acknowledge it is an OS problem the library can't fix, or (2) pretend the library can fix it. C++ chose one; Rust, you say, chose the other. The Posix file API is shot through with races. Patching around them is a game of whack-a-mole. C++ cannot fix Posix. Rust cannot fix Posix. It is dishonest to assert that "C++ programs are only intended to run on a machine where they have exclusive control over the entire system". The system a program is a part of is expected to have enough control over what it operates on that its semantics are well defined. No Standard can do more. Rust can do no more. I doubt Rust pretends to more.
  - tialaramex 5y ago
    The C++ standard does not, in fact "acknowledge it is an OS problem the library can't fix" in respect of remove_all it plainly says this function doesn't remove files resolved to by symbolic links even though sometimes it does. The extent of its "acknowledgement" is that it says elsewhere in the standard that if there's any filesystem race you get Undefined Behaviour. C++ programmers can't do anything with this except, as I explained, insist on exclusive control over the system where their program runs during the entirety of its runtime to avoid this Undefined Behaviour.
    - ncmncm 5y ago
      C++ programmers rely on definitions from a wide variety of places, not limited to the ISO C++ Standard, and not even limited to Standards. Just writing "#include <unistd.h>" is Undefined Behavior as far as the ISO C++ and C Standards are concerned, but ISO Posix defines it. Linux, the BSDs, MSVC, iOS, Intel, AMD, ARM, and NVidia provide numerous additional definitions programmers rely on. A C++ program's behavior is defined by the aggregate of all of them as they apply to the runtime environment of the program. ISO Standards do not editorialize about things they do not define; they simply do not define them. For what the ISO C++ Standard does not define, you must look elsewhere if you want a definition. Often there is one, elsewhere. Every last jot and tittle of what a Rust program does is Undefined Behavior as far as every ISO Standard is concerned, but Rust coders rely on other definitions, too, including a specified binding to ISO Posix where relevant, and the various CPU and OS specs. It is generally advisable not to pontificate on things you do not understand to people who do.
pcwalton 5y ago
This is why it's more useful to talk about blame: http://blog.pnkfx.org/blog/2022/02/09/what-is-rusts-hole-purpose/ http://blog.pnkfx.org/blog/2022/02/09/what-is-rusts-hole-pur... Regarding memory safety, C++ says: "It's your fault if you get it wrong." Rust says: "It's our fault if we get it wrong in safe code." There is an enormous qualitative difference (in terms of ease of programming) and quantitative difference (in terms of number of bugs) between the two.
- pjmlp 5y ago
  Sure, my point was that problems might still happen, and selling Rust as if they don't happen at all doesn't help for advocacy.
  - kaba0 5y ago
    I really don’t think people advocate for Rust as it being capable of producing only correct programs. But in the niche it occupies it is objectively gives much higher safety guarantees than the previous generation of languages, much much more so than C, and somewhat more than C++.
    - pjmlp 5y ago
      They do, I started this thread because of "...making it difficult to shoot _anything_ besides the correct target with rust.", irked me. Lets advocate Rust yes, but not as it is flawless.