no_std: enlazar contra core en vez de std

Cada vez que escribes use std::collections::HashMap o llamas a println!, te apoyas en una suposición gigantesca y casi siempre invisible: que debajo hay un sistema operativo. Un núcleo que te presta un asignador de memoria, un planificador de hilos, descriptores de fichero, una pila de red. La librería estándar de Rust —std— es, en buena parte, un envoltorio educado sobre esas capacidades del sistema. Pero hay mundos donde ese sistema no existe: un microcontrolador recién arrancado, un núcleo que es él mismo quien provee esos servicios, un gestor de arranque que corre antes que cualquier SO. Para esos mundos, Rust ofrece un solo atributo que lo cambia todo: #![no_std]. No apaga el lenguaje; apaga sus suposiciones.

Qué apaga y qué enciende el atributo

#![no_std] es un atributo de crate: se escribe con #! en la primera línea de la raíz del crate y afecta a toda la unidad de compilación. Hace dos cosas precisas. Primero, suprime el extern crate std implícito que Rust inserta por ti: el binario ya no enlazará contra la librería estándar. Segundo, reemplaza el prelude de std por el de core. El prelude es ese puñado de nombres disponibles sin use; al cambiarlo desaparecen de tu alcance Vec, String, Box, println! y HashMap, y permanecen Option, Result, Iterator, Copy, Clone y Ord, porque esos viven en core.

A partir de ahí, donde antes escribías std:: para lo que era puro cálculo, ahora escribes core:::

#![no_std]

use core::cmp::max;              // antes: std::cmp::max
use core::fmt::{self, Write};    // la maquinaria de formato vive en core

fn mayor(a: i32, b: i32) -> i32 {
    max(a, b)                    // calculo puro: core basta y sobra
}

El detalle revelador es que gran parte de std es, literalmente, una reexportación de core. std::mem::swap es core::mem::swap; std::cmp::Ordering es core::cmp::Ordering. No hay dos implementaciones: hay una, en core, que std vuelve a exponer bajo su propio nombre para tu comodidad.

Ese atributo, además, se propaga hacia arriba por el grafo de dependencias. Un crate no_std solo puede depender de crates que a su vez sean no_std, o que ofrezcan una feature para apagar su std. Basta una sola dependencia que enlace std para arrastrar std al binario entero; por eso no_std no es una decisión local de un módulo, sino una propiedad de toda la cadena de crates que desemboca en tu binario. Comprobarlo es sencillo: si tu crate compila con #![no_std] pero falla al añadir una dependencia, casi siempre es porque esa dependencia no ofrece una variante sin std.

core: el corazón portable

core es la fundación del lenguaje. No tiene dependencias, no presupone plataforma alguna y está siempre disponible —incluso std se construye encima de él—. Contiene todo aquello que es cálculo puro y que no necesita ni un asignador de memoria ni una llamada al sistema:

Lo que core no trae es igual de definitorio: nada de montículo (no hay Box, Vec ni String, porque asignar en el heap exige un asignador) y nada que mire al sistema operativo (ni ficheros, ni hilos, ni red, ni reloj de pared, ni println!). La frontera es nítida: si algo se puede calcular sin pedirle nada al mundo, está en core; si necesita memoria dinámica o un syscall, no.

Hay una consecuencia práctica enorme en que core no dependa de nada: está disponible para todo destino que tenga un backend de compilación, exista o no un SO para él. Esa es la razón de fondo por la que Rust cruza sin fricción de un servidor a un microcontrolador a un módulo WebAssembly: no porque std sea muy portable, sino porque debajo de std hay un core que no presupone plataforma alguna y compila igual para todos. La portabilidad de Rust empieza en la ausencia de suposiciones de core, no en la abundancia de std.

Ese es un patrón central de no_std, así que conviene verlo hecho. Implementar core::fmt::Write sobre un buffer en la pila da toda la potencia de write! sin asignar un solo byte en el montículo:

use core::fmt::{self, Write};

/// Un escritor sin heap: formatea dentro de un buffer fijo.
struct BufferFijo<'a> {
    datos: &'a mut [u8],
    usado: usize,
}

impl Write for BufferFijo<'_> {
    fn write_str(&mut self, s: &str) -> fmt::Result {
        let libre = &mut self.datos[self.usado..];
        let bytes = s.as_bytes();
        if bytes.len() > libre.len() {
            return Err(fmt::Error);          // no cabe: fallo sin asignar
        }
        libre[..bytes.len()].copy_from_slice(bytes);
        self.usado += bytes.len();
        Ok(())
    }
}

Con solo write_str implementado, write!(buffer, "valor: {n}") funciona: core deriva de ahí todo el formateo de enteros, flotantes y estructuras. La lógica de formato era de core desde el principio; lo único que tú aportas es a dónde van los bytes.

Por qué y para qué renunciar a std

No se elige no_std por minimalismo estético, sino porque en el destino no hay un SO que respalde a std. Un microcontrolador no tiene sistema de ficheros ni planificador; un núcleo de sistema operativo es justamente quien provee esos servicios, así que no puede depender de ellos; un gestor de arranque corre antes de que exista SO alguno. En esos entornos, std ni siquiera enlazaría: sus lang items y sus llamadas al sistema no tendrían nada a lo que atarse. no_std es la única vía para ejecutar Rust sobre el metal desnudo, dentro de un núcleo o por debajo de un sistema.

no_std, no_main y abort: tres decisiones ortogonales

Conviene separar de entrada tres elecciones que suelen aparecer juntas y por eso se confunden, pero que son independientes. #![no_std] elige la librería: core en lugar de std. #![no_main] elige el punto de entrada: renuncia al envoltorio que prepara el terreno y llama a tu main. Y panic = "abort" elige la estrategia de pánico: abortar en vez de desenrollar la pila.

#![no_std]     // 1) libreria: enlaza core en vez de std
#![no_main]    // 2) entrada: sin el envoltorio que llamaria a main
// 3) estrategia de panico, aparte, en Cargo.toml: panic = "abort"

Un binario no_std hospedado —con un SO debajo y la libc enlazada— puede conservar un main convencional; y un programa con std puede fijar panic = "abort" sin renunciar a nada más. La confusión nace de que el caso más común, el bare-metal, activa los tres ejes a la vez. Pero son ortogonales, y esta lección trata solo del primero: sustituir std por core. El punto de entrada y el manejador de pánico —los otros dos ejes— son el asunto de la lección cuatro.

En la práctica, el destino elige por ti. Los target triples sin sistema operativo llevan la marca -none, y para ellos std sencillamente no existe como artefacto precompilado: la única opción es no_std.

# un destino sin SO: el triple termina en -none, y std no esta disponible
cargo build --target thumbv7em-none-eabihf

Cuando compilas contra uno de esos triples, olvidar #![no_std] produce un error inmediato: no hay std que enlazar. El atributo no es tanto una elección estilística como el reconocimiento de una realidad del hardware.

flowchart TD
STD[std la libreria estandar] --> CORE[core sin SO ni heap]
STD --> ALLOC[alloc heap con un asignador]
STD --> OSCAPA[capa de sistema ficheros hilos red reloj]
NOSTD[crate con no_std] --> CORE
style CORE fill:#a6e3a1,color:#11111b
style STD fill:#89b4fa,color:#11111b
style NOSTD fill:#cba6f7,color:#11111b
style OSCAPA fill:#f38ba8,color:#11111b