Andrei's list of barriers to D adoption

[Carl Vogel via Digitalmars-d]

On Monday, 6 June 2016 at 09:16:45 UTC, Walter Bright wrote:
> On 6/6/2016 1:15 AM, Russel Winder via Digitalmars-d wrote:
>>> * Safety has holes and bugs.
>>
>> Then so does C, C++ and Rust, so this is just a comment made 
>> because it
>> can be made and sounds bad. Bad enough to salve the conscience 
>> of the
>> speaker as to why they are not already using D.
>
> It's pretty clear when they say that, and then continue using 
> C++ which has no safety, that safety isn't the real reason.
>
> Reminds me of an anecdote Andrei is tired of. In the 80s, a C++ 
> developer said that compilation speed, speed, speed is the most 
> important thing in a C++ compiler. This went on until it was 
> pointed out to him that he was using Microsoft C++, which was 
> the slowest at compiling by a factor of 4.
> Clearly, what was actually most important to him was a name 
> brand compiler (social proof), but he needed a more palatable 
> reason, so he just latched on to one without much thought.
>
> We have to be careful about being led down the garden path by 
> people who say "I'd use your product if only it did X." I have 
> a lot of experience with that, and it's very rare that they'll 
> use it if you do X. They'll just respond with "yeah, ok, but 
> what I really need is Y." This process never ends. Sometimes 
> it's because they're embarrassed by the real reason, sometimes 
> they just take pleasure in you dancing to their tune.
>
> Paying attention to our existing users is a much more reliable 
> source of information.

I think this is a really important point and I 100% agree with 
Walter. Also, the idea that more people will adopt D if you just 
"get rid of the GC" ignores the fact that you don't just "get rid 
of the GC," you replace it with another memory management scheme 
(manual, RAII, RC). If you replace all the parts of the language 
and phobos that rely on GC with, e.g., a poor implementation of 
RC, then you're just going to get another round of complaints, 
and no real adoption.

In my experience, GC complaints are split between existence and 
implementation. Some folks are dead against and GC code, others 
just don't like how the current GC works. In my world---which is 
not AAA gaming or HFT, but is still very concerned with 
performance---a GC is tolerable, but a clunky stop-the-world GC 
with big unpredictable pauses is less so. Having a high quality 
GC that can be avoided (with some agreed-to and well-documented 
limitations) would be great.

My concern is that the kill-the-GC craze is going to fall into a 
second-system trap, and be replaced with buggy 
half-implementations of, say RC, that I can't rely on, or will be 
combing through piles of stale bug reports about in 6 months.

I believe a big issue for D, and for any not-mainstream language, 
is being straight about what works and what doesn't. D is not 
alone in this, but I often feel I'm sold on features that I later 
find out are not fully implemented or have big holes in them. The 
limitations themselves aren't the problem---the trust is the 
problem. I never know if I can tell someone else "D can do that" 
safely (turning off the GC is a good example---it took me weeks 
of reading forums and documentation to see how practical that 
really was after initially reading that it was straightforward.)