(no title)
Corazoor | 4 years ago
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|4 years ago
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|4 years ago
It's been implemented.
Imperatorn|4 years ago
Exists as a preview switch