I'd definitely consider it a third option, "garbage collection" to me strongly implies the existence of a "garbage collecter" à la tracing collectors. Reference counting injects reference checks/increments and destructors into the program itself, which means you don't have a separate routine running independently (and nondeterministically) of the main program.

The phrase "garbage collection" has also come to be somewhat associated with tracing's specific characteristics (IMO). Manual memory management is performant and deterministic, but unsafe. Tracing garbage collection is performant and safe, but nondeterministic. Reference counting is deterministic and safe, but not as performant. If you throw Rust into the mix as a fourth option I suppose you could add a "flexible" characteristic.

> Reference counting is deterministic and safe, but not as performant.

Not as performant in a theoretical model with unlimited memory that all costs the same to access. ie it’s not actually faster in practice when peak memory matters and swap exists.

It’s deterministic, doesn’t scan memory, and the program only runs the exact instructions you see in its binary instead of stopping and having some part of the runtime appear from nowhere and change things. So… it’s not garbage collection, it’s a dual to it.

Rust avoids copies and occasionally proves single ownership instead of having RCs. This seems to me to be overoptimization and a waste of programmer time. Copies are fine and you don’t need to prove them away.

RC scans dead memory and changes things, and the GC would appear in a binary. But it is indeed a dual <https://dl.acm.org/doi/10.1145/1035292.1028982>