Andrei's list of barriers to D adoption

[poliklosio via Digitalmars-d]

On Monday, 6 June 2016 at 10:54:41 UTC, Guillaume Piolat wrote:
> On Monday, 6 June 2016 at 08:18:20 UTC, Russel Winder wrote:
>> (...)
>> This should be marketed as a major feature of D: the language 
>> with a GC for those situations where you want it, and manual 
>> memory management for those cases where you do not want a GC.
>
> Having the GC for the UI is very pleasant, while @nogc 
> time-critical code won't use it.
>
> It think the problem is that the message then become more 
> complicated.
> GC is easily victim of the "holier-than-thou" fallacy, because 
> evidently less GC is supposed to translate into faster 
> programs. Er... right?

I'm just worried how usable this approach really is at scale. If 
you combine 20 D libraries, 17 of which use GC, are you able to 
control the GC well enough for a low-latency app? The problem 
with GC is that its a global (per process) resource so it poisons 
everything in the program with its unpredictable time 
consumption. I would be hesitant to market this without designing 
and testing a viable development methodology first. And then 
there is reference counting which is another way to be productive 
that doesn't have this problem.