Why many programmers don't like GC?

[Ola Fosheim Grøstad]

On Friday, 15 January 2021 at 18:43:44 UTC, Guillaume Piolat 
wrote:
> Calling collect() isn't very good, it's way better to ensure 
> the GC heap is relatively small, hence easy to traverse.
> You can use -gc=profile for this (noting that things that can't 
> contain pointer, such as ubyte[], scan way faster than void[])

Ok, so what you basically say is that the number of pointers to 
trace was small, and perhaps also the render thread was not under 
GC control?

>> I think it is better with something simpler like saying one GC 
>> per thread
>
> But then ownership doesn't cross threads, so it can be tricky 
> to keep object alive when they cross threads. I think that was 
> a problem in Nim.

What I have proposed before is to pin down objects with a ref 
count when you temporarily hand them to other threads. Then the 
other thread will handle it with a smart_pointer which release 
the "borrow ref count" on return.

But yes, you "need" some way for other threads to borrow thread 
local memory, in order to implement async services etc.  Then 
again, I think people who write such service frameworks will be 
more advanced programmers than those that use them. So I wouldn't 
say it is a big downside.

> But sometimes that ownership is just not interesting. If you 
> are writing a hello world program, no one cares who "hello 
> world" string belongs to. So the GC is that global owner.

I get your viewpoint, but simple types like strings can be 
handled equally well with RC... If we take the view, that you 
also stressed, that it is desirable to keep the tracable pointer 
count down, then maybe making only class object GC is the better 
approach.