Maybe D is right about GC after all !

[thedeemon]

On Wednesday, 20 December 2017 at 11:21:59 UTC, Thomas Mader 
wrote:
> What I don't get is why he doesn't believe in good GC for C (my 
> previous post) but at the same time praising Go for it's GC.
> What makes it easier to have a good GC in Go vs. in C?
> I guess the GC in D has the same problems as a GC in C.

A good GC requires the compiler to add special bookkeeping code 
to every pointer mutation in the heap, and to generate special 
data for each function to help GC find all the pointers in its 
stack and closures. Without such help from the compiler you can't 
make anything decent, just a slow half-conservative GC that scans 
whole heap every time and leaks memory being unable to tell 
whether some stack value is a number or a pointer. Go compiler 
includes that special bookkeeping, so the running code is a bit 
slower but GC can be fast, its GC can analyze heap concurrently, 
it can clean it by parts. With C you can't do that. D compiler 
also doesn't insert that bookkeeping code, so running code is 
fast as C but GC is slow and sloppy.