Safety may seem like a binary property, but it's really not.
Modern C++ is not as safe as Rust, but it is much safer than C, and significantly safer than doing manual memory management and raw pointer manipulation in C++. The interesting question is if that's enough for a particular project.
In general, I would argue that it is, because security is but one of the non-functional properties of software and the types of bugs that Rust prevents compared to modern C++ are but one category of security-relevant bugs.
The advantages that modern C++ can bring over Rust would compensate on average for its safety gap.
C on the other hand is simply a losing proposition safety-wise. Whatever I do, the type system won't do much if anything to help me prevent or catch bugs.
> the types of bugs that Rust prevents compared to modern C++ are but one category of security-relevant bugs
Memory safety bugs frequently result in basically the worst possible compromise imaginable: arbitrary remote code execution. It is possible to get RCE in other ways, but lack of memory safety makes it way way easier.
This doesn't change anything, you've just added another link at the end of the system > non-functional > security > code execution security chain.
Each project has the option at every link to decide that they're willing to accept a certain risk there and then tools delivering better results don't matter.
Memory safety is somewhat special because it's foundational: it is a prerequisite for any other sort of safety/security, as memory safety violations often can be(/are) exploited to trigger pretty much any other problem (e.g. RCE can do anything); other security problems are usually more constrained.
The thing is, and Rust advocates seem to consistently plug their ears when they hear it, is that most software written specifically in C++ is very highly specialized stuff with a small specific client set, where security is just not an issue.
According to the poll that JetBrains did when it started working on CLion, about half of C++ usage is in financial software. I will tell you first hand that in most applications in financial software, C++ servers will be talking to other internal servers, exchanges, reputable data distributors, etc. The idea that memory = security risk is just not a connection that people around here generally make.
I also know some game developers and my strong sense is that games are similar. Video games may talk to a specialized multiplayer server, an update server, and that's mostly it.
I could continue, but you get the idea. For most C++ developers I've ever encountered, memory issue == bug, != security risk.
Browsers, which operate on maximally complex data (a Turing complete programming, JS) and are by nature exposed to the entire world, including malicious users who want to harm other browser users, are simply not the typical domain for C++. I think there's every chance that Rust is a good fit for writing browsers, but outside of that things are much less clear (at least, at the moment).
Not sure what that has to do with anything. The parent is a very vocal Rust proponent and made a ridiculous comment which has been called out by myself and several others. It hasn't anything to do with any "small group of people" talking smack about C programmers. Although that's unfortunate, too.
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.
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.
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.
> 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.
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.
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.
> 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".
There exist entire industries built on C and C++ today. The security community may think that they're unsuitable, but they're not the ones building the software and making the decisions.
e.g: Mozilla exists because of C and C++. Take that away and Mozilla ceases to exist.
I don't know how to explain this more clearly: you are trying to enter an established market and "sell" a product based on its safety capabilities.
But your problem is that the market doesn't think it has a big safety problem, they think they can manage it. And instead of recognizing that and adapting your marketing efforts, you're just repeating the same safety pitch with more examples and details.
How has this been working for you, besides antagonizing the potential "customers"?
> But your problem is that the market doesn't think it has a big safety problem, they think they can manage it.
Is that not what his original comment was addressing though? There are a number of people who feel there is no safety problem, but examples like this are good indications otherwise. Boost is a very fundamental (as in low-level, not as is essential) library in many cases and having memory safety problem at such a level should be concerning.
That's not what's happening, this is an old(er) discussion.
pcwalton is asserting in general that modern C++ is not memory-safe, with the goal of promoting Rust and discouraging C++ usage.
Now that assertion is true, but it's not really useful, because programming language choices are not done only on the basis of a language being completely memory-safe. It's also misleading to emphasize only this one aspect (while ignoring others) and to such an extent (complete vs. good-enough safety).
It is concerning that this regex library has security issues. People should review their usage of it. But the original comment is something between offtopic and being inflammatory for the sake of it.
"There are a number of people who feel there is no safety problem"
The thing to remember here is: no safety problem... big enough that one should abandon C++ for Rust instead of working on tooling and idioms to improve it. That's what pcwalton would like.
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.
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.
To be fair, it is always the same small group of people who do that.