Why many programmers don't like GC?

[Ola Fosheim Grøstad]

On Friday, 15 January 2021 at 07:35:00 UTC, H. S. Teoh wrote:
> To be fair, the GC *has* improved over the years.  Just not as 
> quickly as people would like, but it *has* improved.

It cannot improve enough as a global collector without write 
barriers. No language has been able to do this. Therefore, D 
cannot do it.

Precise collection only helps when you have few pointers to trace.


> improvement. But why would I?  It takes 5x less effort to write 
> GC code, and requires only a couple more days of effort to fix

That's like saying it takes 5x more time to write code in Swift 
than D. That is not at all reasonable.

Tracing GC is primarily useful when you have many small 
long-lived objects with unclear ownership and cyclic references 
that are difficult to break with weak pointers.

In those cases it is invaluable, but most well-designed programs 
have more tree-like structures and clear ownership.


> after that to debug obscure pointer bugs.  Life is too short to 
> be squandered chasing down the 1000th double-free and the 
> 20,000th dangling pointer in my life.

That has nothing to do with a tracing GC... Cyclic references is 
the only significant problem a tracing GC addresses compared to 
other solutions.


> A lot of naysayers keep repeating GC performance issues as if 
> it's a black-and-white, all-or-nothing question.  It's not.  
> You *can* write high-performance programs even with D's 
> supposedly lousy GC -- just profile the darned thing, and

There are primarily two main problems, and they are not 
throughput, they are:

1. LATENCY: stopping the world will never be acceptable in 
interactive applications of some size, it is only acceptable in 
batch programs. In fact, even incremental collectors can cause a 
sluggish experience!

2. MEMORY CONSUMPTION: doing fewer collection cycles will 
increase the memory footprint. Ideally the collector would run 
all the time. In the cloud you pay for memory, so you want to 
keep memory consumption to a fixed level that you never exceed.


System level programming is primarily valuable for interactive 
applications, OS level programming, or embedded. So, no, it is 
not snobbish to not want a sluggish GC. Most other tasks are 
better done in high level languages.