On Thursday, 4 April 2024 at 15:42:24 UTC, ryuukk_ wrote:

import core.memory;
import std.stdio;
import std.conv;
import std.datetime.stopwatch;

string[int] stuff;

void main()
{
    for (int i = 0; i < 10_000_000; i++)
        stuff[i] = "hello_" ~ to!(string)(i);

    auto sw = StopWatch(AutoStart.yes);
    auto a = new ubyte[512_000_000];
    writeln(sw.peek.total!"seconds");
}

I'm not pro or con but that rather looks like a bug, i.e the new'ed array should not be scanned, it's not even initialized so in no way it can contain references to living-in-the-GC-pointers.

(side-node 3 secs here ^^).

On Thursday, 4 April 2024 at 15:42:24 UTC, ryuukk_ wrote:

There's definitely an anti-GC crowd. Most of them don't use D, but they're happy to vandalize discussions about D.

int[] myarray;
create_array(allocator, myarray, length: 16);


int[int] mymap;
create_map(allocator, mymap)


// or fall back to using GC for casual scripting

But once you have to "fall back" to the GC, you've lost anyone that wants to do scripting.

But in your example, you have picked a clan, those that enjoy dealing with memory management.

Why would I care about an allocator? These are the specs of the computer that will run my program:

Memory: 125.5 GiB
Processor: 13th Gen Intel® Core™ i9-13900 × 32

If I want to write a program that changes a few lines in a markdown file, for instance, there's no reason to introduce overhead.

Why are you using the GC if that's the code you need to write? Although if I'm writing a script and it's run one time once a day, even that isn't a big deal.

On Thursday, 4 April 2024 at 16:06:35 UTC, bachmeier wrote:

int[] myarray;
create_array(allocator, myarray, length: 16);


int[int] mymap;
create_map(allocator, mymap)


// or fall back to using GC for casual scripting

Congratulation, you just describe the reason why nobody wants to take D seriously when it comes to system language with a GC

"Problem? Let's put it under the carpet"

On Thursday, 4 April 2024 at 16:19:28 UTC, ryuukk_ wrote:

That's a different issue though. D's GC can at times become a problem, and pretty much everyone that says D should embrace the GC also says it should be improved.

In your example, the simple solution is to call GC.disable() before allocating the array, so it's hardly a problem for the cases where this does arise. The real solution is to fix the GC so this doesn't happen. And you can use malloc with reference counting if you don't want to disable the GC when it's needed.

If we move the GC to a library and make it less convenient to use, we've eliminated most scripting usage in return for solving edge cases with a simple solution (probably a bug) like the one you've presented.

On Thursday, 4 April 2024 at 15:54:30 UTC, bachmeier wrote:

A great example of the strength of D. Eliminating the GC as the default is premature optimization. When you need to do something else, you can. Tune up your use of the GC or not use it.

On Thursday, 4 April 2024 at 14:13:52 UTC, Richard (Rikki) Andrew Cattermole wrote:

Not enough of a highly visible tactical win, no. However...

I'm just an occasional intense user of D. However, reading the forums, reading this thread again now specifically, I think it is possible to form a wider conclusion.

There is a massive strategic win to having a fabulous 21st century GC for D, perfectly good for soft-real-time coding with no further ado, like the one used by the author of the article linked at the start of this thread.

We might guess that some people who are trying to find the right tool for the job (their soft-real-time game for example), and who do not like manual memory management because of the additional drag it imposes on the programmer simply did not choose D even though they otherwise would were this ace GC present.

Instead they chose Java or C# or Go (but not C++ or Rust which they detest for the memory management administrative burden it imposes on the programmer and the general complicated nature of coding in such languages).

What we see in the dlang forums related to the above group are such soft-real-time programmers who have labored and successfully overcome or bypassed these difficulties with D's GC in one way or another for their situation.

This is a biased sample! The presence of these successes strongly suggests a larger group who failed to go to D, with the successes the minority who got in. Those that penetrated the armor and those who were deflected. It takes something extra to penetrate the armor, so we might reasonably think that the deflected are in the majority, with the successes being the tip of the iceberg.

D is deterring a class of people that are very much operating in the spirit of D from joining the D community and creating new things that in turn widen positive attitudes to the language out there.

Imagine this: what if D had such an ace GC for the last decade? Perception and use of D would be entirely different to its present state; soft-real-time applications would abound, with a wide community of pro-D game programmers talking in the forums.

Just like ImportC being a game changer, ace GC is a game(!) changer. It's just harder to see this, but it is so.

On Friday, 5 April 2024 at 16:40:06 UTC, Carl Sturtivant wrote:

A desire to embrace and improve the GC is an important part of the OpenD fork.

On Friday, 5 April 2024 at 16:40:06 UTC, Carl Sturtivant wrote:

This is the point I was trying to make. The strategic win for have a fantastic GC would be immense, and would far outweigh anything we could gain by continuing down the no-GC path. But first I would like to state that I am not advocating that D remove any of the existing no-GC support. Even I use it occasionally!

But I was there when the anti-GC crowd put on a full court press to convince the community that all we needed to do to see massive increase in adoption was make the language more accessible to C/C++ users who need to manually manage memory. As a result, tools like @nogc and -betterC were introduced. When that proved insufficient, the anti-GC crowd started demanding more invasive changes, up to and including removing the GC altogether.

Instead, the world changed around us. Memory Safety is now a national security concern and languages like C/C++ are being slowly replaced in favor of Rust/Go/C#/Java. These languages speak to the most common usages and concerns of the users of programming languages, and those usages/concerns largely do not benefit from no-GC.

Chasing no-GC as far as we did was a mistake that cost us precious time and scarce resources. We need to be mature enough to admit that it was a mistake and correct our course. Given the lessons and direction of the industry over the intervening years, I would strongly argue that now is the time to return our focus to the GC.

Mic. Drop.

On Sunday, 31 March 2024 at 14:22:43 UTC, Adam wrote:

I think if you like GC, you can try openD, which is pure GC.
As for D, if it's purely GC, why don't others use Rust? Are you prepared to completely abandon for system scope?.