[WalterBright]

> language features that require said GC

A whole two features:

1. concatenating strings using the ~ operator. You can concatenate strings using malloc if you prefer.

2. closures that escape the context of the function they enclose. Instead, write a struct with fields representing the values, and make the lambda a member function of that struct. Allocate the struct instance any way you wish.

The GC is a convenient feature with lots of nice uses. Programming in D is not impaired by not using it.

[Corazoor]

Maybe something changed, but I thought array concatenation with ~, associative and dynamic arrays as well as exceptions rely on the GC as well.

It's a short list, for sure, but thats not the point: Anyone looking into using D without GC will see that there are some language features that require special care.

At that point it becomes a valid question why one should learn about the pitfalls of GC free D, when one already knows that about the currently used language.

GC free D is low friction, but seemingly not low enough for uptake from interested parties.

[aldacron]

> array concatenation with ~, associative and dynamic arrays as well

Yes. Walter was referring to the operator itself. Strings are arrays.

> as well as exceptions

It's not exceptions themselves, but the `new` operator. It directly allocates from the GC. That said, there is a plan to enable @nogc exceptions.

> At that point it becomes a valid question why one should learn about the pitfalls of GC free D, when one already knows that about the currently used language.

People who already know another language and are happy with it have no reason to switch. Why would they? It's people who aren't completely satisfied with a given language that are going to be more open to looking at others. And so of course then it's a matter of weighing pros and cons. Do I like the syntax? Does it feel intuitive? Am I comfortable using it? Do I find the pain points blockers or minor annoyances?

There is nothing special about D in this regard. If you aren't looking for a new language, you aren't going to try it. And if you are, you either like it or you don't.

WekaIO wrote the world's fastest filesystem in D. They did it without the GC, and went so far as to write their own GC_free standard library (which they open sourced). Their CEO talked about why in this interview:

https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-...

That said "GC-free D" is not a major selling point of the language. You will not find the maintainers recommending anyone start a D project fully GC-free unless there is a very specific use case, like that of WekaIO or the blog post author. The allocation patterns in D are different than they are in Java or C#, it's clearly defined when a collection may trigger, the @nogc attribute provides compiler enforcement for avoiding GC allocations in specific functions, a command-line switch can warn you about the same if you find @nogc too much to think about (because employing @nogc does require more consideration of your architecture), and other switches can help minimize the impact of GC.

So the tools are there for anyone who needs them. There are definitely rough edges and we are forever in need of improvement, but everything is usable and people are using D in production right now.

[WalterBright]

> That said, there is a plan to enable @nogc exceptions.

It's been implemented.

[Imperatorn]

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008...

Exists as a preview switch