But then you have no idea what the computer is actually doing. There's a big performance difference between an in-memory loop and querying a database. This is one of the things I like about Go... what the computer actually does in response to any random line of code is pretty obvious (except for function calls, which of course can do anything). When you hide away the loop inside a map statement, you get people doing dumb things like this:

    names = [m.Name for m in machines]
    ids = [m.ID for m in machines]
    addrs = [m.Address for m in machines]

So now we're iterating of over the list of machines 3 times... or making 3 database queries or whatever.

It's worth noting you'd probably want to write this out in Go as follows:

  names := make([]string, len(machines))
  for i, m := range machines {
      names[i] = m.Name
  }

append() is pretty costly, and should be avoided when possible for performance. This is actually relevant to your how vs what concern-- on the one hand, we could trust the compiler and the builtins to always take the most efficient approach, and only program 'what' we want. That could avoid something like using append in a loop where you know the length of your intended output slice. On the other hand, if there are edge cases which the built-ins take into account that we don't care about and want to ignore, being able to and having the intention of programming 'how' can have performance benefits.

I like writing 'how' because I get to benchmark and test different approaches to solve the same problem, whereas 'what' might take a usually-fast approach that isn't a good solution in our specific case.