Immutability: Why Can an Edit Mean Creating a New Version?

Immutability does not stop the world from changing. It sets a narrower rule: once an object has been created, it is not rewritten in place. A change produces another object containing the new state. The old version remains what it was, while the new version carries the new facts.

Suppose several parts of a program read the same settings object. If one part quietly alters it, the others may see different content without knowing when the change occurred, and failures become hard to reproduce. When each edit creates a new version, code holding the old reference remains stable and switching to the new one becomes an identifiable act. Comparison, caching, rollback and concurrent reasoning are easier.

Immutability differs from read-only access. Read-only means a particular user cannot modify something; immutability means the object itself is never changed in place. Nor does it require keeping every version forever: an unused version can still be discarded. The cost can be extra objects and copying, so immutable systems often use shared structures, version identifiers and garbage collection. The point is not resistance to change, but giving change a visible boundary.