Reduce vs Map, which is preferable?

Personally, I think they both are good and serve different goals. As for your example, I would use reduce because at the start of a code line Enum.reduce I understand what to expect from this line (and there is no need to know that you can initialize new map with a list of tuples, as in the second line (even it’s not so difficult, though)).

AFAIK map itself implemented with reduce so we can omit additional functions invocations (inside Map.new) (like in the ‘synonym’ implementation of the second example).

An alternative to using Map.new(tuples) would be Enum.into(tuples, %{}), by the way.

I agree with @madeinussr that this is probably mostly up to personal taste.
However, I would prefer Enum.map because the intent here is to transform each individual value (i. e. map it). So while you might not be able to tell from the initial Enum.map that you’ll get a Map back, it is always safe to assume you will get a transformed value that structurally resembles your input.

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

Oh you’re absolutely right and in this case Map.reduce would definitely be the better choice.

The example was a bit contrived. There are a few places where there is no way around using a reduce, but in a few other places we can do with Enum.map, and in those instances I prefer Enum.map

another example

## blowing up a list
# reduce
(1..10) |> Enum.reduce([], fn n, acc -> Enum.to_list(1..n) ++ acc end)
# map
(1..10) |> Enum.flat_map(fn n -> Enum.to_list(1..n) end)

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.

… and there are a lot of various examples

Actually, in most cases map vs reduce usage (if their outputs are the same, of course) is a matter of taste and code readability. Sometimes it’s a matter of performance.

I’ve just tried to explain my choice over map vs reduce in specific example.

If you can use map use map. With reduce you can do more than in map. You can think as map is subset of reduce → you can write implementation of map using reduce function but you can do do otherwise.
For example you can use reduce to transform list to map, or you can use reduce to transform list to int (count number of elements in list)

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.

Alternatively:

for user <- users, into: %{}, do: {user.id, user}