On Friday, 19 November 2021 at 10:13:02 UTC, Paulo Pinto wrote:

Thanks for the link! Important quote, take notice Boehm GC-defenders:

«C is hostile to automatic garbage collection.»

HOSTILE! Nothing less. And I agree.

Another important quote:

«As should be clear from the history above, C evolved from typeless languages. It did not suddenly appear to its earliest users and developers as an entirely new language with its own rules; instead we continually had to adapt existing programs as the language developed, and make allowance for an existing body of code.»

So, we are stuck with the flaws introduced by backwards compatibility requirements of the 1970s in 2021. *cheers*

D should not be so concerned with breakage, just do D3 and get it right.

On Friday, 19 November 2021 at 10:47:12 UTC, Ola Fosheim Grøstad wrote:

Right.

On Friday, 19 November 2021 at 10:47:12 UTC, Ola Fosheim Grøstad wrote:

This is why D community should take care when celebrating designs in other languages like Objective-C and Swift's ARC.

As I already mentioned a couple of times, Objective-C ARC did not came out being the best technical option for Objective-C just like that, rather due to the failure of making Objective-C GC with a tracing GC based on Boehm work without issues.

Still available on the documentation archive,

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html#//apple_ref/doc/uid/TP40002431

Check "Architecture", "Design Patterns to Use, and to Avoid", "Inapplicable Patterns", just for starters.

So when Apple rebooted their design, they followed up on what Visual C++ extensions already did for COM (e.g. _com_ptr_t), and made Objective-C compiler perform the retain/release Cocoa messages itself.

Coined their reference counting approach as ARC, and made a whole marketing message how ARC tops tracing GC, and the world of App devs cluessless of compiler design issues cheered in unison.

Swift as natural evolution from Objective-C, with 1:1 interoperability goals with the Cocoa ecosystem and Objective-C runtime, naturally had double down on ARC.

The alternative with a tracing GC would require an engineering effort similar to how .NET interops with COM,

https://docs.microsoft.com/en-us/dotnet/standard/native-interop/cominterop

So beware when discussing what D should adopt from other languages, usually there is more to the whole story than just RC vs tracing GC.

On Friday, 19 November 2021 at 12:22:05 UTC, Paulo Pinto wrote:

Well, an Apple engineer did point out in this forum that one could achieve better performance than Objective-C ARC, because of the historic constraints Objective-C had to deal with.

Anyway, I am in favour of ARC for shared and local GC with actors for non-shared. I think that model fits well with most D users expect and also where hardware is heading.

It would also set D apart from the other alternatives.

D should not try to become another language. It must differentiate itself by looking at the open positions in the design space.

E.g. I am a bit torn by C++ compatibility. Yes, it is good for indie game developers, but can also be very limiting. Very difficult choice to make.

On Friday, 19 November 2021 at 12:45:45 UTC, rikki cattermole wrote:

That is more conventional, and in some sense easier because it is more homogeneous.

I think some people will complain about performance, but I am not against it.

On Friday, 19 November 2021 at 12:22:05 UTC, Paulo Pinto wrote:

I think it is besides the point whatever is the best, tracing GC or reference counted GC or whatever. The truth is that both have their advantages and disadvantages.

The problem for D is that the language is limited to tracing GC and I think it is a mistake. The goal should be to create a language that can potentially support any GC type, preferably with as little change as possible when switching between them. This also might include the support for compacting the heap.

It's challenging to create a language that supports all these different types but I think D should have gone a step higher in the abstraction in order to be more versatile.

It is also clear that memory management is something that is still evolving and maybe in the future someone might come up with an even better method that is interesting for D to adopt. That's why the language design should take that into consideration.

On Friday, 19 November 2021 at 15:20:06 UTC, IGotD- wrote:

That would be affine/linear types, the best ergonomics for them is to combine a tracing GC, with such types.

Instead of having them all around the program, only make use of them when performance requirements so demand them.

This is the approach being taken by Swift, Haskell, OCaml, and even D with @life.

It would be interesting to see @life + GC settle all discussions on D's approach to memory management, but somehow I feel it won't happen.

On Friday, 19 November 2021 at 15:37:04 UTC, Paulo Pinto wrote:

What do you think about Nim's ARC + GC solution? They call it ORC :
https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html