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

cym13 via Digitalmars-d digitalmars-d at puremagic.com
Sun Mar 15 18:22:46 PDT 2015


If stories are wanted, I might as well tell mine.

It is not a success story but as a newcommer to D I feel like 
writing it down somewhere before forgetting my first impressions. 
But first, a bit of background.

I'm a CS student and an autodidact before that. I grew up with 
GNU/Linux and never worked with a Windows environment. My first 
languages were bash with which I discovered programming, a 
Scheme/Lisp (SICP) for which I did not really found it any useful 
use at the time and python in this order. I had later to learn C, 
C++, java, D and many others but bash, Scheme and python defined 
my vision of programming.

 From bash I got the Unix philosophy (simple bricks that combine 
well) and a taste for interactivity and incremental development. 
SICP gave me the mental framework needed to tackle real 
programming and a taste for functional programming. Python gave 
me a language that combined almost anything I liked from bash and 
scheme (well... I still miss my pipes) and the access to the best 
ecosystem I know about. Great and very specialized libraries, a 
mostly FOSS-oriented community, great package management (pip), 
great online docs (always clear, good search functions, 
examples), virtualenv, many repls and a *lot* of articles and 
videos on the internet. Most of all it achieved its supreme goal 
of readability.

I've been using python for many years now, mostly on little 
projects because I feel like it.

Today my time is mainly divided between teaching, software 
auditing and reverse-engineering. In the field of offensive 
security only two languages count: C for understanding low-level 
code and manipulating library structures directly and python for 
everything else. Its dev speed and *really really good* libraries 
(scapy...) make it the way to go for many.

So why use D? Well, one day I grew tired of python and almost at 
the same time I had a project that had a need for performance. I 
had tried calling python in C before and it is such a ugly mess 
that I wanted to do anything to avoid that. There are other ways 
to link the two (FFI...) but mixing python and C in the same 
files didn't feel very comfortable. Python's strength is its 
readability, putting C in it would defeat the purpose.

I had a look at Go, Rust and such but they didn't impress me at 
the time. Frankly, the one thing that sold D to me was that 
snippet on the wikipedia page:

import std.stdio : writeln;
import std.range : iota;
import std.parallelism : parallel;

void main()
{
     foreach (i; iota(10).parallel) {
         // The body of the foreach loop is executed in parallel 
for each i
         writeln("processing ", i);
     }
}

It is funny because I didn't actually have any opportunity to use 
yet it but it just felt so much like python and yet was so much 
better (python's multiprocessing is not its best point).

It is anecdotic but after reading everywhere about how fast is 
compiling D, I was very surprised to see it taking 2s for a 
regular "Hello World". I understand it better now but at the time 
I was disapointed.

Porting my python code was interesting. I could basically get 
quite the same expressiveness but getting to it was harder. At 
first I couldn't use the D documentation at all, because all the 
constraints on functions were really frightening, so my first 
documentation was actually the site 
http://rosettacode.org/wiki/Rosetta_Code where I learned many 
basic constructs.

HINT 1: this site is great, either link to and nurture it or do 
something similar on dlang.org

HINT 2: it took me about a month and a good tutorial on templates 
(btw, thanks G.Willoughby) to start understanding the full 
prototypes of standard functions. I really recommend putting the 
constraint part in slight grey so that it is still here and 
readable but the immediatly useful part of the prototype stands 
out.

HINT 3: no beginner cares about how exactly it is compiled or 
advanced metaprogramming options. This should not be more than 
mentionned in a "getting started" page. It is cool stuff, it 
should be said, but it definitely does not fit in an introduction 
to any language.

The more I used D, the better I liked its functional side (UCFS 
<3) and its safety. And the fact that it has ranges everywhere is 
great, but I still wonder why in a language that wants to use 
ranges everywhere they are so complicated to build... Not 
everybody wants to build a struct for everything. Python has 
generators everywhere, why is that? Because the syntax is easy 
and simple. Either use yield like you would use a return, either 
build one on the fly with generator expansion:

for i in (2*x for x in range(100) if x%3==0):
     print(x)

The closest I could find is foreach over a function, which is 
cool but not as easy as yield. InputRange can do more than simple 
generators but a "real" yield would cover the 90% case IMO.

But right now the real reason why I hesitate advising it to my 
friends is because of its stability. I mean, come on! I've only 
been here for something like 5 month and I've seen many 
propositions to add new features and change others. Right now is 
discussed the possibility of changing the default constness of 
variables which would most likely break a lot of code. I can't 
see how a company could think about investing into a project in D 
if they can't have any vision of how long it will be before they 
have to change theyre whole code because "such commenting syntax 
is better" or anything like that.

HINT 4: D is great. It is a good language already. Stop mutating 
it! Fix bugs, improve the standard library, work on the 
ecosystem, reduce compile-time, but do not try breaking things 
all the time. Don't even think of improving yield as I suggested 
before, I'd prefer a standard library based solution at this 
point.

Here is my feeling after some month of D. I know I'm not the 
typical target so don't take it too seriously but I felt like it 
wasn't totally pointless to report my experience.


More information about the Digitalmars-d mailing list