D Language Foundation Monthly Meeting Summary

[Paulo Pinto]

On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote:
> On Saturday, 5 June 2021 at 09:14:52 UTC, Ola Fosheim Grøstad 
> wrote:
>
>> The current GC strategy is a dead end. No GC makes the 
>> language too much of a C++ with no real edge. D needs to offer 
>> something other languages do not, to offset the cost of 
>> learning the language complexities.
>
> I think the switch to arc with cycle detection as opt out (like 
> in python) is the right direction, it fits more to a system 
> level language making use of destructors more often.
>
> Rewriting cyclic code to acyclic code is easier than lifetime 
> management in general.
>
> Further, optimizations can be introduced that detect acyclic 
> structures in D just as it is the case for nim 
> (https://nim-lang.org/docs/manual.html#pragmas-acyclic-pragma).
>
> That doesn't mean tracing GC is bad, I'm still skeptical that 
> arc + cycle detection is better than tracing in general for 
> true high level languages.

Well, I advise reading

"On Adding Garbage Collection and Runtime Types to a 
Strongly-Typed,
Statically-Checked, Concurrent Language"

http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf

And watching the upcoming WWDC 2021 talk "ARC in Swift: Basics 
and beyond" on Friday.

https://developer.apple.com/wwdc21/sessions

What Cedar, Swift and Nim have in common that D lacks, are fat 
pointers, the compiler awareness for optimizations regarding 
elision of counter manipulation code, and tricks like background 
threads for the cycle collector or cascade deletions.

It is no an accident that high performance reference counting GC 
is similar to tracing GC in regards to implementation complexity.