Why does D rely on a GC?

[Paulo Pinto via Digitalmars-d]

On Monday, 18 August 2014 at 10:01:59 UTC, maik klein wrote:
> First of all I don't want to insult anyone on language design, 
> I just want to know the reason behind the "always on" GC.
> I know that the GC as several advantages over reference 
> counting, especially when it comes to immutable data structures.
> What I don't (correct me if i am wrong) understand is why every 
> heap allocation has to be garbage collected, like classes, 
> dynamic arrays etc.
> Does a GC still have advantages over heap allocations that do 
> not need to be reference counted such as the unique_ptr in c++?
> The dlang homepage stats:
>
> Destructors are used to deallocate resources acquired by an 
> object. For most classes, this resource is allocated memory. 
> With garbage collection, most destructors then become empty and 
> can be discarded entirely.
>
> If I understand it correctly it means that D has a GC, so most 
> classes don't need a destructor anymore because they don't need 
> to do any cleanup. I am not totally convinced that this would 
> be a good trade off in general. Maybe someone could shine some 
> light on this statement?

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.

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.

RC also has performance impact when deleting big data structures. 
You can optimize this away big using asynchronous deletion, but 
eventually you are just doing GC with another name.

As for feasibility of a GC in a systems programming language, 
just think the Mesa/Cedar environment at Xerox PARC was a system 
programming language using reference counting with a GC for 
collecting cycles.

--
Paulo