6 days ago

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.

6 days ago

On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote:

>

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.

Yes, this is a way forward. Walter doesn't want to add fat pointers, however he hasn't mentioned if that's part of the language or fat pointers as a library (like C++). It doesn't need to be part of the language but as a library type. Classes in D are essentially already library fat pointers. What we need is to extend this so that we have a generic fat pointer type (that can be recompiled to whatever GC type we want) that can be used for any type through out the entire code base if the programmer wishes that. Then we need refactor druntime/phobos to only use this fat pointer type.

As you mentioned, in order to have better support for different GC, we can support compiler hooks (like your acyclic example) in order to give the compiler optimization hints.

Whatever GC type you think is better for you, you should decide that and not forced by the D compiler and library. Basically GC X is better than Y is not an argument. What is the argument is how we can allow people to choose.

6 days ago

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.

6 days ago

On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote:

>

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.

For truly high level languages garbage collection probably is the best, if you design the language semantics for it. The main issue with D is that the language semantics don't enable competitive GC advantages.

I think at least D should go with ARC for shared resources.

Then have a variety of options for task-local resources, including GC.

Next ›   Last »
1 2 3 4 5