I would just like to politely argue that reference counting cannot be considered a form of garbage collection, at all. The discriminating factor is that in a GC world there is, well to put it bluntly, a garbage collector. A garbage collector is a basically a process itself which determines reachability of objects/memory and reclaims that memory if it can determine it is no longer in use. In manual reference counting (ARC also), there is not necessarily such a process. In Objective-C, as soon as an object's reference count gets to zero it's memory is immediately deallocated. There is no process which searches and marks an object's memory to be reclaimed. It would be like calling any other type of manual programatic memory management garbage collection because the programmer handled the garbage. Now, reference counting in Python may use a garbage collector to clean up zero count references, but they are mutually exclusive, IMHO.

> A garbage collector is a basically a process itself which determines reachability of objects/memory and reclaims that memory if it can determine it is no longer in use

That's a very.... narrow definition, to say the least. I've never seen this outside of the objective-c world. In my mind, garbage collection is automatic memory management, of which objective-c provides an arguably better solution than imprecise collectors. To distinguish between them at all strikes me as pedantic and counterproductive.

Anyway, the only real difference between python and objective-c is that yes, python has a garbage collection routine that bulk frees objects with refcounts of 0... functionality conveniently provided by @autorelease. This would make ARC a superset of python's GC.

I'm not here to argue, other than intellectual arguments... You call my definition narrow. Not sure why. Can you describe what a GC does in a single sentence? I'm just going for a simple description. It also doesn't matter if you haven't seen this outside of Obj-C. I am almost lost at the point that is being made. ARC is in no way, at all, a garbage collection technology. @autoreleasepool is in no way a garbage collection concept. All it does is provide a scope for the compiler to inject a 'release' call on all the instances in the block that were sent the autorelease message in said block.

ARC is purely a compile time feature. And an awesome one at that. There is no ARC runtime process/thread. There is no ARC memory manager.

Anyway. Feel free to respond. I have said all I am going to.

On another note, is there any way to be informed/notified that someone responded to a post? Or do you have to keep coming back and checking? I feel that I drop out of conversations because I lose track.

Garbage Collection: A system wherein memory is automatically allocated when referenced and freed for another allocation when not referenced.

It sounds like you believe a garbage collection system must achieve a certain level of complexity beyond reference counting, and I can't help with that—however, it's a fairly pointless distinction if we switch from saying "GC" to "GC and reference counting" to talk about automatic memory management. What does that give us? And why WOULDN'T you want this simplicity? I don't much care how trivial you consider ARC to be, it certainly collects garbage effectively. No memory scans to worry about interrupting your real time application. If you really need to not deallocate in a tight loop you can autorelease (I never claimed it was a garbage collection mechanism).

And I am not aware of a way to be notified by HN itself but a lot of apps and sites provide that. (I don't use one myself, I just check threads I am still interested in.)

I'd agree that reference counting is a form of garbage collection; It's what wikipedia says on it's page on reference counting. Maybe I was too hasty in my comment - or not very clear. I do think that benefits are to be had (as far as conveying information efficiently) when using more narrow and precise definitions.

I was also thinking "garbage collector" not "garbage collection". :P

Wait, what? How is ARC more powerful than Python's system? ARC is reference counting. Python is reference counting (with a mark-and-sweep collector that sometimes runs to collect cycles). Python also supports weak references (http://docs.python.org/2/library/weakref.html). What's the difference?

The OP mentioned that Objective-C's memory management is deterministic since it does not use a garbage collector. The major benefit is you know exactly when the memory is reclaimed (at zero references). You cannot determine when this will happen in Python (or any other GC language). That's all. And, there is no GC pause time in Objective-C's runtime so, that's awesome too. Another plus of ARC is that the compiler can place the release calls to your releasable instances closer to where they should be and can keep your memory foot print significantly lower, as code would be a lot harder to write with intertwined release calls in the middle of methods. A lot of people like to write their code in a structured form (like, release at the end of a method instead of 'inline' or 'immediate', I hope that makes sense) rather than high performance, due to readability.

What? Python is ref counted. It releases at the time an object goes out of scope and has no references anymore... exactly like ARC. Although Python says its garbage collection is implementation-defined, in practice pretty much everybody uses CPython which uses refcounting. Where does the idea come from that Python releases at undeterministic time?

> Where does the idea come from that Python releases at undeterministic time?

It's not the time that's undeterministic, it's that the 'deconstructor' may not be called at all if python can't guarantee collecting cyclical references in the right order. The object will still be released/deallocated.

In this sense, Objective-C—mostly because you have complete control over the reference counting—has superior reference counting semantics.

I'd like to note that there's nothing stopping Python from using similar approaches.