D on quora ...

[Ecstatic Coder]

On Friday, 6 October 2017 at 21:12:58 UTC, Rion wrote:
> 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 ).

+1

But you are losing your time trying to convince D's management 
that targeting C++ developers instead of scripters is a marketing 
error.

For instance, I AM a C++ developer, and I use D EXCLUSIVELY for 
SCRIPTING tasks. Nothing else.

And if you had asked me why I use D then, I would have answered : 
it's because it's faster and more effective than 
JavaScript/Node.js, Python and Ruby for these tasks.

GC IS NOT A PROBLEM for scripting. We don't care about that. GC 
IS NEEDED for scripting languages.

But as a C++ developer, I can tell you that : D's GC is what 
prevents me to use it for my current C++ programming tasks.

Because I can perfectly live with a GC that progressively 
collects bits of memory in a predefined amount of time, like in 
the Nim language, but not one that can pause my application for 
an unpredictable amount of time.

That's just my personal case and opinion, but I don't think I'm 
the only C++ programmer on the planet to dislike D's GC for 
typical C++ development cases, which are generally those where 
the lack of a GC is the reason that lead to the use of C++.