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.
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.
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.
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.
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.