D on quora ...

[Jonathan M Davis]

On Friday, October 06, 2017 17:14:51 Rion via Digitalmars-d wrote:
> https://www.quora.com/What-is-your-review-of-D-programming-language
>
> It seems that D still has the GC being mentioned up to today.
>
> Maybe its better to move the standard library slower to a non gc
> version in the future...

D's GC isn't going anywhere. The implementation may be improved or replaced,
but there are huge advantages to having the GC (particularly with regards to
memory safety), and there _are_ actually times when using a GC is faster
than something like reference counting.

We don't want D's standard library to rely on the GC when it doesn't need
to, but there are language features that require it and really couldn't work
with it, and there are cases where it's going to be involved by default for
@safety reasons. For someone who wants to avoid the GC or minimize its use,
there are things that they will need to do (e.g. you have to be careful with
lambdas and probably use functors or functions, because closures are
frequently needed when dealing with lambdas, and that means using the GC;
@nogc will catch those cases for you so that you know when a lambda isn't
going to work). But while it should be possible for someone to avoid the GC
if they need to, that does not mean that we're looking to get rid of it or
even have not using it be the default. It just means that we don't want to
force its use where that doesn't make sense.

Honestly, I would _hate_ to use D without a GC. Without it, @safe memory
managament would not be possible, and you'd have to valgrind everything. As
it stands, you only have to do that when you have sections of @trusted code
that would potentially be a problem. And there's a lot of code that's
cleaner for not having to worry about managing memory.

That's not to say that using the GC is always better or that other solutions
are not more appropriate for some circumstances - and the fact that D gives
you control over a lot of that is fantastic - but this idea that GCs are
always nothing but bad and should be avoided by the plague is just nonsense.
GCs have their pros and cons, but they can be fantastic, and idiomatic D
programs actually mitigate a lot of the downsides that you can get with a
GC, because they do so much with the stack rather than the heap (which is
generally better performance-wise regardless of how heap allocations are
managed).

Yes, we could use a better GC, but overall, the GC is really just a PR
problem and not a real one. Most programs can use it and be plenty
performant. And those that can't have the tools necessary to minimize its
use or even outright avoid it (though honestly, if someone is looking to
outright avoid it, I'd lean towards wondering what the point of using D was
in the first place; the proponents of the -betterc stuff still think that
it's worth it though). Plenty of folks have managed to write performant
programs that involve D's GC.

- Jonathan M Davis