On Friday, 6 October 2017 at 21:12:58 UTC, Rion wrote:
On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis
wrote:
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
The issue is only mentioned, because it keeps getting talked
about ( mostly one sided ) on forums and sites like the above
mentioned quora.com. Its hard to change people there
perception, without counter arguing. Currently as i write this,
these claims on quora are unchallenged.
I can make a few simple demos and have D use by default 5 to 10
more memory then the exact same C or C++ program. While D does
not actually use it ( its only marked as allocated for the GC
), it does not dispel the notion or feeling of people that a GC
= bad.
Other aspects like being unsure when the GC will trigger can
also influence people to a non-gc language. The Go developers
have done a massive ( an impressive ) amount of work on trying
to reduce GC pauses in the last two years, and that
communication and effort has helped to reduce the GC myth ( for
people looking at Go ).
Another part of the issue is, while D can be run without the
GC, i can not tell what parts of the standard library can work
without the GC. Even a simple output parsing gave me a compile
error when running nogc a while ago.
When every new languages besides Rust or Zig are GC. That same
"flaw" is not looked upon as a issue. It seems that D simply
carries this GC stigma because the people mentioning are C++
developers, the same people D targets as a potential user base.
D can have more success in targeting people from scripting
languages like PHP, Ruby, Python, where the GC is not looked
upon as a negative. The same effect can be seen in Go its
popularity with drawing developers from scripting languages
despite it not being there intention.
I always felt that D position itself as a higher language and
in turn scares people away while at the same time the people it
wants to attracts, with most are already set in there ways and
looking at excuses to discredit D. The whole C++ has all of D
features and does not need a GC / GC is bad excuse we see in
the quora.com posting fits that description ( and not only
there, also on other sites ).
If the GC issue can not be tackled and even with the recent
communication blogs, it still keeps showing up. Is it maybe not
better to focus the marketing features that other developers (
none C++ ) may see as advantages and slow draw then in? High
performance web development package for instance. Vibe.d does
not count because has not been seen giving any descent public
performance in years ( like techempower or other sites ).
+1
But you are losing your time trying to convince D's management
that targeting C++ developers instead of scripters is a marketing
error.
For instance, I AM a C++ developer, and I use D EXCLUSIVELY for
SCRIPTING tasks. Nothing else.
And if you had asked me why I use D then, I would have answered :
it's because it's faster and more effective than
JavaScript/Node.js, Python and Ruby for these tasks.
GC IS NOT A PROBLEM for scripting. We don't care about that. GC
IS NEEDED for scripting languages.
But as a C++ developer, I can tell you that : D's GC is what
prevents me to use it for my current C++ programming tasks.
Because I can perfectly live with a GC that progressively
collects bits of memory in a predefined amount of time, like in
the Nim language, but not one that can pause my application for
an unpredictable amount of time.
That's just my personal case and opinion, but I don't think I'm
the only C++ programmer on the planet to dislike D's GC for
typical C++ development cases, which are generally those where
the lack of a GC is the reason that lead to the use of C++.
