Why many programmers don't like GC?

[H. S. Teoh]

On Wed, Jan 13, 2021 at 06:58:56PM +0000, Marcone via Digitalmars-d-learn wrote:
> I've always heard programmers complain about Garbage Collector GC. But
> I never understood why they complain. What's bad about GC?

It's not merely a technical issue, but also a historical and
sociological one.  The perception of many people, esp. those with C/C++
background, is heavily colored by the GC shipped with early versions of
Java, which was stop-the-world, inefficient, and associated with random
GUI freezes and jerky animations.  This initial bad impression continues
to persist today esp. among the C/C++ crowd, despite GC technology
having made great advances since those early Java days.

Aside from skewed impressions, there's still these potential concerns
with the GC:

(1) Stop-the-world GC pauses (no longer a problem with modern
generational collectors, but still applies to D's GC);

(2) Non-deterministic destruction of objects (D's dtors are not even
guaranteed to run if it's a GC'd object) -- you cannot predict when an
object will be collected;

(3) GC generally needs more memory than the equivalent manual memory
management system.

(1) and (2) can be mitigated in D in various ways, e.g., prefer structs
over classes to reduce GC load, use GC.stop, GC.collect to control when
collections happen, etc.. Use RAII structs or scope guards for things
that need deterministic destruction. (Or use malloc/free yourself.) (3)
is generally not a big problem unless you're targeting low-memory
devices, in which case you already have to do many things manually
anyway, so you generally won't be relying on the GC in the first place.

There's also the matter of ROI: it's *much* easier, and faster, to write
GC code than code with manual memory management.  For 90% of software,
none of the above concerns matter anyway, and you're just wasting your
time/energy for essentially no benefit (and lots of disadvantages, like
wasting time/energy debugging hard-to-trace pointer bugs and subtle
memory corruptions).  GC code also tends to be cleaner: your APIs don't
have to be polluted with memory-management paraphrenalia that tend to
percolate all over your code and make it hard to read and harder to
maintain.  You get to focus your mental resources on making actual
progress in your problem domain instead of grappling with memory
management issues at every turn.  And most of the time, it's Good
Enough(tm); the customer won't even notice a difference.  The price of
using a GC is far dwarved by the benefits it brings.

Without a GC you're pouring down blood and sweat just to make a little
progress in your problem domain, and the whole time you're plagued with
pointer bugs, memory corruptions, and all sorts of lovely issues that
come with just one tiny mistake in your code but takes hours, days, or
even months to fix. And your code will be convoluted, your API's ugly,
fragile, and hard to maintain. The ROI simply makes no sense, except for
very narrow niches like hard real-time software (where a patient may die
if you get an unexpected GC pause while controlling a radiation
treatment device) and game engine cores.


But there is no convincing a hard-core GC hater sometimes. You do so at
your own risk. :-D


T

-- 
Life begins when you can spend your spare time programming instead of watching television. -- Cal Keegan