> It has shown that GC vs manual memory management has a third option.

Objective-C has only existed a few decades now.

Replies to my comment are questioning whether that was really a third or third-and-a-halfth option, but my point was that previously mainstream languages offered either memory managed by a run-time with an overhead (this includes ARC), or depended on diligence of the programmer to work correctly (Rust has copied C++ move semantics, but made moves automatic and checked).

Rust's ownership + borrowing instead of being somewhere on the axis of performance vs correctness trade-off, has traded off generality/flexibility instead (infamous for being unfit for doubly-linked lists). Unlike ARC, it works without a run-time, and on bare allocations and stack objects too. Unlike C++, it has zero-cost slices/substrings without a risk of dangling pointers.

Note: Some people consider reference counting to be a form of garbage collection.

AFAIK Objective-C has lots of reference counting.

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>

> It has shown that GC vs manual memory management has a third option.

C++ had shown this long before Rust.

C++, despite RAII, is still manual memory management IMO

How is memory management with Vec and Box in Rust any different from std::vector and std::unique_ptr in C++?

They aren't :)

The main thing I guess is dealing with C APIs in C++. You do have to use C APIs in Rust as well though, but maybe dealing directly with plain C APIs is less common because of how annoying it is. The only way to avoid that pain is to make a Wrapper library that exposes a more idiomatic and possibly "safe" interface. C++ can wrap C APIs just as well though.

I agree with you though, C++ has been doing RAII for a while and I'm not sure why people seem to think Rust invented it. Idiomatic C++ APIs and code are just as "automatic" as Rust for the most part!

C++ doesn't have the borrow checker of Rust. Isn't that what made Rust famous?

(Your literal question is a straw man: no, those aren't different, but Rust offers more.)

I don’t really understand what the borrow checker has to do with the automatic/manual memory management dichotomy.

Even though ownership and borrowing are theoretically orthogonal, they're both needed to make a complete safe system (the context was about managing memory for safety, not merely having a syntax sugar for malloc/free.)

Unique ownership prevents leaks and double-free, and borrow checking prevents use-after-free. Borrowing is necessary to temporarily relax the exclusivity of uniquely-owned objects and access their interior. Access to interior of a unique_ptr (and shared_ptr) decays it to a reference or a bare pointer that is not managed by the smart pointer any more, and can be left dangling. Borrow checker eliminates the manual "be careful not to leave dangling pointers" part.

Problem with rust is unlike C you pay for that safety every time you compile.