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

[rikki cattermole]

On 13/12/2022 8:11 PM, thebluepandabear wrote:
> Hello,
> 
> I was speaking to one of my friends on D language and he spoke about how 
> he doesn't like D language due to the fact that its standard library is 
> built on top of GC (garbage collection).
> 
> He said that if he doesn't want to implement GC he misses out on the 
> standard library, which for him is a big disadvantage.
> 
> Does this claim have merit? I am not far enough into learning D, so I 
> haven't touched GC stuff yet, but I am curious what the D community has 
> to say about this issue.

No.

Memory and lifetime management, are two very difficult problems to solve 
and extremely easy to get wrong in a major way.

Garbage collectors are by far the easiest and most common solution in 
the literature to solve these sets of problems in a way that is very 
unlikely to cause you issues.

In D the GC is merely a library that you can call into, and in turn 
control. If you want to stop it collecting until a better time you can. 
Its just one function call away.

As someone who has studied lock-free concurrent data structures, GC's, 
memory allocators and has a what amounts to a standard library in 
-betterC with his own memory allocators and locks using reference 
counting; use locks, embrace the GC, they solve real problems with less 
issues.