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.
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.
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.)