5 ms·

I don't think it's ridiculous. It seems like almost every discussion about Rust vs C++ here has a few people saying that you don't need Rust's guarantees about

by eridius 10y ago

I don't think it's ridiculous. It seems like almost every discussion about Rust vs C++ here has a few people saying that you don't need Rust's guarantees about memory safety if you're writing modern C++. And that oft-repeated comment is what pcwalton is referencing.

blub 10y ago
pcwalton is not framing the problem in a particularly useful way. This is a question of risk management and his argument is basically that one should always reduce the risk of memory management errors to zero. Others say that they can tolerate some risk, as long as it's in acceptable margins, since it's expensive to totally eliminate it. I don't think that lecturing everyone "No, you really want to have 0 risk, you fools" is a successful programming language advocacy strategy.
- pcwalton 10y ago
  > This is a question of risk management and his argument is basically that one should always reduce the risk of memory management errors to zero. No, that's not my argument. > Others say that they can tolerate some risk, as long as it's in acceptable margins, since it's expensive to totally eliminate it. These flaws are not "in acceptable margins". They were numerous and were found the instant Dmitry Vyukov turned a fuzzer on the library. And it's not expensive to totally eliminate memory safety bugs. Just code in a memory-safe language. That's what most people already do.
  - blub 10y ago
    I wasn't talking about a specific example or these particular flaws, but in general, because this is just an instance of your generic argument that modern C++ is unsafe, where "unsafe" means not verifiably memory-safe. That's correct, but you are framing the problem in an unrealistic way in which Rust wins by default. In reality, this type of memory-safety guarantees will be evaluated against other concerns and those other concerns might be more important. For you memory-safety errors are unacceptable, that much is clear. For many they are more or less acceptable and insisting that they're unacceptable won't make them change their minds.
- deleted 10y ago
  [deleted]
- moosingin3space 10y ago
  Memory-safety bugs can lead to RCEs, which are considered unacceptable risks to most in computer science. Additionally, as Rust shows, memory-safety bugs can be checked by a computer, which can consistently apply those checks, making it an excellent bang-for-buck to use Rust or a comparable memory-safety checker. That's what pcwalton is saying.
  - blub 10y ago
    How can you say these are considered unacceptable risks to most, when people write so much code in C and C++? These risks are widely accepted and people are trying to mitigate them using various methods. And that's what I'm trying to communicate: they're only unacceptable to pcwalton and the Rust community.
    - carussell 10y ago
      That's quite a leap. It's not as if the world is C, C++, and Rust. The community behind any managed language is going to include not just people who've never used C++, but also plenty who have, and who reject it for the same reasons that motivate the Rust folks try their hand at doing better.
    - pcwalton 10y ago
      > How can you say these are considered unacceptable risks to most, when people write so much code in C and C++? This argument was very compelling in, for example, 1997. But, nowadays, most code is written in memory safe languages. Choosing to write your next Unix daemon in Go or your next Windows app in C# is not exactly an uncommon choice in 2017. > And that's what I'm trying to communicate: they're only unacceptable to pcwalton and the Rust community. I'm not a member of the security community, but I have never seen anyone in that community disagree with my claim that C and C++ are unsuitable for writing secure software at scale (at least without a robust sandbox or restrictive subsets). I have seen the claim that sandboxes are sufficient to mitigate memory safety problems, but even in that case the comparison becomes "C and C++ with a correctly maintained, leak-proof sandbox" vs. "a memory-safe language", not "C and C++" vs. "a memory-safe language".
- dang 10y ago
  > lecturing everyone "No, you really want to have 0 risk, you fools" On HN, please don't use quotation marks that make it look like you're quoting someone when you're not. It may seem a minor point, but we've found that it's important for clarity and respect. Also, "lecturing everyone" is borderline name-calling, which the site guidelines ask you not to do: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
  - blub 10y ago
    Point taken about the quotes. It was thought as a figure of speech, but I can see how that could be misinterpreted. "Lecturing everyone" is not at all name-calling. That's what he's been doing repeatedly, with code examples in several if not most threads related to C++ and safety. I also don't consider pointing out to someone that they're lecturing offensive or abusive. In this case, this behaviour has derailed the thread and attracted criticism from many other people.
