What's the go with the GC these days?

[H. S. Teoh]

On Mon, Jan 07, 2019 at 05:18:49PM +0000, JN via Digitalmars-d wrote:
[...]
> I think for many people (especially C++ folks which seem to be the
> main target of D leadership) the mere existence of GC is enough to
> turn them off.

Yep. GC phobia is a common malady among C/C++ folks (I used to be one of
them).  I wrote D off the first time I found it because I was suffering
from a particularly acute case of GC phobia, mostly colored by the bad
impressions of the early versions of Java.

It took me a while to come around.  Reading this helped a little:

	https://dlang.org/spec/garbage.html

but it didn't convince me, only made me cautiously willing to at least
try out D a little to see for myself.  I think I wasn't even willing to
try D until I read that I could optionally still use malloc/free if I
really wanted to, or if the GC turned out to be a problem.  Clutching
onto that option was an important crutch for my initial foray into D.

It wasn't until I actually wrote code that let the GC do its job, that I
was finally able to see, in retrospect, just how much time I wasted
basically reimplementing my own version of GC (manually, and rather
poorly!) and debugging the associated tricky pointer code -- all of
which was unnecessary when there's a GC.

Furthermore, having a GC enabled a cleanness in my internal APIs that
manually-managed memory did not allow -- it eliminated memory management
from being an integral aspect of my APIs and freed up the design space
(and my mental concentration!) to actually focus on the problem domain
instead of being bogged down with memory management details.

The result was:

(1) my code quality was better from having eliminated an entire class of
pointer bugs and from my being able to focus more on the problem domain
rather than fiddle with memory management at every turn; and

(2) it had better API that directly addressed the problem domain,
uncluttered by dirty memory management specifics;

(3) I could achieve the above in a much shorter time (and with much less
effort) than without the GC, since I eliminated the big time sink of
manual memory management.

This was a clear win for me.  So eventually I convinced myself. :-P


The other important thing I had to get over was the oft-cited
performance concerns -- which in my case (and I surmise in the case of
many others in the C/C++ camp) was colored by the bad impressions of
early versions of Java.  It took me a while to convince myself that the
chains of `delete`s in the C++ dtor of a large recursive structure
basically was tantamount to a GC pause, just scheduled differently.
Well, OK, it's not *exactly* the same thing, but it dispelled the wrong
notion that malloc/free (or C++ new/delete) came "for free".  You still
have to do roughly the same amount of "work" or bookkeeping either way.

Of course, the cost of a GC collection is likely more than manually
freeing stuff, depending on the situation; but there's the tradeoff of
spending easily 3x to 4x more effort in writing correct pointer code
under manual MM and *still* running the risk of pointer bugs (with the
associated debugging effort required to fix them -- and pointer bugs are
notorious for being hard to debug), vs. paying for a (usually) small
performance cost and being much more productive, with the benefit of
eliminating a whole class of pointer bugs "for free".


T

-- 
Study gravitation, it's a field with a lot of potential.