145
C++ creator rebuts White House warning
(www.infoworld.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 19 Mar 2024
145 points (92.9% liked)
Programming
17314 readers
15 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
Well ok, but the concern is about the weaknesses, Mr. Stroustrup.
Stroustrup to congress: "You expect me to talk?"
Congress: "No, Mr Stroustup, we expect your language to DIE!"
I don't think these discussions on "weaknesses" come from a place of intelectual honesty. None of these arguments even touches the fact that there are already a myriad of freely available static code analysis tools and memory profilers that do a very good job catching memory safety issues.
For some unexplainable reason, these criticisms of C++ always focus on a single strawman: these tools do not exist and no developer in the world cares about the topic.
There is a lot of fanboying in discussions like these, so I understand if you're weary of that. That said I don't think static analysis tools are a very good point of comparison for (what I'm assuming that you're referring to) Rusts ownership system.
While static analysis tools certainly can be useful for some classes of errors, there are types of errors that they can't catch that the borrowchecker can. This is because the language are built around them in Rust. Rusts lifetime analysis is dependent on the user adding lifetime annotations in certain situations, so since c++ doesn't have these annotations static analysis tools for c++ can't benefit from the information these annotations provide.
Furthermore, c++ suffers from being an old language with a lot of features. Legacy features can allow for various loopholes that are hard for a static analysis tool to reason about.
C++ static analysis tools can find errors, but Rusts borrowchecker can prove the absence of errors modulo unsafe code.
That said, I don't have any good data on how much of a problem this is in practice. Modern c++ with a CI-pipeline doing static analysis and forbidding certain footguns is safe enough for most contexts. Personally, I'm exited about Rust more because I think that it's a nicely designed language than because of its safety guarantees, but it doesn't really have the ecosystem support for a lot of things, like gamedev or ui at the moment.
A huge number of exploits rely on unsafe memory bugs.
The fact you have to rely on external tools to manage these issues perfectly illustrates that the language is not memory safe without extra work and it's easy to miss things.
It seems much more sensible to just use a language that is.
I haven't seen anyone make the argument that denies these things exist - it's that the existence of these tools are even necessary to safeguard the language in the first place is the argument. And then on top of that, you'll additionally need a shop that is even allowed the time to properly utilize these tools and implement their usage as standard practice within the company culture.
That there are alternatives which remove (significantly more) footguns is the overall point. Work in one of these other languages so e.g. dumb-ass PMs don't even have the option of pilfering the time it takes to code safely, as it would already be baked in.