D on quora ...

[Ecstatic Coder]

On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
> On Friday, October 06, 2017 17:14:51 Rion via Digitalmars-d 
> wrote:
>> https://www.quora.com/What-is-your-review-of-D-programming-language
>>
>> It seems that D still has the GC being mentioned up to today.
>>
>> Maybe its better to move the standard library slower to a non 
>> gc version in the future...
>
> D's GC isn't going anywhere. The implementation may be improved 
> or replaced, but there are huge advantages to having the GC 
> (particularly with regards to memory safety), and there _are_ 
> actually times when using a GC is faster than something like 
> reference counting.
>
> We don't want D's standard library to rely on the GC when it 
> doesn't need to, but there are language features that require 
> it and really couldn't work with it, and there are cases where 
> it's going to be involved by default for @safety reasons. For 
> someone who wants to avoid the GC or minimize its use, there 
> are things that they will need to do (e.g. you have to be 
> careful with lambdas and probably use functors or functions, 
> because closures are frequently needed when dealing with 
> lambdas, and that means using the GC; @nogc will catch those 
> cases for you so that you know when a lambda isn't going to 
> work). But while it should be possible for someone to avoid the 
> GC if they need to, that does not mean that we're looking to 
> get rid of it or even have not using it be the default. It just 
> means that we don't want to force its use where that doesn't 
> make sense.
>
> Honestly, I would _hate_ to use D without a GC. Without it, 
> @safe memory managament would not be possible, and you'd have 
> to valgrind everything. As it stands, you only have to do that 
> when you have sections of @trusted code that would potentially 
> be a problem. And there's a lot of code that's cleaner for not 
> having to worry about managing memory.
>
> That's not to say that using the GC is always better or that 
> other solutions are not more appropriate for some circumstances 
> - and the fact that D gives you control over a lot of that is 
> fantastic - but this idea that GCs are always nothing but bad 
> and should be avoided by the plague is just nonsense. GCs have 
> their pros and cons, but they can be fantastic, and idiomatic D 
> programs actually mitigate a lot of the downsides that you can 
> get with a GC, because they do so much with the stack rather 
> than the heap (which is generally better performance-wise 
> regardless of how heap allocations are managed).
>
> Yes, we could use a better GC, but overall, the GC is really 
> just a PR problem and not a real one. Most programs can use it 
> and be plenty performant. And those that can't have the tools 
> necessary to minimize its use or even outright avoid it (though 
> honestly, if someone is looking to outright avoid it, I'd lean 
> towards wondering what the point of using D was in the first 
> place; the proponents of the -betterc stuff still think that 
> it's worth it though). Plenty of folks have managed to write 
> performant programs that involve D's GC.
>
> - Jonathan M Davis

To really compete with C++ on the same grounds, D needs a no-GC 
standard library, which would behave as close as possible as the 
GC-based standard library.

Reference-counting is used a lot in C++ game development, for 
resource management.

In C++, using just strong and weak pointer classes for arrays, 
strings and slices, you can develop programs which look like 
garbage collected code.