Why does D rely on a GC?

[b via Digitalmars-d]

> A good reason is the ability to write lock-free algorithms, 
> which are very hard to implement without GC support. This is 
> the main reason why C++11 has a GC API and Herb Sutter will be 
> discussing about GC in C++ at CppCon.

  *some* lock free algorithms benefit from GC, there is still 
plenty you can do without GC, just look at TBB.

> Reference counting is only a win over GC with compiler support 
> for reducing increment/decrement operations via dataflow 
> analysis.
>
> C++ programs with heavy use of unique_ptr/shared_ptr/weak_ptr 
> are slower than other languages with GC support, because those 
> classes are plain library types without compiler support. Of 
> course, compiler vendors can have blessed library types, but 
> the standard does not require it.

  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.

  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.

  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.

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

  I think most people simply haven't worked in an environment that 
supports unique/linear types. So everyone assumes that you need a 
GC. Rust is showing that this is nonsense, as C++ has already 
done for people using C++11.