3 ms·

What if you normalize for the amount of code in the wild? Relatively little software I use day to day have significant amounts of rust in them (only Firefox an

by cozzyd 3y ago

What if you normalize for the amount of code in the wild? Relatively little software I use day to day have significant amounts of rust in them (only Firefox and my phone OS, probably...). Even in firefox, there is far more C++ than rust...

steveklabnik 3y ago
You’d also have to define what “use” means. Your traffic that goes through Cloudflare hits Rust code: does that count as a “use”? Sites you use that rely on AWS almost certainly hits Rust code, does that count as a “use”? I think it’s kind of stretching it, but these are services where issues in them could impact you, so I don’t think it’s a total non sequitur.
- cozzyd 3y ago
  that's totally fair, certainly there are web servers I use that are probably using rust somewhere, but I suspect it's still a relatively small amount of code (even if widely used!).
- fch42 3y ago
  This is true - and also misses one of the points Herb Sutter's article is making. I don't disagree at all with what seems the general sentiment here about the importance of memory safety. I also, though, don't disagree with Herb Sutter that there are other safety-relevant aspects in both programming and software deployment which aren't helped/prevented "merely" by using memsafe languages. Say, the "typical" rust laziness ... just unwrap() because well we know for sure it can't possibly be None, right ? Do that in a form of crit code path, and while that may not open you to an exploit, it'll still down your service and damn you to a crashloop. Yes, we should be using memsafe languages. Yes, we should be a little humble about bugs we may create. As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain.
  - steveklabnik 3y ago
    > As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain. Sure. Nobody believes that memory safety is the sole security issue. Or at least, no serious people, or any of the organizations doing advocacy around this issue.
    - vlovich123 3y ago
      And just to be clear, in C++ a "bad unwrap" could become an exploitable gadget in arbitrary code execution or bypassing security checks or literally any really serious issue. Also, the same issue would show up as any one of N failures and may even be missed. In Rust it would manifest as a DOS attack vector and the issue would be blamed to the bad unwrap 100% of the time. So the C++ case the possible failure modes are arbitrarily serious vulnerability with poor observability and difficulty finding it. In Rust that failure mode is a mild generally non-exploitable vulnerability* that 100% of the time fails in the exact same way making monitoring & detection trivial. * Yes, it could be a single stage of an exploit where you take down 1 service which opens up another vulnerability. But that's still a more expensive exploit (in terms of $ to discover) than if you had this problem in C++.
  - keybored 3y ago
    > Say, the "typical" rust laziness ... just unwrap() because well we know for sure it can't possibly be None, right ? Which is safe. > Do that in a form of crit code path, and while that may not open you to an exploit, Oh, so you realize that it is safe. > it'll still down your service and damn you to a crashloop. So there isn’t an argument here. Next.
    - vlovich123 3y ago
      A DOS attack is still a security vulnerability, but as I describe above it's still a better failure mode than you get with C++.
    - fch42 3y ago
      "memory-safe" != "safe". Make a fair assessment what it means to your app / service when you have a, however controlled/contained, reproducible unexpected (by the developer) exit. Or what it means to use a hardcoded default (unwrap_or). Or what it means to pass up an Err via "?". Or to map an Err to None. My argument is simple: The memory safety of rust is no reason to become arrogant as a programmer. It should, in fact, maybe make you more humble - what you learned about your own typical mistakes as you learned to write rust and tackle the borrow checker and decode clippy's extensive litany of sins in your source. And to consider that rust, as prime example, exists because people learned - from mistakes. From those design flaws in C/C++, namely. Assume you make mistakes as well is likely to turn you into a better person. Definitely into a better programmer. No matter which language you use. Hopefully rust (on that I fully agree)

by cozzyd 3y ago

steveklabnik 3y ago

You’d also have to define what “use” means. Your traffic that goes through Cloudflare hits Rust code: does that count as a “use”? Sites you use that rely on AWS almost certainly hits Rust code, does that count as a “use”? I think it’s kind of stretching it, but these are services where issues in them could impact you, so I don’t think it’s a total non sequitur.

cozzyd 3y ago
that's totally fair, certainly there are web servers I use that are probably using rust somewhere, but I suspect it's still a relatively small amount of code (even if widely used!).
fch42 3y ago
This is true - and also misses one of the points Herb Sutter's article is making. I don't disagree at all with what seems the general sentiment here about the importance of memory safety. I also, though, don't disagree with Herb Sutter that there are other safety-relevant aspects in both programming and software deployment which aren't helped/prevented "merely" by using memsafe languages. Say, the "typical" rust laziness ... just unwrap() because well we know for sure it can't possibly be None, right ? Do that in a form of crit code path, and while that may not open you to an exploit, it'll still down your service and damn you to a crashloop. Yes, we should be using memsafe languages. Yes, we should be a little humble about bugs we may create. As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain.
- steveklabnik 3y ago
  > As important as it is to entirely eliminate one "critical" class, as important it is to realize even with that gone, bugs/issues/security problems will remain. Sure. Nobody believes that memory safety is the sole security issue. Or at least, no serious people, or any of the organizations doing advocacy around this issue.
  - vlovich123 3y ago
    And just to be clear, in C++ a "bad unwrap" could become an exploitable gadget in arbitrary code execution or bypassing security checks or literally any really serious issue. Also, the same issue would show up as any one of N failures and may even be missed. In Rust it would manifest as a DOS attack vector and the issue would be blamed to the bad unwrap 100% of the time. So the C++ case the possible failure modes are arbitrarily serious vulnerability with poor observability and difficulty finding it. In Rust that failure mode is a mild generally non-exploitable vulnerability* that 100% of the time fails in the exact same way making monitoring & detection trivial. * Yes, it could be a single stage of an exploit where you take down 1 service which opens up another vulnerability. But that's still a more expensive exploit (in terms of $ to discover) than if you had this problem in C++.
- keybored 3y ago
  > Say, the "typical" rust laziness ... just unwrap() because well we know for sure it can't possibly be None, right ? Which is safe. > Do that in a form of crit code path, and while that may not open you to an exploit, Oh, so you realize that it is safe. > it'll still down your service and damn you to a crashloop. So there isn’t an argument here. Next.
  - vlovich123 3y ago
    A DOS attack is still a security vulnerability, but as I describe above it's still a better failure mode than you get with C++.
  - fch42 3y ago
    "memory-safe" != "safe". Make a fair assessment what it means to your app / service when you have a, however controlled/contained, reproducible unexpected (by the developer) exit. Or what it means to use a hardcoded default (unwrap_or). Or what it means to pass up an Err via "?". Or to map an Err to None. My argument is simple: The memory safety of rust is no reason to become arrogant as a programmer. It should, in fact, maybe make you more humble - what you learned about your own typical mistakes as you learned to write rust and tackle the borrow checker and decode clippy's extensive litany of sins in your source. And to consider that rust, as prime example, exists because people learned - from mistakes. From those design flaws in C/C++, namely. Assume you make mistakes as well is likely to turn you into a better person. Definitely into a better programmer. No matter which language you use. Hopefully rust (on that I fully agree)