C as a language is obsessed with the fact that C runs everywhere. Even on a DSP with a 24-bit char and a 24-bit int. If you take out those complexities and you add 40 years of lessons on language design, you can make something a lot simpler.
This makes no sense whatsoever and very far from the truth.
I don't think there is such a specific thing and certainly disagree that all idiomatic rust is somehow slower by default.
You can write rust like you might write a higher level language and then that can end up slower but if you write idiomatic low level rust, the performance is much harder to compare with C. There are things which will be faster in C and things which will be faster in Rust but broadly things will be extremely similar in performance.
I write bare metal embedded rust a lot these days and there are quite complex concepts you can represent in rust which make your code a lot safer without a performance hit.
1. Rust structs are generally smaller due to layout optimization.
2. A 10-50% difference is well within the “are you measuring debug builds?” territory.
I’m curious what code you are writing that requires unsafe all the time? I do a lot of low-level optimization, and unsafe is barely ever actually needed.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I’m not really sure what your point is by linking the benchmarks game. I mean, it’s a fun activity, but this is saying nothing about C vs. Rust. It may or may not be saying something about GCC vs. LLVM.
Why can't people just take the win of "10% slower, 10x easier"?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Also note that 3 of 4 comparisons in favor of Rust are marked "contentious" for using different algorithms with different limitations - they are not equivalents. The last one is k-nucleotide, which is a very algorithmically heavy problem where nobody has given optimized C and Rust has won at producing a decently optimized thing quickly. Note that the fastest C++ implementation handily beats Rust on that one, also.
On a similar note, I don't think it's worth talking about C as if the only C being written is highly optimized hand rolled assembly style of C. That's one in a thousand projects.
Now, as for the benchmarks game, you mean 3 of 6 comparisons in favor of Rust. Rust is winning the benchmarks against C there.
I had a look and the top Rust and C entries are using the same pcre2 library in regex-redux. Same for pidigits where both libraries are using GMP.
The only library difference I can see is that the C entries are using OpenMP and both Rust entries are using Rayon. Now, you could claim that using Rayon gives Rust an unfair advantage. But an entirely userland library beating an industry standard with support from compilers is not a good look for C.
Using Clang instead of GCC, the comparison becomes slightly better, at least for microbenchmarks that don't rely too much on libraries.
These benchmarks are still useful from a practical viewpoint - answering the question "what's the expected performance bracket of using language X in real projects today". But it doesn't say anything fundamental about the language design or even the quality of the implementation.
That’s a convoluted way to say that UB is much, much worse than you think. A C program with UB is not a C program, but something else.
Also, modern online gaming with microtransactions isn't something I'd entrust to "hold my beer" languages and gaming industry development practices.
I don't think anyone should develop such games either
Memory safety bugs are very rare in modern, well-written and tested C++. The key difference is that there are no adversarial inputs, while something like a browser or server needs to deal with potentially adversarial inputs, making absolute memory safety much more important (as even a single memory safety issue could be exploited).
They're certainly not inclined to pursue safety at any expense of performance in their code.