no_std: qué pierdes y qué conservas

La primera vez que compilas con #![no_std], el compilador te recibe con una avalancha de errores: Vec no existe, println! no existe, Box no existe. Es tentador leerlo como una mutilación, como si Rust se hubiera quedado a medias. No lo es. Lo que estás viendo es una frontera trazada con precisión quirúrgica: de un lado, todo lo que da por hecho un sistema operativo detrás; del otro, todo lo que Rust puede calcular sin pedirle nada al mundo. Aprender ese mapa no es memorizar dos listas, sino interiorizar el único principio que las genera. Cuando lo tengas, sabrás sin abrir la documentación si cualquier tipo o función sobrevive a no_std o no.

Lo que pierdes: todo lo que presupone un SO

Desaparece, en bloque, cualquier cosa que necesite que exista un sistema operativo debajo. No porque Rust lo prohíba, sino porque vive en std y std ya no está enlazado:

También desaparece el andamiaje que el runtime de std montaba en silencio: el manejador de pánico por defecto, el desenrollado de la pila y el main que se ejecutaba solo. Eso lo reconstruirás tú a mano en la lección cuatro.

Lo que conservas: todo lo que es cálculo puro

Y sin embargo, el corazón del lenguaje queda intacto. Nada de lo que define a Rust como Rust depende de std:

#![no_std]

/// Media entera de un slice, sin asignar nada: puro core.
fn media(datos: &[i32]) -> Option<i32> {
    if datos.is_empty() {
        return None;                       // Option: vive en core
    }
    let suma: i32 = datos.iter().sum();    // el iterador no asigna
    Some(suma / datos.len() as i32)
}

Ese fragmento usa Option, un slice, el trait Iterator con su adaptador sum, aritmética y un if, y compila sin std porque todo ello es core. Conservas, íntegros: todos los tipos primitivos y sus métodos; Option, Result y sus combinadores, con el operador ?; el trait Iterator y todos sus adaptadores (map, filter, fold, zip), que son perezosos y no asignan; los traits fundamentales (Copy, Clone, PartialEq, Eq, Ord, Hash el trait, la familia Fn); los slices &[T] y &str con sus métodos que no asignan; genéricos, closures, pattern matching, core::mem, core::ptr y los atómicos de core::sync::atomic. El borrow checker, por descontado, sigue vigilando cada línea.

El mismo principio escala a estructuras de datos completas. Con genéricos, arrays y const generics —todo de core— se construyen colecciones de capacidad fija que jamás tocan el montículo, la base sobre la que se levantan crates como heapless:

/// Una pila de capacidad fija: puro core, sin asignar en el heap.
struct PilaFija<T, const N: usize> {
    datos: [Option<T>; N],
    cima: usize,
}

impl<T: Copy, const N: usize> PilaFija<T, N> {
    fn nueva() -> Self {
        Self { datos: [None; N], cima: 0 }
    }

    fn push(&mut self, x: T) -> Result<(), T> {
        if self.cima == N {
            return Err(x);          // llena: devolvemos el valor sin perderlo
        }
        self.datos[self.cima] = Some(x);
        self.cima += 1;
        Ok(())
    }
}

Option, Result, genéricos, un array de tamaño constante y aritmética: nada de esto abandona core. Tienes estructuras reales, con una API de push que falla cuando se llena en vez de asignar más memoria, y sin un montículo a la vista.

El criterio: asignador o syscall

Las dos listas anteriores no son arbitrarias ni hay que memorizarlas: son la proyección de una sola pregunta. Ante cualquier elemento de la librería, pregúntate si para funcionar necesita asignar en el montículo o hacer una llamada al sistema. Si la respuesta es no, está en core y sobrevive. Si es sí, está fuera.

flowchart TD
Q[necesita heap o un syscall] -->|si lo necesita| FUERA[fuera de core Vec Box hilos ficheros red reloj]
Q -->|no lo necesita| DENTRO[dentro de core Option Result iteradores slices traits atomicos]
style DENTRO fill:#a6e3a1,color:#11111b
style FUERA fill:#f38ba8,color:#11111b
style Q fill:#89b4fa,color:#11111b

El criterio predice incluso los casos que parecen anómalos. Iterator::map no asigna ni llama al sistema: se queda. std::thread::spawn necesita el planificador: se va. Puedes ejercitarlo como un juego, decidiendo el piso de cada elemento sin tocar el compilador:

// slice::windows     -> core   (solo recorre memoria que ya posees)
// str::trim          -> core   (no asigna: devuelve un sub-slice)
// Instant::now       -> std    (le pregunta la hora al sistema)
// Vec::with_capacity -> alloc  (reserva en el monticulo)
// TcpStream::connect -> std    (abre un socket: puro syscall)

Y hay un caso límite famoso que conviene tener presente antes de la próxima lección.

Dos clases de pérdida, dos destinos

No todo lo que perdiste se pierde igual, y la distinción es el mapa de ruta del nivel entero. Las pérdidas de montículo —Vec, Box, String, Rc, las colecciones— se fueron solo porque necesitan asignar, y son recuperables: basta un asignador, y la próxima lección te las devuelve con el crate alloc, sin traer ningún SO. Las pérdidas de sistema —hilos, ficheros, red, reloj, salida estándar— se fueron porque necesitan un sistema operativo, y ningún asignador las restituye: solo un SO real lo hace.

Por eso la lección tres recupera la primera clase añadiendo alloc, mientras que las lecciones cuatro y cinco enseñan a vivir de forma permanente sin la segunda. Y en tu propio código, saber en qué cubo cae cada dependencia te dice con exactitud hasta qué piso —core, core más alloc, o std— puedes subir en un destino dado.