"faster than C" almost always boils down to different designs, implementations, algorithms, etc.
Perhaps it is faster than already-existing implementations, sure, but not "faster than C", and it is odd to make such claims.
replies(10):
Perhaps it is faster than already-existing implementations, sure, but not "faster than C", and it is odd to make such claims.
For example, he says they didn’t set out to improve the code, but they were porting decennia-old C code to rust. Given the subject (truetype font parsing and rendering), my guess would be that the original code had more memory copies copying data out of the font data because rust makes it easier to safely avoid that (in which case the conclusion would be “C could be as fast, but with a lot more effort”), but it could also be that they spent a day figuring out some code did to realize that it wasn’t necessary on anything after Windows 95, and stripped it out, rather than porting it.
Yes, if your code in Lang-X is faster than C, it's almost certainly a skill issue somewhere in the C implementation.
However, in the day-to-day, if I can make my code run faster in Lang-X than C, especially if I'm using Lang-X for only a couple of months and C potentially for decades, that is absolutely meaningful. Sure, we can make the C code just as fast, but it's not viable to spend that much time and expertise on every small issue.
Outside of "which lang is better" discussions on online forums, it doesn't matter how fast you can theoretically make your program, it matters how fast you actually make it with the constraints your business have (time usually).
I'm always reminded of this video, where the author writes the same program in Rust and Go.
https://www.youtube.com/watch?v=Z0GX2mTUtfo
> Now, the Rust version took me about five times as long as the Go version
> The Go one performed almost identically well
Now this was for netcode rather than number crunching. But I actually had a similar surprise with number crunching, with C# and C++. I wrote the same program (rational approximation of Pi), line for line, in both languages, and the C# version ran faster. Apparently C# aggressively optimizes hot code paths while running, whereas to get that behavior in C++, you need to collect profiler data and use a special compiler flag.