Regarding the depressing GC blog article, dated 2021

https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/

At the foot it says
Content Copyright © 2016-2018 by the D Language Foundation, All Rights Reserved

Easy to guess the current content about the GC. If a person knows anything about the situation and has a small amount of imagination, all of this is totally obvious. What a mess!

Do we really have to reverse engineer the implementation to get here? And a very incomplete reverse engineering indeed. The blog's conclusion: The situation is bad, therefore avoid interacting with it --- this is my first order approximation to the article.

So about D itself. No design here then, no intent, no anticipation of the consequences of putting the pieces together, no strategic reasoning about the consequences of the construction of D with a garbage collector. All this long-ago stuff is coming home to roost.

The article admits it is incomplete. But what can follow except workarounds if someone needs to get past this? And most won't work. This is not just a roadblock. It reveals the entropy inside D. The core of D is fatally flawed. D is not a language where system garbage is taken care of, both concretely and abstractly. The idea that we all system-program ourselves around these difficulties suggests both labor and depression.

So disappointed. I wanted D to win. But this is where the dirt is, and I do not believe a strategic fix will ever be in the works. Entropy rules.

On Saturday, 6 March 2021 at 01:33:00 UTC, NonNull wrote:
> Regarding the depressing GC blog article, dated 2021
>
> https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/

Is this a fair summary of your position?

  You want D to have very simple object lifetime rules or
  maybe deterministic object finalization. You are envious of
  Rust's Drop trait or similar. You dislike the tutorial tone
  of the blog, its "let me help you understand lifetimes in D",
  because it accepts D's current rules as a given when what
  you would prefer to read is a grand proposal to change those
  rules. Reading the blog has helped you to lose hope that D
  will one day change into a language you'd prefer.

Also:

  The copyright notice is old and this shows a lack of care or
  attention to the website.

On Saturday, 6 March 2021 at 01:33:00 UTC, NonNull wrote:
> Regarding the depressing GC blog article, dated 2021
>
> https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/
>
> At the foot it says
> Content Copyright © 2016-2018 by the D Language Foundation, All Rights Reserved
>
> Easy to guess the current content about the GC. If a person knows anything about the situation and has a small amount of imagination, all of this is totally obvious. What a mess!
>
> Do we really have to reverse engineer the implementation to get here? And a very incomplete reverse engineering indeed. The blog's conclusion: The situation is bad, therefore avoid interacting with it --- this is my first order approximation to the article.
>
> So about D itself. No design here then, no intent, no anticipation of the consequences of putting the pieces together, no strategic reasoning about the consequences of the construction of D with a garbage collector. All this long-ago stuff is coming home to roost.
>
> The article admits it is incomplete. But what can follow except workarounds if someone needs to get past this? And most won't work. This is not just a roadblock. It reveals the entropy inside D. The core of D is fatally flawed. D is not a language where system garbage is taken care of, both concretely and abstractly. The idea that we all system-program ourselves around these difficulties suggests both labor and depression.
>
> So disappointed. I wanted D to win. But this is where the dirt is, and I do not believe a strategic fix will ever be in the works. Entropy rules.

I vaguely agree that the Garbage Collector as a global concept is dated, however: Be realistic - every programming language has guidelines (http://dev.stephendiehl.com/hask/ Even for Haskell they can be enormous) and dos and don'ts.

Mike's article could probably use being a little more abstract in it's discussion of garbage collection as a concept, but this isn't reverse engineering the garbage collector, is it? It's also the second of (I think) three articles.

Fundamentally Garbage Collection is an optimization opportunity (sometimes at runtime, usually for the developer) is a trick for when you don't need determinism. All this article does is make clear what you shouldn't be tricked into believing.

On Saturday, 6 March 2021 at 01:33:00 UTC, NonNull wrote:
> Regarding the depressing GC blog article, dated 2021
>
> https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/
>
> At the foot it says
> Content Copyright © 2016-2018 by the D Language Foundation, All Rights Reserved
>
> Easy to guess the current content about the GC. If a person knows anything about the situation and has a small amount of imagination, all of this is totally obvious. What a mess!
>
> Do we really have to reverse engineer the implementation to get here? And a very incomplete reverse engineering indeed. The blog's conclusion: The situation is bad, therefore avoid interacting with it --- this is my first order approximation to the article.
>
> So about D itself. No design here then, no intent, no anticipation of the consequences of putting the pieces together, no strategic reasoning about the consequences of the construction of D with a garbage collector. All this long-ago stuff is coming home to roost.
>
> The article admits it is incomplete. But what can follow except workarounds if someone needs to get past this? And most won't work. This is not just a roadblock. It reveals the entropy inside D. The core of D is fatally flawed. D is not a language where system garbage is taken care of, both concretely and abstractly. The idea that we all system-program ourselves around these difficulties suggests both labor and depression.
>
> So disappointed. I wanted D to win. But this is where the dirt is, and I do not believe a strategic fix will ever be in the works. Entropy rules.

I took the article with a grain of salt when I saw the author claiming that finalisation of classes is a problem in all garbage collected languages. It seems that the author failed to update himself or - what's worse - wants to justify D failure in having deterministic class destruction by pointing to others.

C# has IDisposable/using and Java has AutoCloseable as mechanisms for deterministic destruction.

I bet that the next article will end with the conclusion "use structs, classes are bad, you don't really need OOP, it's obsolete. But if you insist, here is our half baked library solution". I would be happy to be wrong on this.

If we want to be honest here, D failed to update/correct its OOP support, trying to please the C++ gang afraid of the garbage collector. I remember when D had built-in allocator support and delete for deterministic destructors. Now they are deprecated and we have a library solution :)

