On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:
>
> I really think properly killing the GC would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users. That and a bit of blog-spam, I constantly see articles for new languages that are (frankly) a bit rubbish compared to various D features but because they are post-(new generation of languages) they are "cooler"

Not really. GC tends to be the least-effort way to get your average code to work, so it remains a good "default" way to do things. We should strive to make life without GC as easy as possible, but that does not mean changing the default allocation strategy.

For Phobos-like code, the GC may seem old-fashioned -I used to think the way too. But for your average application code that does not need to be that finished, it's a totally different story.

On Sunday, 13 December 2020 at 20:59:10 UTC, Bastiaan Veelo wrote:
> On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:
>> I really think properly killing the GC
>
> What do you mean by this? What would take its place, and what practical steps would need to be taken? And above all, how can the language and library features that rely on the GC today be replaced by alternatives that are as appealing?
>
>> would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users.
>
> I don’t understand, when it’s still there, GCfobics will still think there is reason to look elsewhere. There are various ways to use D without garbage collection today, so it is important to define what this imaginary language will look like.
>
> I don’t think there is a boatload of fresh blood just waiting for a different D even if is has a GC that has been killed.
>
> I love the features that are enabled by the GC and I love not needing to worry about the problems that manual memory management brings.
>
> Above all, I just don’t buy that “it's a huge turn off to new users”.
>
> I think D hits the sweet spot with a pluggable, configurable, profilable and optional garbage collector!
>
> — Bastiaan.

The problem with the GC is that it isn't optional. It is, technically, but practically if you want to use the standard library some things use the GC that really shouldn't.

The solution will have to be better than C++. - passing unique_ptr isn't good enough. In effect, this means we need a combination of reference counting and borrowing. I understand that this is a big task but we're a small but efficient community so we should try.

Garbage collection is absolutely a powerful tool but we shouldn't lie to ourselves about where it doesn't fit.

On Sunday, 13 December 2020 at 21:21:12 UTC, Max Haughton wrote:
>
> The problem with the GC is that it isn't optional. It is, technically, but practically if you want to use the standard library some things use the GC that really shouldn't.
>
> The solution will have to be better than C++. - passing unique_ptr isn't good enough. In effect, this means we need a combination of reference counting and borrowing. I understand that this is a big task but we're a small but efficient community so we should try.
>
> Garbage collection is absolutely a powerful tool but we shouldn't lie to ourselves about where it doesn't fit.

D needs to differentiate managed and raw pointers, this has to be done in order to get out of the tracing GC swamp. Not a small task but I think that the D community can do it. This is the key and Nim has already gone through several types of GC in its development and keeps on updating them.

Also it would be nice to skip all the "unique_ptr" spamming in the source code like C++. A built in identifier would be nice like "int^ intPointer = new int;

On Sunday, 13 December 2020 at 22:18:26 UTC, IGotD- wrote:
>
> D needs to differentiate managed and raw pointers, this has to be done in order to get out of the tracing GC swamp. Not a small task but I think that the D community can do it. This is the key and Nim has already gone through several types of GC in its development and keeps on updating them.

This is never going to happen. It's too big of a breaking change.

On Sunday, 13 December 2020 at 22:26:55 UTC, Paul Backus wrote:
>
> This is never going to happen. It's too big of a breaking change.

I'm afraid of that. No pain no glory.

On Sunday, 13 December 2020 at 22:41:36 UTC, IGotD- wrote:
> On Sunday, 13 December 2020 at 22:26:55 UTC, Paul Backus wrote:
>>
>> This is never going to happen. It's too big of a breaking change.
>
> I'm afraid of that. No pain no glory.

It's easy to sit around in our armchairs pontificating about how, if only "the D community" (read: someone else) would do X, Y, or Z, all of our problems would be solved.

It's harder, but ultimately much more rewarding, to roll up one's sleeves and actually make a positive contribution.

On Sunday, 13 December 2020 at 22:53:31 UTC, Paul Backus wrote:
>
> It's easy to sit around in our armchairs pontificating about how, if only "the D community" (read: someone else) would do X, Y, or Z, all of our problems would be solved.
>
> It's harder, but ultimately much more rewarding, to roll up one's sleeves and actually make a positive contribution.

This is not a one man job which someone can make a neat preview of. It's a decision that has to be made from the maintainers so that several people can start working with such a big task. Also documenting what needs to be done. This ties into the original post with the blog post, that the D project has problems with rallying people towards a common goal (which today is very vague).

People starting to add and change things randomly and then hoping that it will be accepted and be merged isn't really a good way to run a project.

On Sunday, 13 December 2020 at 22:53:31 UTC, Paul Backus wrote:
> On Sunday, 13 December 2020 at 22:41:36 UTC, IGotD- wrote:
>> On Sunday, 13 December 2020 at 22:26:55 UTC, Paul Backus wrote:
>>>
>>> This is never going to happen. It's too big of a breaking change.
>>
>> I'm afraid of that. No pain no glory.
>
> It's easy to sit around in our armchairs pontificating about how, if only "the D community" (read: someone else) would do X, Y, or Z, all of our problems would be solved.
>
> It's harder, but ultimately much more rewarding, to roll up one's sleeves and actually make a positive contribution.

Positive contribution to what? Do we really have a grand strategy as a language at the moment? Obviously the language ecosystem can always be improved but the language itself is more subtle.

We know what we want (e.g. take memory safety for an example), but doing it requires coordination. The DIP system seems to work pretty well, but it encourages incremental work which isn't necessarily ideal for something big (like borrowing) - this doesn't necessarily imply breaking things but it would mean new syntax which (speaking for myself personally) I don't really have the confidence to try and propose by myself.

FWIW, we might benefit from having working groups a la the C++ committee. I'd happily contribute to one on memory safety (I would say I'd start one but I dont trust my knowledge of either DMD internals or formal proofs of this kind of theory).

On Sunday, 13 December 2020 at 23:13:24 UTC, Max Haughton wrote:
> On Sunday, 13 December 2020 at 22:53:31 UTC, Paul Backus wrote:
>> [...]
>
> Positive contribution to what? Do we really have a grand strategy as a language at the moment? Obviously the language ecosystem can always be improved but the language itself is more subtle.
>
> [...]

*the depths of DMD and internals, and similarly with parts of ldc I meant to say

On Sunday, 13 December 2020 at 21:21:12 UTC, Max Haughton wrote:
> The solution will have to be better than C++. - passing unique_ptr isn't good enough. In effect, this means we need a combination of reference counting and borrowing. I understand that this is a big task but we're a small but efficient community so we should try.

OK, I like this formulation better. The problem I had with your previously hyperbolic wording was that I don’t think it does any good. It does not make anyone jump into gear and kill the GC to please people that aren’t here, and it possibly scares people that should not be scared or confirms people’s misbelieves.

The good news is that there is motion. We now have copy constructors which is a necessary step for RC, as is proto object, iirc. @live is actively being worked on.

> Garbage collection is absolutely a powerful tool but we shouldn't lie to ourselves about where it doesn't fit.

“Fitting” is relative. There may be better options and work is being done to please a bigger audience. My point is that most complaints about garbage collection I see on these forums are hypothetical and theoretical. I don’t think I have seen anyone hitting collection related problems in practice that cannot be brought within acceptable limits and that would have been better off using another language.

— Bastiaan.