Mac Apps That Use Garbage Collection Must Move to ARC

[via Digitalmars-d]

On Monday, 23 February 2015 at 07:19:56 UTC, Paulo Pinto wrote:
> Personally I think what matters is getting D's situation 
> regarding memory management sorted out, regardless out it will 
> look like in the end.

This is exactly right, either

1.  The compiler takes care of allocation/deallocations and makes 
refcounting part of the language implementation (but not 
necessarily the semantics).

or

2. If allocation/deallocation is not the compiler's 
responsibility then RC should be a library solution based on 
efficient generally useful counter-semantics build blocks.

A compiler solution for RC and manual allocations is a 
firefighter solution where all similar use cases suffers. I.e. 
when you want something similar to, but not exactly like what the 
compiler provides...

> If I am a bit too quick jumping the gun about GC, is that I 
> have embraced GC languages in my line of work, so I tend to be 
> aware that not all GCs are made alike and some like the ones 
> from e.g. Aonix are good enough for real time situations, the 
> ones someone dies if the GC runs on the wrong moment.
>
> Maybe such GC quality is impossible to achieve in D, I don't 
> know.

Well, hard real time does not mean fast, it means "bounded 
execution time". GC will is not suitable for a lot of reasons 
when you want to get the most out of the hardware (just memory 
requirements on diskless systems is sufficient to disqualify GC). 
When people use the term "real time" on the forums, they usually 
just mean hardware-efficient and low latency.