Plan for D

[nkm1]

On Sunday, 16 May 2021 at 10:15:00 UTC, Mike Parker wrote:

> I'm not saying there can't be more work done to alleviate any 
> pain that arises from going without the GC. But I do believe 
> some people reach for @nogc when they don't need to, and I 
> don't think that's a demographic we should be aiming for.

But the trouble is that D's GC is just not a very good one! There 
are much better GCs out there. Why doesn't D have one of those 
better GCs?

It's pretty obvious that the decision to offer full support for 
@nogc is the source of real technical trouble with memory 
management in D. The language was designed to work with GC and 
relies on it. Thus, the path of least resistance (technical 
resistance, that is) would be to improve the GC - for example, by 
implementing memory barriers, perhaps restricting the language 
itself in some respects and doing other such things which should 
make it possible to use some better GC. People who cry about 
automated memory management too much could then be told to just 
go somewhere else and use C++ or Rust or whatever (which is what 
they do anyway).
Instead what happened is stuff like dip1000... does that even 
work already? Juding by the thread "dip1000 + pure is a DEADLY 
COMBO", not really. There were also some ideas about refcounting 
- looks like that also went nowhere?

Supporting both GC and @nogc is just way too difficult, that's 
all there is to it. Other programming languages don't do it (e.g. 
its possible to bolt a GC onto C or C++, but they don't offer any 
special support for it). Instead, D is stuck with subpar GC, 
which seems no better than what's possible with C++, and also 
with dip1000, which doesn't seem all that great either.

All other problems with D aren't a big deal, but the memory 
management thing is real trouble, and that's because the 
developers go against the original design of the language.