Future of D

Max Haughton maxhaton at gmail.com
Sun Dec 13 21:21:12 UTC 2020


On Sunday, 13 December 2020 at 20:59:10 UTC, Bastiaan Veelo wrote:
> On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:
>> I really think properly killing the GC
>
> What do you mean by this? What would take its place, and what 
> practical steps would need to be taken? And above all, how can 
> the language and library features that rely on the GC today be 
> replaced by alternatives that are as appealing?
>
>> would give us a big boost in fresh blood to the community. It 
>> would still be there, but it's a huge turn off to new users.
>
> I don’t understand, when it’s still there, GCfobics will still 
> think there is reason to look elsewhere. There are various ways 
> to use D without garbage collection today, so it is important 
> to define what this imaginary language will look like.
>
> I don’t think there is a boatload of fresh blood just waiting 
> for a different D even if is has a GC that has been killed.
>
> I love the features that are enabled by the GC and I love not 
> needing to worry about the problems that manual memory 
> management brings.
>
> Above all, I just don’t buy that “it's a huge turn off to new 
> users”.
>
> I think D hits the sweet spot with a pluggable, configurable, 
> profilable and optional garbage collector!
>
> — Bastiaan.

The problem with the GC is that it isn't optional. It is, 
technically, but practically if you want to use the standard 
library some things use the GC that really shouldn't.

The solution will have to be better than C++. - passing 
unique_ptr isn't good enough. In effect, this means we need a 
combination of reference counting and borrowing. I understand 
that this is a big task but we're a small but efficient community 
so we should try.

Garbage collection is absolutely a powerful tool but we shouldn't 
lie to ourselves about where it doesn't fit.


More information about the Digitalmars-d mailing list