Why does D rely on a GC?

[Kagamin via Digitalmars-d]

On Monday, 18 August 2014 at 18:56:42 UTC, b wrote:
>  Not really accurate. First of all, don't include unique_ptr as 
> if it had the same overhead as the other two, it doesn't.

It's still scope guarded, which is not zero cost in sjlj and 
win32 seh exception models. It also injects (inlines?) cleanup 
code everywhere, which wastes cache.

>  With RC you pay a price during creation/deletion/sharing, but 
> not while it is alive.
>  With GC you pay almost no cost during allocation/deletion, but 
> a constant cost while it is alive. You allocate enough objects 
> and the sum cost ant so small.

Quite the contrary: with RC creation and deletion should be 
cheaper because they don't scan whole memory, using the object is 
more expensive, because you need to track it always. With GC you 
pay the cost when collection runs, and it doesn't necessarily 
runs always.

>  Besides that, in C++ it works like this.
>  90% of objects: value types, on stack or embedded into other 
> objects
>  9% of objects: unique types, use unique_ptr, no overhead
>  ~1% of objects: shared, use shared_ptr/weak_ptr etc.

Aren't strings inherently shared? Do you think they account for 
only 1% of objects?

>  With GC you give up deterministic behavior, which is 
> *absolutely* not worth giving up for 1% of objects.

Memory needs deterministic management only under condition of 
memory scarcity, but it's not a common case, and D allows manual 
memory management, but why force it on everyone because only 
someone needs it?