As far as I can tell, the impl of Arc and ARC are actually basically identical at the high level, with the only major diff being ARC only keeps 32-bit counts on 64-bit (so they only waste one pointer of space).<p>Everything else is just where retain&#x2F;release (clone&#x2F;drop) calls are made. Rust is insanely good at not frobbing counts because you can safely take internal pointers and move pointers into a function without touching the counts at all. Swift has lots of interesting optimizations to avoid touching the counts, but it&#x27;s hard to compete with a system that has so much great static information related to liveness of pointers and values.<p>As a simple example, consider this code (which is conveniently valid Swift and Rust, modulo snake_vsCamel):<p><pre><code>    let x = make_refcounted_thing();
    foo(x);
</code></pre>
This code in isolation will always not frob counts for Rust. This code <i>may</i> not frob counts in Swift, depending on what follows `foo`. In particular if foo is in tail position (or at least tail-position-for-the-life-of-x), then we can avoid frobbing, because we know foo&#x27;s final operations will be to release its function args. foo may in turn punt releasing its function args to anyone it passes them to as a tail call. Note that Swift and Rust both have the usual caveats that &quot;less is a tail call than you think&quot; thanks to side-effecting destructors.<p>The takeaway is that Rust&#x27;s default semantics encourage releasing your memory earlier, which in turn means less traffic on the reference counts. Particularly interesting is that in Rust, you can run a function arg&#x27;s destructor earlier than the end of the function by moving it in to a local variable. In Swift, I do not think this is possible (but I wouldn&#x27;t be too surprised to be wrong -- Swift has tons of special attributes for these little things).