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.