Let me answer this question 2 times. One answer will be generic and the other one will be specialised to the question.

In general map and reduce over an Enum are totally different concepts.

To map means to apply a function to every element of an Enum and gives you a List which can be transformed into an Enum which has the same shape as the original data.

On the other hand we have reduce, which applies a function to each element and a moving accumulator to finaly reduce the complete Enum into a single value. There is no guarantee that you can reconstruct the original shape of data and not even a guarantee that your result is an Enum!

So choosing which one you choose totally depends on what kind of data you need after the iteration of the Enum.

Answering the question with the actual examples in mind is a bit harder, since we might tend here to rely on well known implementation details in the stdlib.

Since we want to retain the shape of the original data, the data |> Enum.map(f) |> Enum.into(%{}) (or Map.new/1) is preferable semantically. Currently it is in fact not as fast as reduceing directly, since it is reducing about two times due to implementation details.

So if you really need the speed, you should make sure, that you benchmark both versions with data sizes you do expect to be the average in production. Keep an eye on the result of the benchmarks and check if your choosen version is still the faster one with each elixir release, that also bumps the OTP version. There might happen optimisations in both of them, that suddenly make the semantically correct version the faster one all of a sudden.

Enum.map has been defined underwater in terms of Enum.reduce.
(or more astutely, Enum.map and Enum.reduce are both thin wrappers around Enumerable.reduce, which does the actual reducing.)

Enum.map is not a true map (the map that is part of the Functor Algebraic Data Type): If it would be, mapping over a Range would return a Range, mapping over a File would return a File and mapping over a Tree would return a Tree.

But alas, this is not the case: Enumerable is in fact a protocol that specifies the ADT frequently known as ‘Foldable’. Enum.map might thus more properly be named: Enum.to_list_then_map. The order of elements in this resulting list only matters if they mattered in the original enumerable (so for e.g. MapSet it does not, and when you convert a Tree into a List, there are multiple equally valid ways to do this, so pick one and stick with it).

The reason that Enum.map was built on top of Enumerable.reduce (and always converts to a list) is that it allows for easy use of data types that are not Functors, such as MapSet (and other Sets): If you’d do a true map on a set that results in multiple elements in the set having the same value, then it becomes invalid (so a Set cannot expose a true Functor map).

So:

• Enum.map has an arguably confusing name, as it not only the given function over a data structure, it also always converts the data structure to a list.
• Enum.map is built on top of reduce; it therefore is always possible to use Enum.reduce, but in cases where you don’t need access to the accumulator that is being built, there is no need to do so. This is simply personal preference. (You are always allowed reinvent the wheel if you really want to )
• If you do not want to lose the structure of your original data type, Enum.map is not the answer to your problem.

Well, I understood the example’s intent as “Get the list of users and construct a map based on it”, not “Transform each user in the list”. If you just want transform every item in a list - use map. If you want to get something new (different type) from an input - use reduce. IMHO