Rust Safety Is Not Superior to C++, Bjarne Stroustrup Says – Slashdot

https://security.googleblog.com/2022/12/memory-safe-language...

While C++ with the latest features should be secure enough in theory, in practice practically no one is using all the latest features just right to achieve the needed security.

Sorry, the NSA report is correct. Using C or C++ opens your project up to memory safety risks. Use a memory safe language if at all possible.

> In particular, the work on the C++ Core Guidelines specifically aims at delivering statically guaranteed type-safe and resource-safe C++ for people who need that without disrupting code bases that can manage without such strong guarantees or introducing additional tool chains

Tells me he doesn't really "get it." People do not follow the core guidelines, and other languages are designed such that there aren't guidelines. There's a type checker (wave hands here) that proves your code and its dependencies are memory safe (within some sane definition).

Another thing worth mentioning is that "type safety" isn't something other languages need to worry about since it's generally not possible to tell a type checker that it's wrong.

I've not worked with Visual C++ much (used it once and thought the CLI pointers were a cool feature, though), so maybe that's better. However, my experience on Linux has always been… Uncomfortable? I don't know what to call it.

Sure, all of these things kinda and almost work. Technically they make things marginally better. So, he's not wrong, but only by the strictest possible definition of "wrong". And Jesus Christ, they always made me feel like I stepped into a time machine and traveled back 30 years (and I'm only turning 30 this year), and induced so much friction into both set up and workflow.

Rust on the other hand? I don't have to think about it any of those, and it borrows (no pun intended) great FP type system features to boot.

Also, I don't know what went wrong with C++ Concept, but I was excited about them initially, and now I'm just underwhelmed by them. The coroutine stuff is also a bit frustrating.

C++ is a language that has jaded me with a thousand small frustrations over the years. I still have a small hope that it'll one day rebound (as I used to write it for a long time), but in the mean time I'll stick to Rust.

Also, since he's deliberately chosen to be petty about memory safety in Rust, it probably doesn't warrant addressing, but I'll take the troll-bait this time: nobody EVER said memory safety is the ONLY safety. Ever. I've not seen a single person make that claim, or tout Rust as a "safe" language. Memory safety DOES however eliminate a whole category of bugs (a lot of which can be security or stability bugs in real world environments). That's literally all there is to it.

Edit: my experiences predate a having a Cpp LSP that works (idk if that has changed in the last few years)

(For the record: I’m a lifelong C/C++ programmer who has written large systems in it)

> There is not just one definition of "safety", and we can achieve a variety of kinds of safety

I agree, but C++ and Rust both fail at what I could consider a major form of safety not too far below memory safety. It might be called “capability safety” or “effect safety”: a function call should not be able to have side effects or read data outside that explicitly permitted by the caller (or importer or program manifest or whatever). I would consider a form of “unsafe”-like escape hatch acceptable so long as using that escape hatch is itself treated as a capability.

Rust and C++ don’t do this at all, although I could imagine it being retrofitted into Rust or a similar language. Java sort of tried, and it was a near complete failure on many counts. Several experimental languages have this as an explicit goal.

Some container and VM systems attempt this sort of security. Sandstorm was a notable example.

If Bjarne put something akin to Rust's Editions in C++, and regularly removed poor designs, then yes C++ would be pretty close to Rust for new projects.

But if you wanna write safe code, from scratch, because you don’t want to recycle your dangerous old C++ codebase; then why would you write that new code in C++ when rust is ready and here to do it?

is modern c++ so complex, big with a huge surface area to shoot yourself, yes.

that's the problem with C++ it's such a huge language that knowing to do the right thing is difficult.

Right, but is it still possible to write bad, unsafe, inefficient C++ that looks indistinguishable from the safe kind?

But I remember having off-by-one errors doing just that in basic for-loops in C++.

> I envision compiler options and code annotations for requesting rules to be enforced. The most obvious would be to request guaranteed full type-and-resource safety.

You'd think someone that worked on a compiler for decades would come to the realisation that opt-in safety is just dumb. You want everything to be safe by default, despite the performance implications, and then allow programmers to peel back safety features explicitly where they are not needed.

You don't buy a gun and the safety lock as an add-on.

Borrowing from Donald Norman and his Design of Everyday Things book, safe programming in C and C++ relies too much on "knowledge in the head" instead of "knowledge in the world" in order to do it correctly.

You don't need the big borrow-checker hammer from Rust to be a lot better. Most CVEs (memory safety related) are about out-of-bounds writes/reads. You could mitigate a huge chunk of those problems by just doing something as sensible as having a well defined concept of slices with bounds checking turned on by default.

But this seems to elude the C and the C++ committee for some weird reason.