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

[Chris via Digitalmars-d]

On Tuesday, 17 March 2015 at 21:16:38 UTC, Carl Sturtivant wrote:
>
>
> 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.

I think this is a good approach. The beauty of D is that it can 
be a lot of different things to different people. Do you have any 
examples yet, as in "D for Python programmers"? E.g. loops:

Python:
for item in list:
   print "The item is %s" % item

D:
import std.stdio : writefln;
foreach(ref item; list) {
   writefln("The item is %s", item);
}