Well ok, but the concern is about the weaknesses, Mr. Stroustrup.
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.
a single strawman: these tools do not exist and no developer in the world cares about the topic
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.
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.