I almost ignored this post because I can't stand this particular war, where examples are cherry picked to prove either answer.
I'm very happy to see the nuanced take in this article, slowly deconstructing the implicit assumptions proposed by the person asking this question, to arrive at the same conclusion that I long have. I hope this post reaches the right people.
A particular language doesn't have a "speed", a particular implementation may have, and the language may have properties that make it difficult to make a fast implementation (of those specific properties/features) given the constraints of our current computer architectures. Even then, there's usually too many variables to make a generalized statement, and the question often presumes that performance is measured as total cpu time.
We recently had a post here where the claim being refuted was in quotes in the title, but half the comments were as if the article were making the claim, clearly indicating that people didn't read it (and don't understand how quote marks work).
From the other side of the table, I love performance comparisons, so I always read these things. I also enjoyed your commentary, thanks for writing it :)
I agree, I thought this was a weird example - but I'm not a Rust nor C programmer.
I assume this example is used because programmers of either language reach for asm when looking for raw performance. But to me, it's shouldn't even be a discussion point, since even I know both languages can be made to emit the same assembly.
Also, I think it side-steps the hard parts of the question - which is, what are the performance impacts of Rust safety?
>, what are the performance impacts of Rust safety?
None from the aspect of borrow model, since that is all compile time.
For safety at run time, there is a hit if you use certain structures because you can't figure out at compile time what things like dynamic bounds are. But its no different than C with having to do manual bounds checking.
I'm very happy to see the nuanced take in this article, slowly deconstructing the implicit assumptions proposed by the person asking this question, to arrive at the same conclusion that I long have. I hope this post reaches the right people.
A particular language doesn't have a "speed", a particular implementation may have, and the language may have properties that make it difficult to make a fast implementation (of those specific properties/features) given the constraints of our current computer architectures. Even then, there's usually too many variables to make a generalized statement, and the question often presumes that performance is measured as total cpu time.