It might do that wildly inefficient thing... Or, you might do something where you have a list of pointers, and you point at a different value instead of mutati

It might do that wildly inefficient thing... Or, you might do something where you have a list of pointers, and you point at a different value instead of mutating an existing value. I haven't dug into the details of how immutable data structures can be made to work efficiently, but part of the charm is that in many cases you don't mutate the array at all. What I mean is, there are certain behaviors around mutation that programmers do because they can. When you take away the ability to mutate data, you design differently and without side effects. All of a sudden testing becomes easier, faster, cheaper for large parts of your codebase. You have simpler solutions that are potentially easier to reason about because the complex (and sometimes elegant) solutions aren't so readily available. A few talks that are around this style of thinking: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries https://www.youtube.com/watch?v=WpkDN78P884 https://www.youtube.com/watch?v=WpkDN78P884 https://www.youtube.com/watch?v=tq5SQ4W3gRI https://www.youtube.com/watch?v=tq5SQ4W3gRI http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy Boundaries are good, values are good, simple things that work together are good. The more we can take the good parts and form them together into a cohesive language/framework/platform, the better our software will be.