It's compilers and compiler optimizations that make code run fast. The real question is if the Rust language and the richer memory semantics it has help the Rust compiler to provide a bit more context for optimizing that the C compiler wouldn't have do unless you hand optimize your code.

If you do hand optimize your code, all bets are off. With both languages. But I think the notion that the Rust compiler has more context for optimizing than the C compiler is maybe not as controversial as the notion that language X is better/faster than language Y. Ultimately, producing fast/optimal code in C kind of is the whole point of C. And there aren't really any hacks you can do in C that you can't do in Rust, or vice versa. So, it would be hard to make the case that Rust is slower than C or the other way around.

However, there have been a few rewrites of popular unix tools in Rust that benchmark a bit faster than their C equivalents. Could those be optimized in C. Probably; but they just haven't. But there is a case there of arguing that maybe Rust code is a bit easier to make fast than C code.

> It's compilers and compiler optimizations that make code run fast

Well, then in many cases we are talking about LLVM vs LLVM.

> Ultimately, producing fast/optimal code in C kind of is the whole point of C

Mostly a nitpick, but I'm not convinced that's true. The performance queen has been traditionally C++. In C projects it's not rare to see very suboptimal design choices mandated by the language's very low expressivity (e.g. no multi-threading, sticking to an easier data structure, etc).

Compilers are only as good as the semantics you give them. C and C++ both have some pretty bad semantics in many places that heavily encourage inefficient coding patterns.

The compiler backend yes. But there probably is a lot of work happening elsewhere in the compiler tools.

> It's compilers and compiler optimizations that make code run fast.

Compiler optimisations certainly play a large role, but they're not the only thing. Tracing-moving garbage collectors can trade off CPU usage for memory footprint and allow you to shift costs between them, so depending on the relative cost of CPU and RAM, you could gain speed (throughput) in exchange for RAM at a favourable price.

Arenas also offer a similar tradeoff knob, but they come with a higher development/evolution price tag.

It might be a minute or two before we get to see the words "favourable price" anywhere near the word RAM again.

> we can say that a fast language is the one where an average programmer is most likely to produce fast code with a given budget

I'd say most people use this definition, with the caveat that there's no official "average programmer", and everyone has different standards.

Right, but if we assume that programmers' compensation is statistically correlated with their skill, then we can drop "average" and just talk about budget.

That seems like a wild assumption to make.

Statistically? I don't think it's that wild.

If you prefer it, salaries correlate with years of experience, and the latter surely correlates with skills, right?

(No, this doesn't mean that every 10 years XP dev is better than a 3 years XP one, but it's definitely a strong correlation)

I think when designing a language, and a set of libraries for it, the designer has an idea of how code for said language should be written, what 'idiomatic' code looks like.

In that context, the designer can reason about how should code written that way should perform.

So I think this is a meaningful question for a langauge designer, which makes it a meaningful question for the users as well, when phrased like this:

'How does idiomatic code (as imagined by the language creators) perform in language X vs Y?'

These are the languages an "average programmer" would use. What language are you thinking of?

I may be biased, but I think that if you have a budget that's reasonable in the industry for some project size and includes not only the initial development but also maintenance and evolution over the software's lifetime, especially when it's not small (say over 200KLOC), and you want to choose the language that would give you the fastest outcome, you will not get a faster program than if you chose Java. To get a faster program in any language, if possible, would require a significantly higher budget (especially for the maintenance and evolution).

Do you think C# / .NET doesn't stack up in terms of budget, or not stack up in terms of runtime speed?

It's probably in the same ballpark. To me, the contenders for "the fastest language" include Java, C#, and Go and not many more.

Ah thanks. That clarifies things.

Go?

I don't think so, but it may not be far behind. More importantly, though, I'm fairly confident it won't be Assembly, or C, or C++, or Rust, or Zig, but also not Python, or TS/JS. The candidates would most likely include Java, C#, and Go.

Purely by the numbers, an "average programmer" is much more likely to use Javascript, Python, or Java. The native languages have been a bit of a niche field since the late 90's (i.e. heavily slanted towards OS, embedded, and gamedev folks)