A lot of people are arguing (especially on Discord) that @nogc should be discarded entirely in favor of betterC.

Here are my thought on the subject:

• When it comes for the standard runtime and library, for the most part, yes, but maybe keep around @nogc for the occasional student that wants to get into real-time stuff like audio development early on, as an option.
• Due to (a world stopping) garbage collection is interferring with real time applications, my solution for that are community-driven runtimes for each target application, many of which already exists.

My only concern with the latter is, that people could pull yet another case of D1/Tango, if some people are really stubborn about doing everything their own way, thus stuff have to implemented multiple times. While competition can be a good thing and lead to multiple choices of the end user, it can lead to self-sabotage. On the other hand, people can just fork each others code then refine them to the target runtime.

I'll look into some of those already existing runtimes, then think about how should I proceed, as I decided I would need something custom for game development. Came to D because I didn't want to bother with header files in C/C++, stayed because alternatives like Rust and Zig have their own issues, and I'll stay because I want to believe in the future of the language.

On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

My only beef with @nogc is that too many parts of Phobos aren’t @nogc-compatible even if they can be in principle.

On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

If they want to use betterC, why not just let them use betterC? If you want to use D features not in betterC, then @nogc is helpful, no?

On Friday, 6 September 2024 at 13:05:15 UTC, jmh530 wrote:

Actually the point was to kill both :)
Because it make harder for internal things in compiler

On Friday, 6 September 2024 at 13:11:41 UTC, Sergey wrote:

Until dlang has several explicit full time mantainers for supporting for every new arch, killing nogc would make the shit situation of broken and pretend support of embedded and wasm completely unthinkable.

D will not be getting the man power for that, so nogc needs to stay

On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

May I remind people that one of dlang's big sponsors is Weka, where @nogc is used extensively to achieve high performance where it matters, in combination with less performance-critical code that is allowed to use the GC.

D is used by serious companies, not just students.
https://www.reuters.com/technology/data-platform-firm-wekaio-notches-16-bln-valuation-after-lastest-funding-round-2024-05-15/

-Johan

On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

For real time audio the actual audio processing will either be in an OS callback, or a host callback in the case of a plugin. In both cases the "audio thread" will be an external thread that D runtime does not know about. And the only actual code that needs to be @nogc, (and no malloc etc), is in that callback. Just the actual audio processing code, well maybe some others in a plugin situation, stuff like events, automation will typically be delivered in the real time thread.

So you don't need the whole app to be @nogc, just the real time parts, and they will typically be less that 10% of the codebase.

So the "lets just remove the GC completely", or "just use a custom runtime", might be a good solution in some cases, but its a sledgehammer to crack a nut solution for others.

And tbh I don't see what it fixes? The problem, or what people are complaining about is that trying to make everything @nogc compatible puts a burden on people who don't care about it.

You don't need a custom runtime to fix that problem. You just need to stop trying to make all the things @nogc compatible. If it adds no baggage / burden to GC users then sure fine, but just accept D is a GC language, some of its core language features rely on GC, some of the stdlib will use GC.

I don't see massive amounts of posts from people complaining that this or that in the stdlib isn't usable in @nogc code?

Maybe its not a problem that needs fixing, or maybe @ogc people expect to have to do some extra work themselves.

On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

I am fine with how things are, but here are some ideas.

I am OK with removing @nogc because it's annoying to use and a bit useless. It kind of forces you to take a side, even though nogc code can work with gc code.

BetterC is weird, but it does do something. If @nogc were to be removed, BetterC could act as a replacement for those who want to avoid using the gc and enforce that at compile time.

On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

Please, just a big no.

/P

On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev wrote:

How do you replace this code with BetterC? Answer: You don't.

import std;
void main() {
    writeln(add(3, 4));
}
@nogc int add(int x, int y) { return x+y; }

The use cases of @nogc and BetterC are very different. With BetterC you lose classes, dynamic arrays, and associative arrays, among other things.