On Saturday, 6 March 2021 at 20:21:41 UTC, Rumbu wrote:
> It seems that the author failed to update himself or - what's worse - wants to justify D failure in having deterministic class destruction by pointing to others.

D *does* have deterministic class destruction. `scope Object o = new Object;`. Also `scope(exit) .destroy(o);`.

The blog is kinda awkward because it says "pretend class destructors don't exist" now, but the next parts are going to explain how he's lying to you.

Class destructors do exist in D, just you need to take care to use them properly (especially since the old `scope class` was deprecated. Note this is distinct from the not-deprecated `scope Object` construct.). So the early advice is to pretend they don't exist. Then once you level up a little you can learn the truth.

On Saturday, 6 March 2021 at 03:07:32 UTC, Max Haughton wrote:
> On Saturday, 6 March 2021 at 01:33:00 UTC, NonNull wrote:
>>
>
> I vaguely agree that the Garbage Collector as a global concept is dated, however: Be realistic - every programming language has guidelines (http://dev.stephendiehl.com/hask/ Even for Haskell they can be enormous) and dos and don'ts.

"Number of guidelines" is inversely proportional to quality of design.

On Saturday, 6 March 2021 at 20:45:00 UTC, Adam D. Ruppe wrote:
> On Saturday, 6 March 2021 at 20:21:41 UTC, Rumbu wrote:
>> [...]
>
> D *does* have deterministic class destruction. `scope Object o = new Object;`. Also `scope(exit) .destroy(o);`.
>
> The blog is kinda awkward because it says "pretend class destructors don't exist" now, but the next parts are going to explain how he's lying to you.
>
> Class destructors do exist in D, just you need to take care to use them properly (especially since the old `scope class` was deprecated. Note this is distinct from the not-deprecated `scope Object` construct.). So the early advice is to pretend they don't exist. Then once you level up a little you can learn the truth.

Oh, it's like scientology? 😱

Xenu

On Saturday, 6 March 2021 at 20:45:00 UTC, Adam D. Ruppe wrote:
> On Saturday, 6 March 2021 at 20:21:41 UTC, Rumbu wrote:
>> It seems that the author failed to update himself or - what's worse - wants to justify D failure in having deterministic class destruction by pointing to others.
>
> D *does* have deterministic class destruction. `scope Object o = new Object;`. Also `scope(exit) .destroy(o);`.
>
> The blog is kinda awkward because it says "pretend class destructors don't exist" now, but the next parts are going to explain how he's lying to you.
>
> Class destructors do exist in D, just you need to take care to use them properly (especially since the old `scope class` was deprecated. Note this is distinct from the not-deprecated `scope Object` construct.). So the early advice is to pretend they don't exist. Then once you level up a little you can learn the truth.

A library solution is not a feature of the language. Also the scope Object declaration is not needed. At least I didn't found any reference in the language specification except the one of scoped classes, which, of course, will be deprecated.

On Saturday, 6 March 2021 at 21:12:51 UTC, Rumbu wrote:
> A library solution is not a feature of the language.

I'm not talking about a library solution.

> Also the scope Object declaration is not needed.

That's how you get scoped, deterministic destruction of class objects in the pure language.

> At least I didn't found any reference in the language specification except the one of scoped classes, which, of course, will be deprecated.

That's different. That's what I meant by `scope class`, but `scope Object` is referring to it as a storage class

https://dlang.org/deprecate.html#scope%20as%20a%20type%20constraint

"scope as a storage class attributed to variables, function parameters, etc. is not deprecated."

But this is why it is complicated: as the class author, you can't know how it will be used. The same is also true of structs, which the next part of the blog will talk about. So you need to take some appropriate care.

It can be done right though.

On Saturday, 6 March 2021 at 20:21:41 UTC, Rumbu wrote:

> I bet that the next article will end with the conclusion "use structs, classes are bad, you don't really need OOP, it's obsolete. But if you insist, here is our half baked library solution". I would be happy to be wrong on this.
>

Then you're going to be happy.