I think this is done at compile time, so it wouldn't be considered garbage collection.

The compiler is LLVM though, "By enabling ARC with the new Apple LLVM compiler", which begins to blur the difference

LLVM is being used as a static compiler. There is no LLVM virtual machine - the compiler emits native machine code.

MacRuby does support AOT compilation, although I don't think it's a very production-ready feature yet and would likely be incompatible with a fair percent of existing ruby code

This isn't in MacRuby — it's in Objective-C. And it's explicitly distinct from garbage collection. This is an alternative to garbage collection that has generally been considered kind of impractical.

(And MacRuby's AOT compilation works pretty well from what I've seen.)

I don't think that makes much difference, as long as it's performed at compile time.

it depends. If it copes with circular references, then yes, it is suffiecient to use for gc.

If not then it's just what COM had.

Unfortunately, it doesn't handle cycles in the object graph[1], which was almost the entire reason I wanted GC. Manually dealing with cycles is one of the worst parts of working with blocks (the other is the lack of parameterized types).

Assuming that ARC works reliably and consistently, it'll be nice to lose some boilerplate, but the worst facet of reference counting -- object graph cycles -- still isn't fixed.

[1] There is support for zeroing weak references, but this is a very manual solution to the cycle problem.

That basically makes it useless. It would be an utter pain in the arse finding leaks in. I don't know why they cant chuck a generational collector in it such as the one in the last ObjC drop in it. Even microsoft with the woefully inadequate WM7 platform has a proper GC.

I wouldn't say useless -- just a lot less useful. Maybe they'll add cycle handling on top of it later.