Why many programmers don't like GC?

[Ola Fosheim Grøstad]

On Friday, 15 January 2021 at 14:50:00 UTC, welkam wrote:
> The reasoning of why we do not implement write barriers is that 
> it will hurt low level programming. But I feel like if we drew 
> a ven diagram of people who rely on GC and those who do a lot 
> of writes trough a pointer we would get almost no overlap. In 
> other words if D compiler had a switch that turned on write 
> barriers and better GC I think many people would use it and 
> find the trade offs acceptable.


Yes, I think this is what we need some way of making the compiler 
know which pointers has to be traced so that it can avoid 
redundant pointers. For instance, a type for telling the compiler 
that a pointer is non-owning. Then we don't have to use a write 
barrier for that non-owning pointer I think? Or maybe I am 
missing something?

Then we can also have a switch.

But I also think that we could do this:

1. Make all class objects GC allocated and use write barriers for 
those.
2. Allow non-owning annotations for class object pointers.
3. Make slices and dynamic arrays RC.
4. Let structs be held by unique_ptr style (Rust/C++ default).

Then we need a way to improve precise tracing:
1. make use of LLVM precise stack/register information
2. introduce tagged unions and only allow redundant pointers in 
untagged unions
3. Each compile phase emits information for GC.
4. Before linking the compiler generates code to narrowly trace 
the correct pointers.

Then we don't have to deal with real time type information lookup 
and don't have to do expensive lookup to figure out if a pointer 
points to GC memory or not. The compiler can then just assume 
that the generated collection code is exact.