When should you prefer immutability over performance in systems programming languages?

[iaversao7-sketch]

In languages like Rust, C++, and Go, immutability is often promoted for safety and reasoning, but it can introduce performance overhead in hot paths.

In practice, how do you decide when immutability is worth the cost versus when controlled mutability is the better choice?
Are there concrete patterns or heuristics you apply in performance-critical code?

[DaviBonetto]

I treat immutability as a default at the boundaries and mutability as an optimization inside hot paths.

In systems languages, the main heuristics I use are:

Concurrency boundaries: immutability simplifies reasoning and eliminates entire classes of data races.

Hot vs. cold paths: in hot loops, controlled mutability often provides measurable gains with minimal conceptual cost.

Ownership clarity: in Rust, for example, explicit ownership and borrowing already provide safety, so mutability can be acceptable when it’s local and well-scoped.

When immutability forces excessive allocations or copying, I usually reconsider it. The goal isn’t purity, but making illegal states unrepresentable without sacrificing performance where it actually matters.