A reason to choose D over Go

Martin Nowak via Digitalmars-d digitalmars-d at puremagic.com
Sat Mar 21 15:15:48 PDT 2015

This blog post describes what to consider when switching from python to go.


It's very interesting, because the long list of things to give up for
more efficient go code reads like an argumentation against choosing go
from a D perspective.
And given that D is on par with Python's expressiveness, we should
really emphasize this aspect.

I recently made a pull request for a go tool and spent about half an
hour trying to find some function to test whether an array contains a
particular element. I also asked on #go-nuts to confirm I didn't miss
anything, but you're really supposed to write an explicit loop.


That's what you would write in other languages.

if "chunked" in request.transfer_encodings:

return if request.transfer_encodings.include? 'chunked'

if (request.transferEncodings.canFind("chunked"))

const auto& arr = request.transfer_encodings;
if (find(arr.begin(), arr.end(), string("chunked")) != arr.end())

There exists some functionality for sorted arrays (only int, float, and
string), but that isn't applicable here.

While go will hardly ever have good support for algorithms, because of
the lack of overloads and generics, they also choose against adding such
trivial, but often needed, algorithms to the basic types.
With a functional programming (or C++ algo) background, I find this very
hard to get used to.
Repeatedly writing out such trivial code often mixes different levels of
abstraction and is one of the reasons why go code is so noisy, manual
error code handling being another one.

More information about the Digitalmars-d mailing list