Andrei's list of barriers to D adoption

[Russel Winder via Digitalmars-d]

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.

> Is it a unique selling point (USP) against C++ or Rust? I don't 
> think so. People who use the GC languages for business/scientific 
> apps don't care what is behind the scenes. Also, the relationship 
> between GC and productivity is a subtle point that requires some 
> CompSci background to grasp. I think D is far too complicated to 
> be marketed as even simpler than python or Go. Low-latency people 
> do care what is behind the scenes and they understandably want no 
> GC. That leaves high-performance high-latency people. If you 
> think you can find a niche there, fair enough, otherwise its not 
> a USP.

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.

> 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.

[…]
> 
> 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.

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.

> 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.

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?

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20160607/6d7d2e3e/attachment-0001.sig>