Andrei's list of barriers to D adoption

[Shachar Shemesh via Digitalmars-d]

On 06/06/16 07:17, Adam D. Ruppe wrote:
> On Monday, 6 June 2016 at 02:30:55 UTC, Pie? wrote:
>> Duh! The claim is made that D can work without the GC... but that's a
>> red herring... If you take about the GC what do you have?
>
> Like 90% of the language, still generally nicer than most the competition.
>
> Though, I wish D would just own its decision instead of bowing to Reddit
> pressure. GC is a proven success in the real world with a long and
> impressive track record. Yes, there are times when you need to optimize
> your code, but even then you aren't really worse off with it than
> without it.

Weka thought so too, at first. We said there are two kinds of components 
where it is okay to use the GC:

* Long living objects (where the GC won't matter, because they are not 
freed anyway)
and
* very small objects.

The thought was that, with these two constraints, the GC won't matter. 
We can run it infrequently, and all will be fine.

Turns out, we were very very very wrong.

The problem with the GC is that its run time is proportional not to the 
amount of memory it frees, but to the amount of memory it needs to scan. 
This number is vastly different than the first one. Without keeping this 
number low, the GC freeze time runs into the high milliseconds range.

So we changed course. We are now trying to minimize the total use of GC 
memory. This, with lots of other tricks, would, hopefully, allow us to 
get the GC run time to very very very low, maybe even not run it at all.

However, saying that the GC makes you no worse is simply false.

Shachar