> I think a much more interesting question is how much safer a code written in rust today would be vs a C/C++ code written today , reflecting our current understanding and knowledge on how to build safe system.

A lot safer, judging by browser exploits.

> reflecting our current understanding and knowledge on how to build safe system...

Browser engines are more indicative of the current "understanding and knowledge of how to build safe systems" than nearly any C++ codebase in existence.

Part of the current "understanding and knowledge of how to build safe systems" is to use a memory-safe language.

Despite all the flashy tools that proponents of C and C++ claim that makes C++ as safe as Rust, it's not doing any good at stopping the exponentially-increasing amount of vulnerabilities and crashes that are being reported over the last few years.

You have no data at all to back this up. The vulnerabilities you speak of are, far more often than not, written in old-style C and C++. That doesn't make Rust a bad idea, but it does mean your claim is completely unsubstantiated.

Advocating for Rust by lying is not going to help anyone.

This is the same line of logic and statements repeated by C and C++ programmers that shortly thereafter get showed up with a list of CVEs in their 'modern C/C++' projects. Remember the recent Curl developer PR disaster?

Yes, it's the same line of logic because it's correct.

The claim that Rust's memory safety is sound while C++'s is not is... not really the question. The question is whether that matters in practice. C++ has certainly improved in making certain mistakes easier to avoid.

Now, I come down on the Rust side for many situations, but making unsubstantiated claims about your language of choice is exactly the problem people had with the Curl blog post. Please stop making them about Rust.

You've living in some serious denial. You were given a point that proves that your line of thought is incorrect, and you continue on to completely ignore that point by stating that it is correct. So tell us, o'wise one, why is that top C and C++ projects are continually riddled with CVEs, crashes, and other severe issues that are 90+% the fault of C and C++? Why is it that veteran, experienced C/C++ programmers are still making these same mistakes 20, 30, and even 40 years into their careers?

I think it's too early to tell if rust will prove any better in the real world, which includes things like devs using unsafe sections to cope with time pressures.

Use of unsafe in Rust is not required or recommended in most, if not all situations. That said, auditing a handful of small unsafe blocks is easier than auditing an entire project.

The question then is whether large chunks in unsafe is still better than the entire program in the equivalent of unsafe (C).

> Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons.

AFAIK no one's done a comprehensive survey, and it'd be hard to know for certain what someone would choose to use unsafe for until/unless they actually rewrite the code in question into Rust.

But if you look at code that is written in Rust today, I think you'll find less than 1% of the code is unsafe. [1] I think it's used for

* FFI / interfacing with C (common now, but less so the more you rewrite into Rust),

* low-level code (such as synchronization primitives and data structures), and

* a few bits of performance-sensitive code.

My gut feeling is that many of these bugs are in safe code, the "boring" 99%. The bugs would either be prevented by the compiler or turned into a panic at runtime instead of undefined behavior.

When people use unsafe, I'd like to think having to explicitly flag it as such would make authors and reviewers more careful. But certainly there's no 100% guarantee; I've seen broken unsafe Rust code in the wild already. As a small example, sqlite3::core::ResultRow::column_slice [2] is unsound; a following call to another column_* method would invalidate the returned pointer, [3] but as they all take a &self nothing prevents you from using the pointer after it's no longer valid. column_slice should take a &mut self instead. I haven't reported the bug because this buggy crate has been marked obsolete in favor of rusqlite.

[1] For a project of mine, it's found on 0.3% of non-comment-non-blank lines (23 unsafes / 7,390 lines). 13 of those were for FFI; the remaining 10 were due to my unfortunate obsession with optimizing for CPU. If anyone's done an accounting of more/larger projects, I'd be curious to hear it.

[2] http://www.madmode.com/rust-sqlite3/sqlite3/core/struct.Resu...

[3] https://www.sqlite.org/capi3ref.html#sqlite3_column_blob

You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programers. A portion will, perhaps even a substantial portion, but I'd be willing to wager a far larger portion of the Rust written today will follow best practices and doesn't have to be written by expert programers. This is because the safety in Rust isn't optional, like it is with C/C++ best practices/new features.

> You seem to be presupposing that all, or much of the C/C++ written today will follow best practices and be written by "expert" programmers

No, the argument i am trying to make is that if someone wants safe and reliable code, it's possible to buy that in C/C++ at cheaper price than to migrate to whole new language and platform.

> I'd be willing to wager a far larger portion of the Rust written today will follow best practices

Yes, as you mentioned that's by design. But i don't that the metric we should be looking at : in the group of people/team/compagny who actually care about safety and performance ( and let's be honest that group is the biggest one), what proportion will be using C++ vs rust.