> But when the type system doesn’t distinguish between mutable and immutable values, it becomes hard to reason locally about the code. You never know for sure i

> But when the type system doesn’t distinguish between mutable and immutable values, it becomes hard to reason locally about the code. You never know for sure if that value that looks like it shouldn’t be mutated isn’t maybe mutated after all under some circumstance five function calls away. I don't think that mutability has to be an inherent property of a value: it's really a description of how a value can be accessed. Personally, I'm partial to the model used by Rust, where you can either have shared immutable access to a value, or exclusive mutable access to a value, and you can temporarily loan out your access to another function with a strict deadline (a "lifetime"). Together, this means that you can call a function granting it mutable access to your value, and be confident that the called function is the only thing in the world that could have modified the value. I'm surprised by how this "controlled mutability" solution never seems to come up in discussions of imperative vs. functional programming. Perhaps it has to do with how mind-boggling the borrow checker can appear coming from most other languages.