A reason to choose D over Go

[Martin Nowak via Digitalmars-d]

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

http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/#tips

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.

https://github.com/buger/gor/pull/149/files#diff-b8b346beabeabdf0fca6f0b6893ce82bR42

That's what you would write in other languages.

```py
if "chunked" in request.transfer_encodings:
    return
```

```ruby
return if request.transfer_encodings.include? 'chunked'
```

```d
if (request.transferEncodings.canFind("chunked"))
    return;
```

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

There exists some functionality for sorted arrays (only int, float, and
string), but that isn't applicable here.
http://golang.org/pkg/sort/

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.