[jandrewrogers]

The main performance difference between Rust, C, and C++ is the level of effort required to achieve it. Differences in level of effort between these languages will vary with both the type of code and the context.

It is an argument about economics. I can write C that is as fast as C++. This requires many times more code that takes longer to write and longer to debug. While the results may be the same, I get far better performance from C++ per unit cost. Budgets of time and money ultimately determine the relative performance of software that actually ships, not the choice of language per se.

I've done parallel C++ and Rust implementations of code. At least for the kind of performance-engineered software I write, the "unit cost of performance" in Rust is much better than C but still worse than C++. These relative costs depend on the kind of software you write.

[throwaway2037]

I like this post. It is well-balanced. Unfortunatley, we don't see enough of this in discussions of Rust vs $lang. Can you share a specific example of where the "unit cost of performance" in Rust is worse than C++?

[pjmlp]

> I can write C that is as fast as C++.

Only if ignoring the C++ compile time execution capabilites.

[pmarin]

C++ compile time execution is just a gimmicky code generator, you can do it in any language.

[pjmlp]

Yeah, I could also be writting in a macro assembler for some Lisp inspired ideas and optimal performace.

[jandrewrogers]

Any code that can be generated at compile-time can be written the old fashioned way.

[pjmlp]

Including using a macro assembler with a bunch MASM/TASM like clever macros.

[gf000]

> I can write C that is as fast as C++

I generally agree with your take, but I don't think C is in the same league as Rust or C++. C has absolutely terrible expressivity, you can't even have proper generic data structures. And something like small string optimization that is in standard C++ is basically impossible in C - it's not an effort question, it's a question of "are you even writing code, or assembly".

[jandrewrogers]

Yes, it is the difference between "in theory" and "in practice". In practice, almost no one would write the C required to keep up with the expressiveness of modern C++. The difference in effort is too large to be worth even considering. It is why I stopped using C for most things.

There is a similar argument around using "unsafe" in Rust. You need to use a lot of it in some cases to maintain performance parity with C++. Achievable in theory but a code base written in this way is probably going to be a poor experience for maintainers.

Each of these languages has a "happy path" of applications where differences in expressivity will not have a material impact on the software produced. C has a tiny "happy path" compared to the other two.

[pjmlp]

Also in theory, one could be using a static analyser all the time as a C or C++ build step.

Lint is part of UNIX toolset since 1979, and we have modern versions freely available like clang tidy.

In practice, many devs keep thinking they know better.