Andrei's list of barriers to D adoption

[poliklosio via Digitalmars-d]

On Tuesday, 7 June 2016 at 08:57:33 UTC, Russel Winder wrote:
> On Mon, 2016-06-06 at 19:57 +0000, poliklosio via Digitalmars-d 
> wrote:
>> […]
>> 
>> I should have been more specific here. I mean I want to 
>> elliminate GC in my code. I don't mind if you or anyone else 
>> uses GC. Even I use GC languages when writing things like 
>> scripts, so I'm not a no-GC-because-I-say-so person.
>
> Indeed. D has a GC by default which can be switched off. This 
> is good. That D needs a better GC is an issue.

For me a much bigger issues are:
- Smaller power of the language with GC switched off.
- Mixing GC and noGC is still experimental thing that few experts 
know how to do properly.

Better GC is not a bigger issue for me as I'm not going to use 
much of it.
Better GC is of course advantageous for adoption, I just have a 
strong impression that there are more important things, like 
nailing easy setup of editors, and providing a guide for 
programming **without** the GC and for mixing GC and NoGC.

You have to distinguish switching GC off (that implies 2 
languages, 2 communities, 2 separate standard libraries, all with 
some overlap) from being able to mix GC and non-GC code in the 
same program. The problem is that AFAIK the second is not a 
viable methodology outside a tightly controlled environment, 
where you select used libraries very carefully and limit their 
number.

>> (...)
> My feeling is there is no point in over-thinking this, or being 
> abstract. C++ can have a GC but doesn't. Rust can have a GC but 
> doesn't. Python has a GC. Go has a GC. Java has a GC. D has a 
> GC that you can turn off. That seems like a USP to me. Whether 
> this is good or bad for traction is down to the marketing and 
> the domain of use.

I'm trying to be as far from abstract as I can. Having GC is 
hardly a unique selling point. As for switching it off, see 
issues above. After they are solved to a point when experts can 
get noGC stuff done easily, it will be a USP.

>> D's power is in its native-but-productive approach. This is an 
>> improvement in C++ niches, not a simplified language for 
>> banging end-user apps.
>
> Productive is way, way more important that native.

For some people native is necessary. For them D is the way to get 
productive. Others ideally would use D as well but currently 
there are more productive options for them, like C# or python.

> […]
>> 
>> Why would they not use D? D is a much better language for them 
>> as well. To give some examples, in C++ code there is a ton of 
>> boilerplate, while D code hardly has any. Also, the number of 
>> bugs in a D program is smaller due to easier unittesting. 
>> Also, templates don't cause day-long stop-and-learn sessions 
>> as in C++. I don't think those people are a lost market.
>
> Can we drop the unit and just talk about testing. Unit, 
> integration and system testing are all important, focusing 
> always on unit testing is an error.

There's nothing wrong with discussing unittesting on its own. In 
fact, this is very relevant because its the unittesting that D 
makes easier. More coarse-grained testing can be done as easily 
in any other language - you just make some executables for 
various subsystems and variants of your program and run them in 
test scenarios.

> As to why not use D? The usual answer is that "no else is using 
> D so we won't use D" for everyone except early adopters.
>
> D needs to remanufacture an early adopter feel. It is almost 
> there: LDC announcing 1.0.0, Dub getting some activity, new 
> test frameworks (can they all lose the unit please in a 
> renaming), rising in TIOBE table. This can all be used to try 
> and get activity. However it needs to be activity of an early 
> adopter style because there are so many obvious problems with 
> the toolchains and developer environments. So let's focus on 
> getting these things improved so that then the people who will 
> only come to a language that has sophistication of developer 
> experience.

As long as those are improvements in getting started fast and 
time-to-market for D apps, than yes, and that's probably 10 times 
more important than the both slow GC and poor noGC experience.

>> This is a big issue now due to lack of a comprehensive guide, 
>> as well as holes in the language and phobos (strings, 
>> exceptions, delegates). C++ doesn't have those holes.
>
> Holes in Phobos can be handled by having third-party things in 
> the Dub repository that are superior to what is in Phobos.

I don't think that third-party libraries can have the reach of 
Phobos libraries. Also, things as basic as strings should be in 
the standard library or language, otherwise the whole idea of 
using D looks ridiculous. Having said that, third-party libraries 
can help.

> Documentation, guides, and tutorials are a problem, but until 
> someone steps up and contributes this is just going to remain a 
> problem. One that will undermine all attempts to get traction 
> for D. So how to get organizations to put resource into doing 
> this?

I think those things can be easily done by individuals as well, 
as long as pull request are accepted. But of course until someone 
steps up... :)