The problem is the intersection of people's intuition about closures from languages without mutable state bumping into the imperative world built of mutable sta

The problem is the intersection of people's intuition about closures from languages without mutable state bumping into the imperative world built of mutable state. For example, equivalent code in Elixir: i = 0 list = [] list = list ++ [fn -> i end] i = i + 1 list = list ++ [fn -> i end] i = i + 1 halfway = list list = list ++ [fn -> i end] i = i + 1 list = list ++ [fn -> i end] IO.inspect Enum.map(halfway, fn f -> f.() end) IO.inspect Enum.map(list, fn f -> f.() end) Would produce the functional-intuitive result of [0,1] [0,1,2,3] Because there is no mutable state. Those repeated assignments to i and list are exactly equivalent to the scenario where each i was actually i1, i2, i3, etc.