Values and Immutability

In F#, the let keyword binds a name to a value, and by default that binding is immutable — once let x = 5 has executed, x can never be reassigned to point at a different value within that scope. This differs sharply from variables in C#, Python, or JavaScript, where x = 5 typically means 'this variable can change later'; in F#, immutability is the default assumption baked into the language, and mutability must be explicitly requested.

Because let creates a binding rather than a variable slot, let x = 5 is closer to defining a mathematical constant than declaring storage — the compiler enforces this, so x <- 6 on an immutable binding is a compile error, not a runtime surprise. Immutability by default eliminates an entire category of bugs where a shared value is unexpectedly changed by distant code, which is especially valuable in concurrent or multi-threaded systems where mutable shared state is a classic source of race conditions.

When mutation truly is the right tool — a loop counter, an accumulator updated in a tight performance loop, a UI-bound value — F# lets you opt in explicitly with let mutable x = 5, after which x <- x + 1 reassigns it using the <- operator, deliberately different from the = used for binding and equality comparison. This explicitness means every mutable variable in an F# codebase is visible at a glance, making it easy to audit exactly where state can change.

F# also supports shadowing: writing let x = 5 followed later by let x = x + 1 in the same scope does not mutate the original x — it creates a brand-new binding that happens to reuse the name, while the old value still exists (and may still be referenced by a closure created before the shadowing). This is a common source of confusion for beginners coming from mutable-variable languages, who read shadowing as mutation when it is actually the creation of an entirely separate, still-immutable value.