Governments triggered this entire discussion with their papers and plans to strengthen cyber defenses. The article states that some experts ask for our industry to be more regulated in this regard.
I am surprised that possible regulations are not even listed as a factor that in the decission to stay with C++ or move to something else.
Sure, COBOL is still around after decades, but nobody ever tried to pressure banks into replaceing that technology AFAICT.
What I find surprising is that there are a lot of steps between a free-for-all and state intervention through regulation that those experts seemed to have skipped altogether, such as voluntary auditing, state-sponsored industry initiatives to specify best practices, invest in the development of static analysis tools and memory profilers, or making vulnerable companies liable for the consequences of attacks.
But no, they jumped straight into state-imposed regulation. Because keeping people out is a solution?
There is no regulation at this time. There may not be regulation ever. Before there is any regulation we will see nudging into the “right” direction. Suggesting that companies define a memory safety roadmap could be considered as the very first nudge, or maybe not:-)
All I wanted to say is that ignoring the possibility of regulation in such a text seems a bit short-sighted to me.
Because industries don’t do shit until forced to. People have been writing code for decades and virtually nothing has been done on this topic, so government has to regulate.
Let’s ask Boeing about self regulation, for instance
One major selling point for C++ for new projects is efficiency. People are still skeptical that other languages can truly compete with C++ in that space. For example, people that need low latency (game development, trading, etc.) or are into HPC, may never be convinced to switch away from C++ because of this reason. We still don’t have enough data to argue if another language that provides safety can compete with C++ in this area.
While I can agree we don’t have sufficient data to make hard conclusions on this front, I think there are enough early indications that point to Rust being able to stay on par with or even outperform C++ in this regard:
- Google, Firefox and Microsoft report performance improvements from migration to Rust. Some of this was attributable to having a better understanding of the problem domain upfront, thus giving an opportunity to choose better data structures. But a large part was also because choosing Rust obsoleted the need for other safety techniques that had a higher runtime impact, such as Google’s MiraclePtr or even sandboxing.
- Crypto-traders have already massively adopted Rust as their language of choice, providing evidence the language is fast enough for their use cases. It seems a matter of time before traditional traders make the switch.
- Rust ownership model avoids issues with possible memory aliasing that are inherent in C and C++. This enables compilers to apply optimizations they cannot apply otherwise, leading to higher theoretical throughput. Meanwhile, areas where Rust is theoretically slower (such as mandated bounds checking) are also applicable to C++ whenever safety is prioritized.
While I can agree we don’t have sufficient data to make hard conclusions on this front, I think there are enough early indications that point to Rust being able to stay on par with or even outperform C++ in this regard:
I’m skeptical of these claims, not because X or Y is better or worse, but because milking the last drop of performance has far more to do with software architecture than it has to do with the programming language per se.
Also, I think this sort of argument always leads to specious reasoning. C is the undisputed performance lead, and you surely do not see Rust proponents using benchmarks to argue they should rewrite all Rust code in C.
C is the undisputed performance lead
This sounds like it would be hotly disputed by almost anyone you said it out loud to, even if you said it 40 years ago.
This sounds like it would be hotly disputed by almost anyone you said it out loud to, even if you said it 40 years ago.
I think you’re expressing uninformed and uneducated opinions.
Even Debian’s computer language benchmarks game showcases C consistently outperforming Rust, with some notable exceptions in some key benchmarks.
And Rust was not a thing 40 years ago.
Anyway, I think I proved my point with regards to the silly idea that performance is a decisive trait. You cannot have your cake and eat it, too.
Nah, 40 years ago this discussion already existed and it was between C and FORTRAN at the time. FORTRAN was often faster than C, precisely because of aliasing rules that Rust now benefits from as well: https://stackoverflow.com/questions/146159/is-fortran-easier-to-optimize-than-c-for-heavy-calculations
Btw, are these the Debian benchmarks you were referring to? Because I can see C and Rust trading blows with one another, but neither taking a consistent lead. Nothing that points to an undisputed performance lead surely. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gcc.html
But I still agree with your premise that performance isn’t the deciding factor. Which means that other than legacy reasons, C (and C++) really doesn’t have much going for it anymore.
I agree performance is much more about architecture than language performance at the bare metal. But especially in security-conscious environments C and C++ lose in performance because architecture decisions include mitigations that need to compensate for the languages’ lack of safety. I know of several projects where C or C++ code is either delegated to separate processes with reduced permissions or to WASM sandboxes. Firefox even famously used to compile C++ code to WASM and then used a WASM ahead-of-time compiler to turn it back into native code that still maintained properties of being sandboxed. Such measures gravely impact performance however, so in those instances C is far removed from having a performance lead.
We can improve security via updating the C++ language forever, but the threat remains in the package management, and I couldn’t find that discussion in this article.
Great article, though I would love to see a summary that breaks down the possible approaches and what the status of each is.
I’m quite interested in the research that adds runtime provenance info to pointers, so you store (for example) a region ID that lets you do bounds-checking on pointer arithmetic. It doesn’t achieve Rust-level safety, but means buffer overflows can only get so far before they segfault.
I know there are many cases where ordinary code will cast mystery memory into a pointer, but in modern C++ these generally live in templated library code. If we introduce a Rust style “unsafe block” to disable compiler warnings on these, I think I could refactor most of the others out of the legacy code I maintain.
I don’t know how many exploits this would prevent in practice though. I have no expertise there
