Last year saw a proliferation of talks and articles about safety in C++. Lucian Radu Teodorescu gives an overview of these and presents a unified perspective on safety.
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.
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.
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.
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.