Compare that to:

    out = []
    [1,2,3].each do |x|
      out.append(x.to_s)
    end

[1]: `&:method_name` is extremely-common shorthand for "call this method"

A tale of two cities is an easier book for an English speaker than Les Aventures de Tintin.

Map applies a function to each item in a collection.

As pseudo-code:

Collection.map(function)

And in the parents example we have:

[1,2,3].map(&:to_s)

The only Ruby specific part is &:.

Summing is a nice example. A naive for-loop will just iterate through the list, keep a variable around, add the next item in the list to it. In functional programming (or with a reduce), you tell it to sum in a more concise way - but more importantly, you don't tell the compiler how exactly it should do it. It's trivial with functional programming to make the task (for example) multithreaded or to use advanced underlying cpu tricks, without you as a developer needing to know how exactly it does what you ask it to.

I'm unclear where algorithmic complexity is coming into this. Can you clarify what you're trying to imply?

Can you given an example where map might increase algorithmic complexity like that where the imperative version would not?

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.

You're right: map separates looping mechanics from computation. In Go, that's a bit too much obscurity.