* Not having to worry about trivial memory/resource allocations
ARC - Lifetimes:
* Can blow up hilariously with refcount cycles
* Incurs a runtime overhead
Lifetimes - ARC:
* For the subset of allocation patterns it handles, it does so with zero runtime overhead (i.e. invalid programs do not compile, invalid = leaks memory)
* Use extends beyond just memory allocation/deallocation (see the concurrency docs [1] for example) (note that Mozilla wrote Rust to help write Servo [2], their prototype highly-parallel browser engine, so this use case was a target from the getgo)
* Cannot encode all data structures a GC can (hence why reference counting is part of the stdlib [3])
Not quite true- invalid use of lifetimes typically means use-after-free rather than a memory leak (and if you include the standard library, then you can leak memory in safe Rust).
Its interesting to me how everyone goes to "memory leaks" as their example of memory unsafety, and then if we're talking about Rust we need to clarify that Rust allows leaks (but it makes them hard to do by accident). I guess mnemonically "memory leak" is easier to bring to mind than "dangling pointer" when talking about memory.
* Not having to worry about trivial memory/resource allocations
ARC - Lifetimes:
* Can blow up hilariously with refcount cycles
* Incurs a runtime overhead
Lifetimes - ARC:
* For the subset of allocation patterns it handles, it does so with zero runtime overhead (i.e. invalid programs do not compile, invalid = leaks memory)
* Use extends beyond just memory allocation/deallocation (see the concurrency docs [1] for example) (note that Mozilla wrote Rust to help write Servo [2], their prototype highly-parallel browser engine, so this use case was a target from the getgo)
* Cannot encode all data structures a GC can (hence why reference counting is part of the stdlib [3])
[1]: https://doc.rust-lang.org/book/concurrency.html
[2]: https://github.com/servo/servo
[3]: https://doc.rust-lang.org/alloc/rc/