Most of the questions about "how do I do X in Go?" are answered with "just write a loop". Yes, that means map/reduce, filter, fold, zip, etc. If writing simple loops gets your hackles up, Go is not the language for you. For me, I worry about the hard stuff, not easy loops.

> If writing simple loops gets your hackles up, Go is not the language for you.

What gets my hackles up is claiming that "it's just the same".

The same argument works for any language that satisfies the structured programming theorem, including assembler.

"If writing simple BNE $reg gets your hackles up, Assembler is not the language for you."

For most people's uses, it's the same. Certainly, there can be performance benefits if your language's implementation uses lazy evaluation and you have a very large list and you only need to evaluate a small portion of the list... but in my experience, that is very rarely the case in real programs.

> For most people's uses, it's the same.

I look forward to seeing how I can chain multiple operations on a set into a single line of Go.

Cramming a lot of logic into a single line of code is an anti-pattern and not a goal of the go language.

Also see the aforementioned "the answer is to write a loop".

As I said, I've seen people say "it's the same".

It is not the same.

Saying "supports higher level and lower level" programming when you don't actually support most higher level programming primitives is also, from my point of view, untrue.

Go's design choices are what they are, which is fine. But I just see a lot of people who argue, in all seriousness, that a loop has the same level of abstraction as map, filter etc. It simply doesn't.

I can put the loop a function if you want a nice compact version with a friendly name. Not sure what level of abstraction you're missing.

I can label a GOTO as well.

That languages are turing equivalent doesn't mean that they operate at the same level of abstraction; trying to pass one off as being "the same" as another is just silly.