I feel that it's pretty much a consensus in the software security world that C and C++ should be avoided. Not sure why he omitted Rust from the list, it is in the original document, and is pretty much a drop-in replacement for C++. Also using a dynamic language like Ruby for anything secure or safe sounds like a terrible idea.
He didn't remove Rust from the quote though. The NSA document[1] contains two lists of languages considered safe and for some reasons Rust is only included in one:
> Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®.
> Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®
[1] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
Nice observation, that seems to change the meaning of the paper substantially. OP might be privately admitting that you should use Rust if you can (not much that's new here, the Carbon folks said the same thing) and everything else just silently assumes that you can't do that for some reason - be it legacy or perhaps concerns about Rust's supposedly challenging learning curve. (It goes without saying that we shouldn't expect a C/C++ committee paper to outright advocate for Rust.)
I don't believe this. That's a reasonable claim for many other languages, but C/C++ are in a category of their own.
If one wants to know it all then yes. C++ is huge language. In practice except few people nobody really needs to. Subset of modern C++ enough to solve many real world tasks is very easy to learn in my opinion.
With Rust one must first train brain to wrap around those ownership rules and this might not be easy.
Fortunately or not I do not know even remotely enough of Rust to do the real comparison of "mental load" but at some point I will.
You need to do that in c++ also, otherwise you'll still have the same problem - only randomly at runtime instead of at compile time.
C++ users already understand ownership because C++ has ownership too. With C++ you have to me extra careful because the compiler won't save you from making mistakes like Rust will.
It's the same thing in Rust and C++. There is no difference conceptually.
Yes, it's a different experience, but both have the same concept of borrowing that you must understand.
And yes, I aware of all the bells and whistles modern c++ can bring to alleviate some of that burden - but people can and do subvert those mechanisms intentionally and unintentionally, especially over refactors.
I have a codebase that I ported from C# to C++ and found a few bugs where the items were copied instead of moved. In C# this was completely invisible since I "trusted" the compiler to do it properly - it did it wrong according to my wishes but right compared to the language.
By contrast in C++ it was very visible when the ownership was shared and wrong. I would rather use C++ because of this rather than trusting the compiler to get it right.
The same was true on generics/templates for a function/parameter system I'd written. The C# compiler resolved to the wrong function every single time but in C++ it resolved correctly.
I suspect there are plenty of subtleties in "safe" languages that actually muddy concepts of owernship and/or needless copying and lifetimes.
True in my experience. However, not the case in Rust, which is actually much more explicit about ownership, copying and lifetimes than C++.
Uh? What was being done there?
There are very good reasons to use C++ rather than Rust for some projects, typically interoperability, or developer already having experience in C++, as you mention.
However, having coded in both C++ and Rust professionally, my experience is that switching Rust has liberated much of my brainpower to concentrate on actually implementing useful stuff, so I have to strongly disagree on "mental load".
What is true is that, for a while after switching, getting code to compile in C++ is easier than in Rust. Took me maybe 6 months to 1 year before it became natural? However, as we all know, there is a huge difference between writing code that builds and writing code that works. In my experience, that difference is order of magnitudes larger in C++ than in Rust.
Performance and "low-levelness" wise it most likely is. From high level point of view it messes with how one must think when writing code and is missing some features / paradigms found in modern C++ (for better or worse, not gonna dwell on it here).
In my opinion it is closer to "drop-in replacement" for C.
> Also using a dynamic language like Ruby for anything secure or safe sounds like a terrible idea
afaik, it depends on how you use Ruby right? I agree that using metaprogramming could lead to issues, but i would like to hear your view points on security?
Static audits (including, but not limited to static typing) are very strong barriers against entire classes of safety issues. Not supporting them doesn't automatically make code bad, but it prevents lots of defense-in-depth (what the Rust community calls "fearless programming").
Languages like Ruby are indeed nightmares for static analysis. Even constructing a call graph is a disaster. But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant. Do you want to prove that your Ruby program won't crash? Good luck. But do you want to prove that your Ruby program won't read key material out of memory when it shouldn't? Pretty easy. The security problems in these sorts of managed languages tend to either be logical errors (also present in a C++ codebase) or dynamic code loading / unsafe deserialization (not present often in C++ codebases, but much easier to eliminate in principle).
> But "safety properties" includes a huge amount of stuff that isn't necessarily security relevant.
Good remark.
However, as a former safety (not security) researcher, it feels to me like the consensus in some parts of the security community is that once you have lost safety guarantees (i.e. you're not sure what your program is going to do), you have lost this entire line of defense and need to move to the next one (e.g. containerization).
Example: Python has a very clear syntax and it is often easy to audit code to find out whether the algorithm implemented matches the specifications. However, Python is also a language in which `True`, `False` or integer literals can be redefined dynamically. So, with this in mind, how can you be sure that your Python code that appears to calculate fibonacci is not going to actually `ctype` into something memory-unsafe that could be used to escape into the shell?
Of course, this example (and anything analogous in other dynamic languages) requires active malicious intent by the author of the code or one of the module it uses, but it's not too hard to come up with examples that end up with OS or XSS injections, without malicious intent by the code author.
I believe that we both agree that these examples are safety issues escalating into security issues.*
> Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®.
> Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®.
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
Stroustrup quotes the second one without Rust.