[hvidgaard]

On the topic of immutability you can actually trace it back to a point (and languages even) where every variable is a global one. That almost always leads to hard to debug errors and generally poor quality of the final product until you catch all the bugs. The natural "fix" is to have variables that a scoped and cannot be used outside of that scope - I hope I do not have to make the case for why that strictly improves long term maintainability.

Immutability is taking it a step further and provide a mechanism where scope does not matter. If you have an immutable object you can always expect the values to be what they are and not changed by some other path of code. You can freely pass around the immutable objects because they cannot be changed.

In other words, it's a mechanism that you can use to ensure that no matter what is changed, it's not the value of you immutable objects. I'd argue that it lowers the surface of things to consider and with any decent tooling also prevents you from trying.

[goto11]

So you try to convince me that immutability is great. But I did not say I don't believe in the benefits of immutability, I said there is no empirical evidence that it leads to better long term productivity.

[hvidgaard]

I'm not in a position where I can give you any empirical evidence because I do not collect it. My teams do see a decrease in bugs that reach production when they start to embrace immutability. But, the catch is that most of those teams are on a general journey of known good practices such as integration tests, static analysis, linting, and to some degree unit tests and reducing cyclomatic complexity. So I cannot in good faith give you any numbers because I do not run controlled experiments for that alone.