Maybe D is right about GC after all !

[Thomas Mader]

On Thursday, 21 December 2017 at 11:08:23 UTC, thedeemon wrote:
> 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.

But for D it's planned to rewrite the GC to become something like 
the Go GC right?
The last attempt to do this was afaik a Google Summer of code 
project.