> Often safety and performance are characterized as a set of zero sum tradeoffs, yet often it's possible to find better tradeoffs who's holistic properties improve upon a previously seen "either or".<p>There is truth in this, but I'm not sure whether the reader can/should extrapolate this to larger situations (not that the author implied we should, but it was my first interpretation).<p>We know that in certain situations, borrow checking works really well and allows us to guarantee safety with minimal friction and no overhead.<p>But there are other cases where safety and performance _are_ in contention, and we must choose one or the other. Anyone who has been forced to satisfy the borrow checker by using a .clone(), using Rc, or refactoring objects into a hash map and referred to them by an ID (that must be hashed to exchange with a reference), has felt this contention. In <a href="https://verdagon.dev/blog/myth-zero-overhead-memory-safety" rel="nofollow noreferrer">https://verdagon.dev/blog/myth-zero-overhead-memory-safety</a>, I concluded that there's no general approach that always has zero overhead, at least not yet.<p>So perhaps the best interpretation from this study is that often, for small enough programs/areas, there is no conflict between safety and performance.<p>For larger programs with more complex requirements and data interrelationships, the question becomes much more interesting.<p>> I see no reason why a straight port from Rust to C++ wouldn't have been possible while satisfying their requirements.<p>Like the author, I also don't see a reason for this, but I've never tried myself. I've always thought that with the restrict keyword, one could make any C++ as performant as any Rust code. Perhaps something else got in the way there.