let y la inmutabilidad por defecto

Casi todos los lenguajes te dan variables mutables por defecto y te obligan a pedir la inmutabilidad (const, final, val). Rust invierte el default: let crea un enlace inmutable, y la mutación es una decisión que declaras con mut. No es una manía estética; es una elección de diseño que se propaga hasta el borrow checker, el optimizador y la concurrencia.

El binding inmutable como default

let x = 5; no declara “una variable llamada x”. Declara un enlace (binding) del nombre x al valor 5, y por defecto ese enlace es de solo lectura. Reasignar es un error de compilación, no un aviso:

fn main() {
    let x = 5;
    x = 6; // error[E0384]: cannot assign twice to immutable variable `x`
    println!("{x}");
}

El compilador incluso te sugiere la corrección: añadir mut. La mutabilidad se pide de forma explícita y local, término a término:

fn main() {
    let mut contador = 0;
    contador += 1;      // ahora sí: el binding es mutable
    contador = 10;      // reasignación completa, también válida
    println!("{contador}");
}

Qué compra el default inmutable

La inmutabilidad por defecto no es una restricción gratuita: paga en tres monedas distintas.

Razonamiento local. Si x es inmutable, sabes que su valor no cambia entre su definición y su último uso, sin leer nada más. No hay que rastrear si una función intermedia lo modificó. El compilador convierte “seguramente no cambia” en “no puede cambiar”.

Optimización. Un valor que el compilador sabe inmutable puede mantenerse en un registro, propagarse como constante o reordenarse sin releer memoria. La ausencia de aliasing mutable (la regla de que solo puede existir un &mut a la vez) es precisamente lo que permite a rustc y a LLVM asumir que nadie mutará un dato a tus espaldas.

Concurrencia. Los datos inmutables compartidos entre hilos son seguros por construcción: sin escrituras no hay data races. Esta idea se formaliza más adelante en los traits Send y Sync, pero su raíz es este default.

flowchart TD
A[let x] --> B{Necesitas reasignar o mutar}
B -->|No| C[Deja el binding inmutable]
B -->|Si| D[Declara let mut x]
C --> E[Razonamiento local garantizado]
C --> F[Compartir entre hilos sin riesgo]
D --> G[Solo un prestamo mut a la vez]

mut y el préstamo exclusivo

La mutabilidad del binding es la puerta de entrada a la regla central de Rust: para modificar un dato a través de una referencia necesitas un préstamo mutable &mut, y solo puede existir uno simultáneamente, sin ningún & compartido activo a la vez.

fn main() {
    let mut v = vec![1, 2, 3];
    let r = &mut v;      // préstamo exclusivo
    r.push(4);
    // mientras r viva, no puedes tomar otro & ni &mut de v
    println!("{v:?}");   // aquí r ya no se usa: v vuelve a estar libre
}

Sin mut en el binding, &mut v ni siquiera compila. Así, la mutabilidad viaja explícita desde la declaración (let mut) hasta cada préstamo (&mut). El compilador puede seguir esa cadena y demostrar que nunca hay dos escritores, o un escritor y un lector, sobre el mismo dato al mismo tiempo. Este es el “aliasing XOR mutability” que estudiarás a fondo en el nivel de ownership.

Inmutabilidad del binding no es congelar el valor

Cuidado con una confusión común: let inmoviliza el enlace, no necesariamente todo lo alcanzable desde él. Existe la mutabilidad interior: tipos como Cell<T> y RefCell<T> permiten mutar su contenido a través de una referencia compartida &, moviendo la comprobación de préstamo de compilación a ejecución.

use std::cell::Cell;

fn main() {
    let celda = Cell::new(0);   // ¡binding inmutable!
    celda.set(42);              // y aun así mutamos el interior
    println!("{}", celda.get());
}

Esto no rompe el modelo: es una vía controlada y explícita, marcada por el tipo, para casos donde la disciplina estática de &mut es demasiado rígida. La regla mental correcta no es “inmutable = nada cambia”, sino “let = este nombre no se reasigna; para mutar el valor necesito o bien mut y &mut, o bien un tipo que ofrezca mutabilidad interior”.