On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
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
To really compete with C++ on the same grounds, D needs a no-GC
standard library, which would behave as close as possible as the
GC-based standard library.
Reference-counting is used a lot in C++ game development, for
resource management.
In C++, using just strong and weak pointer classes for arrays,
strings and slices, you can develop programs which look like
garbage collected code.
