A bit more explanation would be: each variable points to an exclusive memory location which can not be mutated. A new variable (even when named the same) is a new exclusive memory location.

The blog does a good job of explaining that Elixir numbers the variable names internally, so the second ‘varname’ is in fact ‘varname2’ underneath and so no the same variable.

Nitpick: The example with the rookie mistake is not that clear at first sight. @zachdaniel might want to either explain it a bit more why it does “ surprising stuff” or replace it with another variant, as for me it does exactly what I expect it to do (just not from an immutable view). One that bit myself once: have a list of date ordered scores [1,5,2], send it to function top_score to pick the top score by sorting [1,2,5] it and give me the top result 5, continue with the list below the call to top_score(list) expecting it to be the original date sorted [1,5,2]….auch. In this example the function was never expected to mess up the list order ‘globally’.

As Javascript is large in React, the sorting function would cause a unexpected rerender due to the change.

Very nicely written. To summarize: Mutation depends on the point of view; Unobservable mutations do not count; Mutations can only be observed through indirect observation, such as an impure function call.

This mutation, however, is syntactic.

Wish I’d been armed with this simple explanation in some past discussions