3 ms·

I didn't claim that rust would be faster than C (not that it can't be) in that situation. I would expect very similar performance. I'm not feeling very well un

• lacampbell 10y ago
  I just keep hearing about how rust handles safe bounds checked arrays with (and I quote) "Zero-cost abstractions", which to me implied it would be faster than C, since C pays some performance penalty by branching. Hope you feel better soon.
  • wmf 10y ago
    "Zero-cost abstraction" really means zero additional cost beyond what is required. So Rust still pays a cost for bounds checking, but it's the same cost as if you optimally hand-coded the bounds check in C.
    • pekk 10y ago
      Adding the cost of bounds checking is not actually "zero cost" relative to a C default of not bounds checking. There's really no reason to speak in this misleading way except marketing. Of course, bounds checking is worth paying a cost! As are many other common foot-guns like remembering to free memory. Which starts to raise the issue of when it would actually be necessary to reach for Rust instead of (arbitrary example) Java. Because a language with enforced bounds checking is not really the same kind of thing as C, and we've already had languages that are safer than C for decades.
  • staticassertion 10y ago
    Ah, I see. For what it's worth C will perform similar optimizations to Rust, which is why I expect similar performance. And thank you.
  • Manishearth 10y ago
    "Zero cost abstraction" means that the abstraction doesn't impose an additional cost. It is the same cost of branching that C will have, modulo optimizations. (Languages with dependent types can help move bounds checks to compile time, but Rust does not have those)