[lelanthran]

Agree; this is not an issue that slows down my development or bughunts.

You can get a long way towards safety without learning Rust. It's those rare cases that will get you.

It's a trade-off; take the time to learn the language and deliver later, or just use what you already have to deliver a product now.[1]

[1] During a Rust discussion some years back, when I was at a different company, on a specialised and large-ish product written in C++03.

I went through about 3 years of tickets (limited to only the bugs reported). No open ticket was older than a few weeks. Out of maybe 1000 bugs, only a single one was something Rust would have prevented. I would think that most mature products will have similar stats, so the trade-off is not as obvious as it looks to be on the surface.

Deliverables matter.

[vgel]

It probably depends on project type and how complex your ownership models are, but that doesn't really track with large projects having a majority of their CVEs be memory safety issues that are far less likely in Rust[1] (e.g., https://www.chromium.org/Home/chromium-security/memory-safet...)

[1] I say far less likely because obviously it's possible with unsafe Rust, but I've never had one happen, seen one happen in real code, or been affected by part of a dependency tree having one.

[lelanthran]

I'm not saying that a large number of CVEs won't be prevented in Rust, I'm saying that so few bugs are CVEs that the trade-off is not always worth it.

If you have 1000s of bug reports, of which 5 are CVEs, and then have 3 of those 5 be preventable, most dev teams are still going to consider the cost/benefit of going through the pain of developing a long-term product in Rust, or of switching to Rust altogether.

[bschwindHN]

> of which 5 are CVEs

Those 5 are just the ones you know about...

[lelanthran]

> Those 5 are just the ones you know about...

It's pointless making a cost/benefit analysis on things that probably don't exist.

[girvo]

I suppose it comes down to risk assessment; if those CVEs are critical “fix this now or the world catches fire”, then their relative infrequency seems to be outweighed by their impact, no?

[lelanthran]

> I suppose it comes down to risk assessment; if those CVEs are critical “fix this now or the world catches fire”, then their relative infrequency seems to be outweighed by their impact, no?

No.

[snovv_crash]

CVEs are a tiny, tiny fraction of bugs.

[nemothekid]

>I went through about 3 years of tickets (limited to only the bugs reported)

This statement is meaningless without any insight on how bugs were created. If the bug reports exclusively dealt with "happy-path" or "business logic QA", then of course you won't see any CVEs. Did the use of fuzzers or address sanitizers create bug reports? Were these tools even used? If not, the claim that only one of 1000 bugs were memory safety issues isn't credible; you weren't looking for them so of course you didn't find them.

I think it says a lot when almost every C++ developer claims to have a higher quality code base compared to say Linux or Chromium when it comes to memory safety errors.

[Daishiman]

What is it about C++ as a community where most average devs claim an inhuman level of proficiency but only the coders with experience in real critical codebases have the humility to claim that without extremely strict coding practices and extensive use of fuzzers we're barely smarter than apes at churning out safe code?