> It's actually rather rare to *need* to avoid the GC -- only niche applications need that, like if you're writing a game engine that has to avoid stop-the-world pauses (which can be easily worked around, btw), or real-time medical applications where if it stops for 10ms somebody dies. 90% of real world programs out there work just fine with the GC.

Actually it's my case. I'd LOVE to use D for game development for instance, but I won't take the risk of having the GC pause the game when I don't want to, even for just an unknown amount of milliseconds, and even if I know that anyway I'll try to limit dynamic allocations by using caches etc.

Of course, for everything else (scripts, tools, servers, etc), now I use D and I'm glad with it. Because for that same scripts and applications, I could have used any other garbage collected language (JavaScript/, C#, etc), so no problem for that.

And that's my point.

D is probably the best alternative to C++, Java, C# and Node.js. Better than Rust too.

But for D to succeed as a viable alternative to C++ where it's mandatory to use it, it must have a minimalistic version of Phobos that makes it easy and natural to use D with manual memory management.

Maybe it's already the case, but then I suggest that you should promote it louder, so that people don't even feel the need to try Rust for instance.

On Monday, 6 March 2017 at 05:50:01 UTC, Rico Decho wrote:

>
> Actually it's my case. I'd LOVE to use D for game development for instance, but I won't take the risk of having the GC pause the game when I don't want to, even for just an unknown amount of milliseconds, and even if I know that anyway I'll try to limit dynamic allocations by using caches etc.

It's *not* going to pause your game unless you do any allocations in your game loop, because it isn't otherwise going to run. D's GC is perfectly acceptable for games if you just follow the best practices that are already standard in game development. Allocate as much as you can when loading a new level and minimize allocations in the loop. If you do need to allocate during the level, you can avoid the GC entirely and do so via malloc. D provides the means to reduce or eliminate the impact of the GC in your critical loops. When developing games, you should already be trying to minimize allocations in those loops anyway.

On Monday, 6 March 2017 at 05:50:01 UTC, Rico Decho wrote:
> Actually it's my case. I'd LOVE to use D for game development for instance, but I won't take the risk of having the GC pause the game when I don't want to, even for just an unknown amount of milliseconds, and even if I know that anyway I'll try to limit dynamic allocations by using caches etc.

void loop() {
    // code
}

void loadLevel() {
    import core.memory : GC;
    GC.disable();
    while(stuff)
        loop();
    GC.collect();
}

Also see EMSI containers for no gc containers with deterministic destruction https://github.com/economicmodeling/containers

On Monday, 6 March 2017 at 05:50:01 UTC, Rico Decho wrote:
>> It's actually rather rare to *need* to avoid the GC -- only niche applications need that, like if you're writing a game engine that has to avoid stop-the-world pauses (which can be easily worked around, btw), or real-time medical applications where if it stops for 10ms somebody dies. 90% of real world programs out there work just fine with the GC.
>
> Actually it's my case. I'd LOVE to use D for game development for instance, but I won't take the risk of having the GC pause the game when I don't want to, even for just an unknown amount of milliseconds, and even if I know that anyway I'll try to limit dynamic allocations by using caches etc.

If this isn't a perfect example of D's marketing problem I don't know what is. Someone who likes D and takes the time to write on the forum yet thinks the GC will randomly run no matter what.

To make it abundantly clear: I'm not bashing on you in the slightest, Rico Decho. I'm just pointing out that there's a clear problem here in that we can't expect to convert e.g. C++ game developers who have never written a line of D before if we haven't even managed to educate the community yet.

Unfortunately, I have no ideas on how to remedy the situation. I also don't know how to get people to stop believing that C is magically fast either, which I think is a similar perception problem.

Atila

> void loop() {
>     // code
> }
>
> void loadLevel() {
>     import core.memory : GC;
>     GC.disable();
>     while(stuff)
>         loop();
>     GC.collect();
> }
>
> Also see EMSI containers for no gc containers with deterministic destruction https://github.com/economicmodeling/containers

Thanks for mentioning the containers, that's exactly what I needed !

Then I think it's worth trying...

This week end I'll try to generate the D wrapper for Urho3D and test how to load some scene resources in the background.

> If this isn't a perfect example of D's marketing problem I don't know what is. Someone who likes D and takes the time to write on the forum yet thinks the GC will randomly run no matter what.
>
> To make it abundantly clear: I'm not bashing on you in the slightest, Rico Decho. I'm just pointing out that there's a clear problem here in that we can't expect to convert e.g. C++ game developers who have never written a line of D before if we haven't even managed to educate the community yet.
>
> Unfortunately, I have no ideas on how to remedy the situation. I also don't know how to get people to stop believing that C is magically fast either, which I think is a similar perception problem.
>
> Atila

Actually it's written in the documentation.

If I remember well the garbage collection could be triggered during any allocation, for instance when concatenating some displayed text, and freeze all threads until the garbage collection is done.

In my opinion, the problem is D's GC implementation.

For instance, Nim uses a soft (realtime) GC, which is why Nim's author himself has made the Urho3D wrapper :)

With this approach, no need to disable the GC and make manual allocations to avoid that the GC freezes all threads.

Instead you simply use all the standard libraries as normally, while still try to avoid allocating too much stuff during the rendering of course.

During the render loop, in Nim you occasionally call the GC with an numeric argument telling how much milliseconds it is allowed to use in the worst case.

For instance, you ask for GC when the game is in a menu or after a background resource loading.

That's the simple and clever way of using a garbage collected language for game development.

On Monday, 6 March 2017 at 15:40:54 UTC, Rico Decho wrote:
> If I remember well the garbage collection could be triggered during any allocation, for instance when concatenating some displayed text, and freeze all threads until the garbage collection is done.

My understanding is that GC can be triggered only when you do an allocation with GC memory. And if you use @nogc (which to my knowledge works) you cannot call anything that might trigger a garbage collection.

https://dlang.org/spec/attribute.html#nogc

On Monday, 6 March 2017 at 06:39:27 UTC, Jack Stouffer wrote:

> void loop() {
>     // code
> }
>
> void loadLevel() {
>     import core.memory : GC;
>     GC.disable();
>     while(stuff)
>         loop();
>     GC.collect();
> }

GC.disable doesn't guarantee the garbage collector won't run: https://dlang.org/phobos/core_memory.html#.GC.disable I'm not sure how much impact that has in practice.

On Monday, 6 March 2017 at 14:49:42 UTC, Atila Neves wrote:
> Unfortunately, I have no ideas on how to remedy the situation. I also don't know how to get people to stop believing that C is magically fast either, which I think is a similar perception problem.

Writing up a detailed example with code showing how to avoid the GC in the most common situations, posting it on Reddit, and then making it easy to find on dlang.org would be a good start. Given the importance of these issues, it should be one of the first things you see on the homepage.

On Monday, 6 March 2017 at 16:42:50 UTC, bachmeier wrote:
> Writing up a detailed example with code showing how to avoid the GC in the most common situations, posting it on Reddit, and then making it easy to find on dlang.org would be a good start. Given the importance of these issues, it should be one of the first things you see on the homepage.

That's a great idea. In fact, I'd like to see multiple examples, with many different approaches to manual memory management, going over the common problems (e.g. "How do I do a writefln in a @nogc block?") and how to solve them in idiomatic D. Something like Rust's guide to unsafe programming. This set of examples could be extended as the upcoming DIPs dealing with resource management make it into D compilers.