Garbage Collection and gamedev - tl;dr Yes we want it, so let's solve it

[Ethan]

On Sunday, 22 November 2020 at 14:30:45 UTC, Ethan wrote:
> ...longer form discussion about the exact kind of GC we want in 
> game development...

So chatting with Atila on beerconf. The conversation that comes 
up, apart from this needing to be a DIP, is that I need to fill 
out some of the ideas that I have here.

One of the things I mentioned is that I don't get why library 
solutions are pursued for handling memory allocations/garbage 
collecting when the runtime already exists and can be used for 
the same purpose. This led to highlighting that the runtime 
should be more templatised anyway so that it can get that deeper 
knowledge of objects via DbI. The runtime as designed and 
implemented is about ten years behind how the language 
progressed, so there's definitely some work that needs to happen 
there.

But the single reason I'm focused on runtime versus a library 
solution. If you get the pointer acquire/release hooks in to the 
runtime that I talk about, then the whole argument between ARC GC 
and other forms comes down to a single question: "Who cares?"

A library solution actively requires the user to specify the kind 
of memory management they want. This is not what most modern 
programmers need to care about. A runtime solution means that if 
you want to switch between ARC GC and a traditional mark/sweep GC 
then you just swap the runtime implementation out. The user's 
code does not change, and it should not need to.

But yeah, this all comes down to the fact that the runtime really 
needs work these days. And to a degree, I imagine user-provided 
templates that dictate how code should be generated is an 
interesting compiler design paradigm that can help there.

So tl;dr - DIP, but I can't think about writing one for a few 
months because time, but there's bound to be interesting 
discussion that can come up as a result of this.