A big advantage for Go is that the standard library has been stable since 1.0 and there are no plans for breaking changes.

This appears not to be true for lodash.

Lodash introduces breaking changes in major version bumps (following semver).

So upgrades are optional and not pulling the rug out from underneath the feet of devs.

Major releases allows the project to make corrections and avoid carrying around years of baggage.

Yes, that's usually the best strategy for most of us.

But a standard library is a little different due to the sheer number of dependencies and level of coordination needed to upgrade them all. Go got it mostly right the first time, and the lack of churn is a major advantage.

    async function() {
      const {data} = axis.get('foo'),
            arr = ['foo', 'bar', 'baz'];
      return arr.map(ele => await axis.get(ele));
  }

I rewrote your async function making it more concise and compact. Isn't advisable not to use «for in» with arrays?

    return arr.map(ele => await axis.get(ele));

is not legal - the await has no corresponding async. You may have wanted to write

    return arr.map(async ele => await axis.get(ele));

but that's the same as

    return arr.map(ele => axis.get(ele));

(Assuming axis.get returns a promise.)

That is, it returns an array of promises of values, not a promise of an array of values like erlich's function.

erlich's example is correct, with the replacement of for-in with for-of.

Edit:

Also, a solution using Array.map() is not impossible:

    return Promise.all(arr.map(ele => axis.get(ele)));

but this has different characteristics than the original function. The original ran the tasks in series whereas this runs them in parallel.