Andrei's list of barriers to D adoption

Mon Jun 6 01:15:42 PDT 2016

On Sun, 2016-06-05 at 19:20 -0700, Walter Bright via Digitalmars-d
wrote:
> […]
> 
> * The garbage collector eliminates probably 60% of potential users
> right off.

And i bet over 80% of them are just saying this based on zero evidence,
just prejudice. 

Go went with the attitude "Go has a GC, if you cannot deal with that
#### off". Many people did exactly that and the Go community said
"byeeee". Arrogant this may have been, but Pike, Cox, et al. stuck to
their guns and forged a community and a niche for the language. This
then created traction. Now GC in Go is not an issue. 

D has a different problem in that it is not a new language, it cannot
ride a "new language" hype wave to get over knee-jerk opinions.

D needs t make it clear there is the normal GC approach proven to work
fine over the years, just look at Go, and there is the GC-less mode for
those that really do need absolute control over all memory management.
If D does not have this then C++ and Rust win.

If GC-less D is a problem then why not let people who want absolute
control of memory at all times go to another language, e.g. C, C++,
Rust. They will anyway.

So maybe get rid of CG-less mode as Go has done and not try to make D a
language for people who are already prejudiced against GC and for C,
C++ and Rust?

Ig GC is a problem for these people, let them go.

> * Tooling is immature and of poorer quality compared to the
> competition.

This is true. 

We have too many half-finished attempt at things, basically because
everything is volunteer, not directly associated with work, activity.
Nothing wrong with this per se, but an obvious explanation why it is
so. Unless an oirganization or seven put some work-oriented effort into
the tooling, nothinkg will change.

I would suggest three ways forward:

1. Get effort on the IntelliJ IDEA and CLion plugin. Kingsley has made
a start. I suggest using his work as a basis and doing a new version
written in Kotlin instead of Java. Kotlin will be easier than Java for
D people to work with and easy for Java people to work with.

2. Get effort on the DDT Eclipse plugin. Bruno has declared it
finished, which is fine, but I would say it should not be treated that
way.

3. Have one lightweight D realized cross platform IDE. Qt us probably
the best widget set to use for this. My model here is LiteIDE which is
a Qt-based Go IDE realized in C++. It should of course be realized in
Go, but there are no Qt bindings for Go, only QML ones.

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

What does safety mean here anyway. C++ safety perhaps?

> * Hiring people who know D is a problem.

Definitely.

But this is also an excuse since there were no Go programmers, no Rust
programmers, no C++ programmers, yet now there is no problem. The point
here is that a few organizations just need to take a public stance on
using the language to create a buzz and traction either happens (as
with Go) or it doesn't.

> * Documentation and tutorials are weak.

True. This is a resourcing issue. Go had full resourcing from Google,
and then later others, to get to the state they have – which is not
half bad.

> * There's no web services framework (by this time many folks know of
> D, but of 
> those a shockingly small fraction has even heard of vibe.d). I have
> strongly 
> argued with Sönke to bundle vibe.d with dmd over one year ago, and
> also in this 
> forum. There wasn't enough interest.

vibe.d is not a full Web services/applications framework in most
people's eyes, it is just the event loop. I guess it is like saying
Node is a framework without recognizing the importance of npm and the
library of REST, SQL, and other components. Another analogy would be
saying Flask is a web framework without pip, SQLAlchemy, etc.

> * (On Windows) if it doesn't have a compelling Visual Studio plugin,
> it doesn't 
> exist.

I guess Windows people are so wedded to Visual Studio this is true.

> * Let's wait for the "herd effect" (corporate support) to start.

Seems reasonable to me. Why should organization X take a risk if
organization Y hasn't already. This is the position of businesses
doomed to failure. Without some risk taking there is no new business
and hence no growth, not even status quo.

So target this decade old technology at less risk averse organizations.
Likely this means SMEs, probably small businesses (or small business
units within bigger businesses) simply because they are generally less
risk averse.

> * Not enough advantages over the competition to make up for the
> weaknesses above.

A position clearly based in a total lack of knowledge, probably of the
technology they are currently using. This attitude is simply the risk
averse position in another guise.

It is worth taking note of these and learning from them, clearly. But
perhaps D as a language and community should be less defensive about
the language and its position in the world. Let's stop the "it's a
better C++" line, that is clearly a dead route to traction. Let's take
lessons from Go, Rust, Kotlin. Find the things that D does well, in the
organizations that use it and push those.

Go came along as a systems programming language for Google interns to
do productive work and not get things wrong. It has ended up as a
premier Web programming language and other things taking market share
from PHP and Python as well as C. Yes it had the "better C" angle but
it did not agamize about how to move people from C. Yes it had Google
and hype, but it gained traction both because of that and in spite of
that.

Rust is pushing the "Rust is a better C++ but with memory safety" the
fact that it is a quasi-functional language isn't being made enough of.
Many people are blocked from using current C libraries because of many
features of Rust. So for example trying to use GStreamer from Rust is
noted as being fundamentally impossible by the core GStreamer team, and
they have been trying – to the extent of having to contemplate a new
implementation in Rust. D has a big win here as it already has a fully
working GStreamer adapter API – though I wish it were not a part of
GtkD but a separate thing.

So where should D go? Let's cease the defensive attitude of trying to
compete with C++ where C++ is entrenched. Let us take D out to people
as a native code language with a declarative feel that has excellent
data structures and algorithms, concurrency, parallelism; a language
good for computation. Many in finance are already using it. Market
their usage, leave the defensive approach and promote the organizations
who have taken the risk so other organizations can see what they have
done.

-- 
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/20160606/b40d2bc2/attachment.sig>