About D and a gratitude

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Mar 9 00:07:41 UTC 2019


On Fri, Mar 08, 2019 at 06:21:51PM +0000, Ecstatic Coder via Digitalmars-d wrote:
> On Saturday, 2 March 2019 at 13:11:17 UTC, Matheus wrote:
[...]
> > One thing that I liked at first was the fact that It has a built-in
> > GC.  While I see some people bashing it. I never had big problems
> > even when writing games.
> 
> I think that those who bash D's GC are mostly those who would like to
> use D as an alternative to C and C++, while in those very few cases
> where C and C++ still remain the most obvious solutions, like
> OS/embedded/game-engine development, only the lack of a GC can
> **completely** remove the **risk** of a GC application freeze.
> 
> But for those who like me use D only as an alternative to scripting
> languages like Python, Ruby, Perl, etc, D's GC has never been a
> problem, but a blessing.

I come mostly from the C/C++ camp, and while I do sometimes write short
utilities in D that could be done with a Perl (or other scripting
language) script, my main focus is C/C++-style applications.  Yet I find
the GC to be a big blessing, rather than the curse some people seem to
think it is.  It has significantly improved my productivity, eliminated
an entire class of bugs, improved my APIs, improved the kind of
algorithms I could write (by not making every non-trivial algorithm a
monumental exercise in tight-rope balancing between memory management,
algorithmic needs, more memory management, resource usage, memory
management, and yet more memory management, that's the staple of C/C++
code of equivalent functionality), and given me the ability to focus on
and make progress in the problem domain rather than micro-managing
memory every other minute of writing code.

Even with the suboptimal GC that D has today, performance has rarely
been a major problem.  When it becomes a problem, there are ways of
mitigating it that doesn't involve rewriting entire APIs -- the kind of
thing you end up doing in C/C++ when you need to change how you manage
memory -- because memory management in C/C++ permeates every aspect of
your code, and it's almost impossible not to think about memory
management every other minute you write code, and it's practically
impossible not to have memory management considerations clutter all over
your APIs even if the code logically speaking has nothing to do with
memory management. It gets into your face, into your hair, and under
your skin, and even if you're a hero-cowboy coder who can navigate this
complex mess all it takes is ONE slip-up, and you have a memory leak,
segfault, or security hole in your hands. So much effort is spent on
memory management when writing C/C++ code, yet it all comes crashing
down like a tower of cards at the slightest provocation. It's totally
incommensurate, esp. if you're trying to make progress in the lousy
problem domain rather than babysitting memory management issues all day
long.

Give me a GC any day, seriously.

And if you ever need to, malloc/free is just a function call away in D,
for those times when you actually *need* to take hold of the reins.
(Unlike Java that coddles you so much it won't allow you to reach under
the hood for malloc, even when it becomes a necessity.)  There's a time
and place for this, but in general, I say gimme the GC so that I don't
have to debug memory leakage in a linked-list for the 1000th time in my
career, or track down an obscure untraceable dangling pointer bug for
the 500th time in my lifetime that's far too short to squander on such
needless annoyances.


[...]
> So I'm also happy to have the opportunity to use D for almost all my file
> scripting needs, as in this domain I can assure you that D is by far one of
> the best alternative out there :)

For me, D straddles that delicate (and very difficult!) balance between
being powerful enough for complex, large-scale applications, performant
enough for intensive computations, and simple enough to meet any one-off
scripting needs that might arise.  Most languages can only handle one of
the above; a few can handle two.  But I've yet to find one that can
master all three like D does.  These days I'm finding less and less need
for scripting languages and what-not.  D trumps them all, and comes with
the bonus that should that "one-off script" evolve into something more
than just a script, the code just fits itself into a more structured,
larger-scale design naturally.  I never have to worry about "rewriting
that hackish Perl script into a better-designed C++ program"; I just
write the script in D and then it becomes a full-fledged program as time
goes.  Marvelous.


T

-- 
Computers aren't intelligent; they only think they are.


More information about the Digitalmars-d mailing list