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.