Do we need US gov advisory in order to be convinced? Microsoft and Chromium were telling this for years

https://www.chromium.org/Home/chromium-security/memory-safet...

>The Chromium project finds that around 70% of our serious security bugs are memory safety problems. Our next major project is to prevent such bugs at source.

https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...

>As we’ve seen, roughly 70% of the security issues that the MSRC assigns a CVE to are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated. And we’re not the only company to have reported such findings.

> Do we need US gov advisory in order to be convinced?

Even HN still has a fair number of comments along the lines of “C++ is fine, you just need to do things the modern way and avoid making any mistakes”...

Yes, disclaimer, or necessary predefense here? ;) Looking at rust, wanting to play with it, liking it very much from what I have seen, to some degree... still it also seems to develop some complexity problems, and is it fully stable in regard to language now? Can we take it to a certification body already? Or will it also become the next C++ with the later on-boltings? Anyway..

> “C++ is fine, you just need to do things the modern way and avoid making any mistakes”

I know I will be burned now, but: Which is kind of true if you stick to modern C++ (>11) .. and if you do that (maybe enforced by a style checker or some new cpp standard setting?) you even strip out the "avoid making any mistakes". Again, fully admitted, C++ is kind of a grown and ugly language, with many holes that you could use if you don't systemically forbid them.. but if it just would make real step to enforce / deprecate with a safe-strict-standard all the bad old C/C++ heritage and there'd be something like an enforced safe-C++, I think it would not be too far away from Rust..

.. because I lately read a Rust paper "Safe Systems Programming in Rust" and what did I needed to read there?: "There are a number of data types whose implementations fundamentally depend on shared mutable state and thus cannot be type-checked according to Rust’s strict ownership discipline. To support such data types, Rust embraces the judicious use of unsafe code encapsulated within safe APIs." (and more schizophrene explanations how we still can do everything in Rust, but are safe follow..)

If that is the case, then this is really not too far away from safe&modern-C++, where you only touch the unsafe parts for hard to find last bits of performance?

Especially, and hear me out .. what I'm not getting is consider the typcal embedded/automotive and similar applications, which usually run single threaded and without any dynamic memory allocation and by that already exclude all of the data-race and other problems. You are basically left with bounds-checking on arrays and similar buffers, and you can really, no you will have that if you use modern C++?

I'm really confused more than ever :) .. but the rust complexity curve does not seem to be only high for the devs, but also for the orgs who require standardization&certification. Hope that will follow now, and also some way to completely abandon unsafeness completely in Rust before we put it so high up the throne? and plea

Haven't we seen any Rust security issues because there is so little software out with it? If some memory unsafeness in some Rust program happens, will we always hear then Rust is safe, this was just unsafe code (like today it was all every time the hacker's fault?? :D )

On the topic of a “forced” C++ to be close to rust.

I guess technically if you forced all allocations to be in unique_ptr<> and then used std::move every time you passed it as a parameter, you would kind have the first part of rust (ownership rules) down.

But the borrow checker? Not sure how that’s possible. It might be (and in fairness, you could require all references to be const)

But I am not sure if there’s a way to do the usual 1 and only 1 borrowed mutable value. (Unless someone can think of a way?)

The C++ commitee is interested. Carbon is a Google attempt at at c++ with safety.

I don’t think Carbon will have a borrow checker. I am under the impression it’s just checking array bounds and adding nicer syntax

Carbon is experimental, don't make any predictions. Herb Sutter has his own that I forget the name of with interesting things that when mature are making it to C++