[esjeon]

Theoretically, C is likely faster than Rust only by an unnoticeably small margin. Still, this is unavoidable because Rust works with abstraction that (1) adds overhead per-se albeit tiny (2) forces overhead in the design level.

Practically, that little margin can be removed thru a series of engineering, as both are proper system-level programming languages, which offer tight control over the generated machine code. That is, this whole discussion is basically pointless if we mix in engineering factors.

We better talk about overall engineering costs, and personally I think Rust would not overshoot C easily, mainly due to the limitations that Rust puts on the higher level designs.

[steveklabnik]

What abstraction do you refer to?

[esjeon]

Rust is actually few steps above from the bare metal, to enforce its security invariants. Boundary checks (which breaks auto-vectorization of loops), stack probe, fat pointer (wastes register), fixed index type (uint), etc.

There are other hidden costs coming from usage of std. Even `Result` is a bit of inefficiency.

I'm not saying any of these are bad. I'm just saying Rust would be slower than C if *naively* used.

[steveklabnik]

Okay, cool, I can see where you're going with this. I wouldn't exactly agree, because all of these things are stuff you can easily opt out of, but I thought you were maybe suggesting something like "the borrow checker has overhead" which I would take more direct issue with.

(and yeah, the opt out question gets right to what you're saying about "naively used", I saw "unavoidable" but you're not actually saying it's unavoidable.)