[Corazoor]

Certainly not the sole reason, but the mix of language features puts it into a weird spot: You have great control over memory layout and can easily embed assembler, which would be perfect for performance sensitive software like games. Yet "default" D comes with a garbage collector and - more importantly - language features that require said GC.

If you want to go the noGC route, you have to refrain from using certain language constructs, which puts you in a similar spot as with C++...

And if you actually want a GC, you might find the simple linear allocator of D to be lacking...

D is a very cool language, but it is also a lot like QTified C++... Which, well, already exists...

[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

[mhh__]

I'm surprised you mentioned memory allocation without spotting the memory allocators in the standard library. Andrei designed the library and as far as I can tell no other language comes close when it comes to composable allocators.

[Corazoor]

I dunno why you assume that I don't know about them...

Apart from that, they came pretty late, are still in experimental, and don't change the fact that only a subset of D is usable without GC.

I very much like D, I really do, but I never encountered a usecase where the pros of using D outweight the cons. It sits in a very very weird spot design-wise, and while Walter and Andrei tried their best to get rid of the most common problems, not much of that effort resulted in actual useful change: Still no other GC than the default linear one, the stdlib is still not fully noGC usable (and probably never will), and "proper" compile time functions are still not done, after quite a few years now...

Which is a shame, D is very close to being the perfect C++ replacement.

[WalterBright]

If you don't want to use the GC, why the concern about its implementation?

I have no idea what you mean by "proper" compile time functions. D's CTFE is excellent.