I think the advantage of ARC is not the potential for longer pause times but the fact that things are predictable & somewhat easier to debug.

I think it's too bad that the GC/ARC choice also implies a language choice. For e.g. if we had the ability to choose between GC & ARC in Java, we would be able to get a better understanding of which memory model developers of Java enterprise software end up preferring.

There are JVMs with RC,

http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rcix-oops...

Very interesting, thanks for sharing.

Often, the problem with this kind of academic work is that they don't have a real world system to gather data and study different algorithms. I don't really care if javac (one of the application they benchmark) takes 10% more or less time. I want to know how much time engineers save when using ARC vs tracing GC over a long period of time (development + maintenance).

You loose the predictability if you get longer pause-times. Memory leaks can also severely hurt development time when you spend days or weeks chasing down memory leaks (personal experience). You're not immune to memory leaks (space leaks really) in a GC based system, but it's generally easier to reason about where the system is using memory.

In regards to resources, who depends on lifecycles in a GC based system to handle resources? try-with-resources in Java is just as predictable as destructors in C++, with the added benefit of resources being eventually closed in case you forget to close it (wheras a memory leak in C++ will never close said resource)

The "A" in ARC is a bit of an euphemism. You basically move the coding of your memory management into the type signatures, which don't write themselves automatically either. The amout of thoughts you have to make during development is the same.

I thought the A was for atomic, ARC is atomic reference count. RC is non atomic.

My mistake, in rust it is atomic, in objective c it is automatic.