[lmm]

By that logic why bother with for? You can implement any control structure with goto, after all.

The value of using map is precisely that it can't do everything a for loop can. It can only do one simple thing, which makes it easy for the reader to understand what it's doing.

[ominous_prime]

> You can implement any control structure with goto, after all.

Because a for loop is the most appropriate construct in the given language. That's different than comparing hypothetical constructs that a language doesn't have.

Go has higher-order functions, and you can write all the maps funcs you want, it just doesn't have the ability to create generic combinators with parametric polymorphism. That's a trade-off I accept with Go to get things done. Like a lot of people, Go for me hits a sweet spot of simplicity, productivity, and performance; simply put the benefits outweigh the drawbacks. Whatever, it's a programming language; a tool.

It's like complaining that a functional language doesn't have an easy way to write mutating procedural code. You're always working within the confines of some language, and unless you're directly working on that language's implementation where you can change things, I'd rather be working with the language than fighting it.

[lmm]

But we're talking about language design. Of course it's harder to use the feature the language doesn't have than the feature the language does have. The whole point is that the language should have that feature, because if it did have that feature then code using that feature would be better than code using the current features.

> It's like complaining that a functional language doesn't have an easy way to write mutating procedural code.

I do complain about such languages. That's why I use Scala.