On Sunday, 16 May 2021 at 09:48:58 UTC, IGotD- wrote:

By definition, avoiding the GC means avoiding features that use the GC. And you don't lose everything in the standard library, either. A good chunk of it does not require the GC.

Like anything else in programming, it's a tradeoff. Give up the GC and you lose the convenience it provides. The question is, do you need to give up the GC or not? And if so, do you need to give it up completely or only in the spots where you absolutely cannot trigger an allocation?

I'm not saying there can't be more work done to alleviate any pain that arises from going without the GC. But I do believe some people reach for @nogc when they don't need to, and I don't think that's a demographic we should be aiming for.

On Sunday, 16 May 2021 at 06:44:09 UTC, Ola Fosheim Grostad wrote:

C'mon dude... How can you say with a straight face that dmd isn't a short running process?

It's even hard to imagine a better real world example of a case where it's ok to not free.

Also, if you want to you can use the lowmem switch?

On Sunday, 16 May 2021 at 10:15:00 UTC, Mike Parker wrote:

Many like GC but it is the type of GC in D that disqualifies the language for certain applications, an area where often C++ dominates. The key is not giving up GC, but giving people a choice of which type of GC they want to use. D is a versatile language and giving people the versatility of pick and choose GC type is something that would suit an already versatile language. D already supports RC, but only by implicitly doing so in the code so next step would be transparent RC.

On Sunday, 16 May 2021 at 07:18:54 UTC, Paulo Pinto wrote:

+1

On Sunday, 16 May 2021 at 03:58:15 UTC, Mike Parker wrote:

Hi Mike,
I have to agree with Ola on this point.
I too find it jarring that for something as simple (really) as a compiler, that a very simple bump-the-pointer memory allocation strategy without any freeing of memory is considered superior to the language's GC.

I do not buy the performance argument. The high memory consumption of the D compiler is a real issue, and it does hurt compilation performance. The amount of memory used frequently passes the available physical memory and paging isn't cheap. Or worse, the memory used exceeds the pagefile limit, and the compile just fails.
Speeding up a build by parallel compilation is not possible with a compiler that has such high memory demands.

Let's simply acknowledge the issue and move on. Ignoring it will just spawn more forum posts about it and drain our energy.

cheers,
Johan

On Sunday, 16 May 2021 at 10:22:02 UTC, Imperatorn wrote:

This is only acceptable in realtime applications or very specific FOREGROUND applications. Draining kernel and hardware resources is not something a BACKGROUND prosess should do.

If D was popular it would be used in installers and the compiler would run for ages, kicking in and out.

On Sunday, 16 May 2021 at 10:50:38 UTC, Johan Engelen wrote:

Indeed. When this bad decision was made, the blame went to free. Walter's decision was to never call free... but someone here just replaced the free call with the jemalloc library and saw the same performance improvement.

Walter's decision was, even known at the time, the wrong one.

dmd's atrocious memory management is the #2 issue using D in real world applications (#1 being the godawful error messages. in this order cuz at least in theory, you can buy more ram lol).

On Sunday, 16 May 2021 at 10:15:00 UTC, Mike Parker wrote:

Yes, POOP is what made C++ so unappealing (POOP permeates C++ froma A to Z) and we should avoid to fall in that same trap in D.

POOP = Premature Optimization Oriented Programming.

On Sunday, 16 May 2021 at 10:15:00 UTC, Mike Parker wrote:

But the trouble is that D's GC is just not a very good one! There are much better GCs out there. Why doesn't D have one of those better GCs?

It's pretty obvious that the decision to offer full support for @nogc is the source of real technical trouble with memory management in D. The language was designed to work with GC and relies on it. Thus, the path of least resistance (technical resistance, that is) would be to improve the GC - for example, by implementing memory barriers, perhaps restricting the language itself in some respects and doing other such things which should make it possible to use some better GC. People who cry about automated memory management too much could then be told to just go somewhere else and use C++ or Rust or whatever (which is what they do anyway).
Instead what happened is stuff like dip1000... does that even work already? Juding by the thread "dip1000 + pure is a DEADLY COMBO", not really. There were also some ideas about refcounting - looks like that also went nowhere?

Supporting both GC and @nogc is just way too difficult, that's all there is to it. Other programming languages don't do it (e.g. its possible to bolt a GC onto C or C++, but they don't offer any special support for it). Instead, D is stuck with subpar GC, which seems no better than what's possible with C++, and also with dip1000, which doesn't seem all that great either.

All other problems with D aren't a big deal, but the memory management thing is real trouble, and that's because the developers go against the original design of the language.

On Sunday, 16 May 2021 at 10:50:38 UTC, Johan Engelen wrote:

I have trouble following an argument between people that I feel should know better than me that the premise is false.

Ola's statement that

is false, given the -lowmem compiler option:

So dmd as shipped can be used with and without the GC, the default being fast. You've got to have a default.

So before taking this further, I'd suggest arguing about the effectiveness of -lowmem, and whether the GC at all can be blamed.

1. Usually the prime argument against a GC is speed. So, if one wants to prove that the GC leads to unacceptable delays then demonstrate that compile times with -lowmem take considerably more time than compilers that use manual memory management. Try to come up with a comparable case, like C-like betterC and C. If the argument is that important, it shouldn't be hard to make an indisputable case.
2. A secondary argument is that the GC claims more memory than when memory is released by hand. We know that memory usage can be very high even with -lowmem, but that is much more likely to be due to template instantiations and ctfe than due to uncollected memory. Again, it shouldn't be hard to demonstrate whether the GC can be blamed substantially or not.

Until i see this demonstrated, the argument goes on the GC-whiners pile for me...

-- Bastiaan.