Why does D rely on a GC?

[Jonathan M Davis via Digitalmars-d]

On Mon, 18 Aug 2014 10:01:57 +0000
maik klein via Digitalmars-d <digitalmars-d at puremagic.com> 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?

The biggest reason is memory safety. With a GC, it's possible to make compiler
guarantees about memory safety, whereas with manual memory management, it
isn't. It's also pretty hard to do stuff like automatic closures and delegates
without a GC, and the behavior of D's dynamic arrays - particularly with
regards to slices - is much harder to do without a GC. The result is that
there are a number of features which you lose out on if you don't have D's GC
(though they're not features a language like C++ has, since it doesn't have a
GC).

However, it's also not true that the GC is necessarily always on. You can
disable it. It's just that you do so, you lose out on certain language
features, and memory management becomes a bit harder (particularly when it
comes to constructing classes in malloced memory, but the custom allocators
which are in the works should fix that). However, with the way a typical D
program works, a lot more goes on the stack than happens with a typical
GC language, so the fact that it has a GC wouldn't be as big an impediment as
it is with some other languages, if you couldn't turn it off.

So, having the GC gives us a number of features that aren't really possible
without it, and unlike languages like Java, you _can_ turn it off if you want
to, though you do lose out on some features when you do. So, ultimately, about
all we really lose out on by having the GC is having folks who want a systems
language freaking out about the fact that D has a GC and frequently assume
that that means that they have to it and that D is not performant.

- Jonathan M Davis