Earlier quoted context omitted.
I also came from Python (15 years of experience) to Go and I think newcomers to Go index too hard on terseness. The for-loop equivalent for a map over a list is more characters, but it's really straightforward and easily recognizable in the code. In the general case, I'm glad that Go doesn't try to explore new PL territory, optimizing instead for things that are known to improve developer productivity. None of this i…
For me, it's not a question of terseness -- it's more about communicating intent, and not polluting the scope with incidental variables. Everyone knows what map/filter/reduce do. When reading new code, seeing "map" is better than seeing a for loop: you don't have to think about the underlying iteration at all, you can skip directly to the essence of the transformation. As a side effect of this, when you do see a for…
A mapping for loop doesn't pollute scope with incidental variables:
results := make([]Result, len(input))
for i := range input {
results[i] = callback(input[i])
}
Moreover, if you don't care about terseness, you can always pull this out into a well-named function or annotate it with a comment.
> Everyone knows what map/filter/reduce do
In isolation, but for complicated chains of map/filter/reduce (especially with error handling logic in languages which return errors rather than raising them as exceptions) it's much easier for me to read the corresponding for loop equivalent. Even my colleagues at a Python shop had limits on the complexity of list comprehensions beyond which point they were required to rewrite into a for loop because while packing that complexity into a single expression is elegant and clever, it's not particularly readable or easy to understand.
I guess my view can be summarized as: for very simple cases, map/filter/reduce are a bit clearer, but for those same simple cases a for loop is still easily understood and a for loop's readability scales better with complexity.