The D standard library is built on GC, is that a negative or positive?

[cc]

On Wednesday, 14 December 2022 at 10:06:40 UTC, matheus wrote:
> But when I tried D for this same thing, I used to do the basic 
> thing like, enable GC load and instantiate everything for the 
> level, disable GC and run the game, and just enable again after 
> the level is over, and I don't remember having much trouble.

Pre-allocated lists are fine for many cases.  We typically use 
them for particle engines now, when we can be comfortable with a 
specific hard limit and the initial resource draw isn't a 
significant burden.  But in some of our engines we decided we 
wanted to be able to scale without entity limits, especially for 
persistent always-online worlds.  Naive porting from reference 
counted languages to D's GC led to unacceptable resource usage 
and performance losses that `GC.disable` couldn't work around.  
It doesn't matter if the actual delay caused by a GC pause is 
minimal, if those delays cause significant recurring hiccups and 
timing errors.  Allocations and deallocations had to be more 
deterministic, ultimately it came down to the decision that with 
the need to offload or reschedule memory management to be more 
distributed, working around the GC would be more trouble than 
just avoiding it in the first place.