A few notes on choosing between Go and D for a quick project

[Carl Sturtivant via Digitalmars-d]

Characterizing the problem as "Go versus D" is framing it to D's 
disadvantage. Broadly speaking Go is one thing & D is many things.

The whole difficulty with D encountered by a person choosing 
which of (e.g.) Go and D to use lies in this difference. D as a 
whole is overwhelming in this situation.

D may be spoken naturally in many different ways. This is its 
strength. We need to make this strength accessible to outsiders. 
If an outsider can speak D at first in a way somewhat familiar 
from their previous experience, that will provide accessibility.

We may classify outsiders as coming from C, C++, Java, Python, Go 
and more. Make your own list.

Each kind of outsider needs to see an approximate reflection in D 
of the machinery of their usual means of expression and its 
attendant conceptual models, plus exciting possibilities to 
improve and extend these. This reflection must be made workable 
on all scales, from details of idioms and techniques up to the 
big picture.

An outsider needs a well developed specialized way in! One that 
is designed for that specific class of outsider. Given such, in 
the short run the D written by one class of outsider will be 
quite different in its use of the language to that written by 
another, which will be quite different again to that written by 
contributors to phobos.

We should accept this. They may expand their horizons within D 
later. The community may find ways to help such people do this, 
for example by gently suggesting better parts of D to use for 
technical parts of their purposes when they post to the forums. 
In the meantime they have come to D because there was a 
relatively efficient way for them to do that, not a bewildering 
collection of possibilities that deflected them to the 
certainties of the overly prescribed ways of (e.g.) Go.

Now consider outsiders from C, C++, Java, Python, Go.

I'll leave you to consider C, C++. The articles
   http://dlang.org/ctod.html
   http://dlang.org/cpptod.html
   http://dlang.org/pretod.html
have made a detail-oriented start with tacit assumptions about 
what is going on at wider scales. These languages are closely 
entangled with D's development, and so are special cases given 
better treatment. These could be expanded into an entire 
introduction to D for C outsiders and an entire introduction to D 
for C++ outsiders.

Java is not too hard especially given the design of D's classes. 
Java is almost a small sublanguage of D.

Python and Go are harder. But D is a system programming language 
with [long list of powerful abstraction facilities, many 
supported paradigms, "wonderfulness of D"]. And as such one may 
hope it is possible to arrange to program in D in Pythonesque or 
Goish ways. Especially if this provides a way for D to win rather 
than lose out to these languages, by providing an incremental way 
in.

The yield facility in Python can serve as a first example here. 
This is not a part of the D language. The Fiber class in 
core.thread can be made to emulate it with additional 
superstructure with some effort. But this is exactly the kind of 
effort an outsider from Python is not immediately equipped to 
make. Go's goroutine and its attendant machinery could be 
examined with a similar end in view.

What all of this suggests is that some library code may need to 
be written to accomodate the way into D for a class of outsiders. 
The administration of where such goes needs to make it simple to 
import with a standard D installation. And if D is too inflexible 
to provide something important via a library, as is possibly the 
case with yield, serious consideration should be given to (don't 
scream) adding it to the language.

In conclusion, D is not gaining the traction it deserves as a 
potential lingua franca. I am making the case that we need to 
treat it as several programming languages for the purpose of 
making it rapidly usable by typical outsiders. D-python, D-java, 
D-whatever --- facets of D.

This entails library additions, and possibly language additions. 
This entails a lot of writing of documentation, in effect a small 
book for each facet of D.

There is much to be decided about how this could be best done. I 
will not pursue that here. But I do believe something 
approximately like this is the only way for D to start to win out 
when someone decides whether to use (e.g.) Go or D in a new 
situation, or even whether to use D or stay back in Python with 
all of its disadvantages. The complex cliff face of D needs some 
overtly navigated paths for all kinds of explorers.