Someone else has made this point below, but I'm not sure where this misunderstanding comes from. Reference counting is a form of garbage collection.

My copy of Jones and Lins "Garbage Collection" textbook includes Reference Counting as its first item its "classical algorithms" chapter.

It's usually non-tracing, but variants that can cycle collect will even do some limited tracing to resolve cycles.

And the original comment about latency still stands, even for RC. A single de-reference can lead to a whole series of collections, taking an unknown amount of time, and thrashing cache in the process. A deep tree of objects deleted at the top creates a cascade of de-references. And modern high level languages tend to encourage deep object trees.

When doing realtime programming, I avoid anything with GC. Out of experience. Yes it is possible to tune GC for realtime performance -- but it's fiddly, and never perfect. There are systems tuned for incremental realtime collection -- but there is a cost to this.

As software engineers our job is to pick the right tool for the job. I had many years usually almost exclusively garbage collected languages (including Objective C) before ending up where I am now (I work mainly in C++ lower down the stack)

Manual memory management still exists for a reason.

I'm sure I sound like a broken record but Rust has solved the problem of memory safety lower in the stack pretty well with the borrow checker. There is almost no reason to use unsafe code aside from interop.

Sure, I'd be into it, if someone would pay me to work in Rust. That hasn't happened for me yet.

But there is a cognitive overhead cost to working with Rust. Or even just following consistent RAII patterns in C++. It doesn't come for free.

Trade-offs.

Yep. ‘Tis true. I keep telling Rust people that I could do with less syntactic overhead and that sometimes I just want GC, but I don’t think it’s a priority for the community and they already have a lot on their plate and it does basically everything else right, imo.

Ignoring the problem with calling something a “GC-based” language, Objective-C is most typically used with ARC these days, which is definitely GC.

Reference counting is still not garbage collection. ARC causes the compiler to implicitly insert calls to retain and release, that’s it. Everything is still 100% deterministic at runtime.

Reference counting is a form of garbage collection [1]. Any automatic memory management is garbage collection. There is in fact a continuum of memory management strategies between full reference counting on one end and full stop-the-world mark/sweep on the other.

Malloc heuristics also mean that it is not true that everything is 100% deterministic at runtime. It's easy to forget that malloc is simply an abstraction like any other. When do free memory blocks get reshuffled between threads in a thread-caching malloc? When does unused memory get returned to the OS? These are all things that cannot be predicted. Even retain and release are not 100% deterministic, as they can and will be optimized away by the compiler.

[1]: https://www.memorymanagement.org/glossary/g.html#term-garbag...

reference counting is reference counting.

a reference counting gc is a form of garbage collection.

not sure what applies here, as am not versed in objc, but, the terms are distinct - in theory one can have an object system that refcounts objects so that they are not mis-deleted if some reference still exists and the object is accidentally deleted by some code, but still allow for mostly-manual memory management.

We're discussing ARC here, i.e. Automatic Reference Counting, which is a garbage collection algorithm. Retain/release would be manual memory management by reference counting, which is not being discussed.

Even without ARC it's still garbage collection. The reference counts are kept for the purpose of managing garbage collection. That the programmer has to do some manual retain/release steps is beside the point, even if it does make the experience somewhat painful.

It's not deterministic because you don't know the timing relationship between threads which may drop references. The only sense in which it is deterministic is that "when the reference count reaches zero, the object will be destroyed". That's a long way from the determinism of manual/explicit memory management. It gets even worse if there are per-thread pools in use, though to be fair, this is mostly an application design issue rather than a language one.

It’s not tracing GC, but it’s well-known as a garbage collection algorithm: https://en.wikipedia.org/wiki/Reference_counting#Garbage_col...