Tensions in Practice: Cheap replacement in tension with stable observed values¶
Shared values · readers spanning an update
A reader holds a reference to a value whose content is Blue. A later update changes the desired content to Green. Overwriting the shared value makes the old reference observe Green too. Creating a new value lets the existing reader keep Blue while new readers advance, but requires retaining both values during that overlap.
Keep updates compact
Replace a small shared value without maintaining a separate value for every observer’s view.
Preserve what a reader already holds
Let an existing reference continue to identify unchanged content.
Why these aims pull against each other
An in-place edit changes the meaning of a held reference. A retained successor avoids that shift by paying for another value and a policy for its lifetime.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Overwrite the value
Change the content of the shared object from Blue to Green in place.
- What it protects
- The illustration needs one value cell rather than retaining two distinct values.
- What it costs
- A reader that needed its previous snapshot can no longer obtain Blue through that reference.
- When it fits
- Fits explicitly live views where observing later changes is intended and concurrent access is correctly synchronized.
Illustration note: The storage contrast is qualitative. It ignores allocator and representation details and assumes a correct mutation protocol.
Retain a snapshot
Create Green as a new immutable value while the existing reader still holds Blue.
- What it protects
- The existing reader’s content remains stable while the system continues to change.
- What it costs
- Overlapping values consume storage and require a safe policy for eventually releasing unused versions.
- When it fits
- Fits readers needing a consistent snapshot or preserved prior content and a manageable retention policy.
Illustration note: The old value is retained because this reader still holds it; immutability alone does not guarantee eternal history.
What this illustration does—and does not—establish
Immutability: Immutability trades storage and write cost for safety and history supplies the storage/stability conflict; its limitations explicitly bound permanence. The two reference graphs are editorial and hold the desired content change fixed.
- Updating which value is called current is a separate mutable operation that also needs a concurrency contract.
- Immutable records do not reverse effects already produced outside the record.
- Blue and Green are arbitrary content labels, not states with an implied preference.
Source entries
Immutability
Immutability: Immutability trades storage and write cost for safety and history supplies the conflict examined here.
Immutability trades storage and write cost for safety and history
This is the price of referential stability and a complete audit trail, but it is a real cost: unbounded growth, larger working sets, and write amplification.
What It Is Not
Immutability is also not the same as *permanence* or *indelibility*. An immutable value can still be forgotten, pruned, expired, or made unreachable—what immutability guarantees is that *while it exists*, it will not be altered in place, not that it must exist forever. A git commit can be garbage-collected after a branch is deleted; an append-only log can be truncated by retention policy. The commitment is "no silent in-place change," not "eternal retention."