Yes, that's exactly right. And Go takes a relatively strict stance on making the _how_ obvious to the programmer. It goes out of its way to avoid hiding O(n^k) loops behind language sugar like map or fold, for example.
You can hide a loop behind a function call in Go, Python, really any imperative language.
What makes map different is that it separates the looping mechanics (incrementing, initializing and appending to the collection) from the actual computation we want to perform on each element. It's just separation of concerns.
Yes. In Go, function and method calls are the primarily, perhaps only, mechanism of abstracting computational complexity. That is, when you see a function or method call, you know that "anything goes" back there, and you need to dig and find out what the computer is gonna be doing. Pretty much everything else is implemented "in plain sight"; in the case of fold/map, that means with a for loop, where you see precisely how many iterations you're going to step through.
You're right: map separates looping mechanics from computation. In Go, that's a bit too much obscurity.
I'm unclear where algorithmic complexity is coming into this. Can you clarify what you're trying to imply?