sidlls 10y ago
It is ridiculous. Both because he doesn't qualify his targets the way you have and for the reason others noted (it's not modern C++). It's a gratuitous and inflammatory insult.

by eridius 10y ago

blub 10y ago

pcwalton is not framing the problem in a particularly useful way. This is a question of risk management and his argument is basically that one should always reduce the risk of memory management errors to zero. Others say that they can tolerate some risk, as long as it's in acceptable margins, since it's expensive to totally eliminate it. I don't think that lecturing everyone "No, you really want to have 0 risk, you fools" is a successful programming language advocacy strategy.

pcwalton 10y ago
> This is a question of risk management and his argument is basically that one should always reduce the risk of memory management errors to zero. No, that's not my argument. > Others say that they can tolerate some risk, as long as it's in acceptable margins, since it's expensive to totally eliminate it. These flaws are not "in acceptable margins". They were numerous and were found the instant Dmitry Vyukov turned a fuzzer on the library. And it's not expensive to totally eliminate memory safety bugs. Just code in a memory-safe language. That's what most people already do.
- blub 10y ago
  I wasn't talking about a specific example or these particular flaws, but in general, because this is just an instance of your generic argument that modern C++ is unsafe, where "unsafe" means not verifiably memory-safe. That's correct, but you are framing the problem in an unrealistic way in which Rust wins by default. In reality, this type of memory-safety guarantees will be evaluated against other concerns and those other concerns might be more important. For you memory-safety errors are unacceptable, that much is clear. For many they are more or less acceptable and insisting that they're unacceptable won't make them change their minds.
deleted 10y ago
[deleted]
moosingin3space 10y ago
Memory-safety bugs can lead to RCEs, which are considered unacceptable risks to most in computer science. Additionally, as Rust shows, memory-safety bugs can be checked by a computer, which can consistently apply those checks, making it an excellent bang-for-buck to use Rust or a comparable memory-safety checker. That's what pcwalton is saying.
- blub 10y ago
  How can you say these are considered unacceptable risks to most, when people write so much code in C and C++? These risks are widely accepted and people are trying to mitigate them using various methods. And that's what I'm trying to communicate: they're only unacceptable to pcwalton and the Rust community.
  - carussell 10y ago
    That's quite a leap. It's not as if the world is C, C++, and Rust. The community behind any managed language is going to include not just people who've never used C++, but also plenty who have, and who reject it for the same reasons that motivate the Rust folks try their hand at doing better.
  - pcwalton 10y ago
    > How can you say these are considered unacceptable risks to most, when people write so much code in C and C++? This argument was very compelling in, for example, 1997. But, nowadays, most code is written in memory safe languages. Choosing to write your next Unix daemon in Go or your next Windows app in C# is not exactly an uncommon choice in 2017. > And that's what I'm trying to communicate: they're only unacceptable to pcwalton and the Rust community. I'm not a member of the security community, but I have never seen anyone in that community disagree with my claim that C and C++ are unsuitable for writing secure software at scale (at least without a robust sandbox or restrictive subsets). I have seen the claim that sandboxes are sufficient to mitigate memory safety problems, but even in that case the comparison becomes "C and C++ with a correctly maintained, leak-proof sandbox" vs. "a memory-safe language", not "C and C++" vs. "a memory-safe language".
dang 10y ago
> lecturing everyone "No, you really want to have 0 risk, you fools" On HN, please don't use quotation marks that make it look like you're quoting someone when you're not. It may seem a minor point, but we've found that it's important for clarity and respect. Also, "lecturing everyone" is borderline name-calling, which the site guidelines ask you not to do: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- blub 10y ago
  Point taken about the quotes. It was thought as a figure of speech, but I can see how that could be misinterpreted. "Lecturing everyone" is not at all name-calling. That's what he's been doing repeatedly, with code examples in several if not most threads related to C++ and safety. I also don't consider pointing out to someone that they're lecturing offensive or abusive. In this case, this behaviour has derailed the thread and attracted criticism from many other people.

sidlls 10y ago

It is ridiculous. Both because he doesn't qualify his targets the way you have and for the reason others noted (it's not modern C++). It's a gratuitous and inflammatory insult.