D on quora ...

[Rion]

On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
> 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

The issue is only mentioned, because it keeps getting talked 
about ( mostly one sided ) on forums and sites like the above 
mentioned quora.com. Its hard to change people there perception, 
without counter arguing. Currently as i write this, these claims 
on quora are unchallenged.

I can make a few simple demos and have D use by default 5 to 10 
more memory then the exact same C or C++ program. While D does 
not actually use it ( its only marked as allocated for the GC ), 
it does not dispel the notion or feeling of people that a GC = 
bad.

Other aspects like being unsure when the GC will trigger can also 
influence people to a non-gc language. The Go developers have 
done a massive ( an impressive ) amount of work on trying to 
reduce GC pauses in the last two years, and that communication 
and effort has helped to reduce the GC myth ( for people looking 
at Go ).

Another part of the issue is, while D can be run without the GC, 
i can not tell what parts of the standard library can work 
without the GC. Even a simple output parsing gave me a compile 
error when running nogc a while ago.

When every new languages besides Rust or Zig are GC. That same 
"flaw" is not looked upon as a issue. It seems that D simply 
carries this GC stigma because the people mentioning are  C++ 
developers, the same people D targets as a potential user base.

D can have more success in targeting people from scripting 
languages like PHP, Ruby, Python, where the GC is not looked upon 
as a negative. The same effect can be seen in Go its popularity 
with drawing developers from scripting languages despite it not 
being there intention.

I always felt that D position itself as a higher language and in 
turn scares people away while at the same time the people it 
wants to attracts, with most are already set in there ways and 
looking at excuses to discredit D. The whole C++ has all of D 
features and does not need a GC / GC is bad excuse we see in the 
quora.com posting fits that description ( and not only there, 
also on other sites ).

If the GC issue can not be tackled and even with the recent 
communication blogs, it still keeps showing up. Is it maybe not 
better to focus the marketing features that other developers ( 
none C++ ) may see as advantages and slow draw then in? High 
performance web development package for instance. Vibe.d does not 
count because has not been seen giving any descent public 
performance in years ( like techempower or other sites ).