El ecosistema esencial: las crates que todo Rustacean conoce

Si vienes de lenguajes con «pilas incluidas», la biblioteca estándar de Rust te parecerá austera hasta el desconcierto: no trae serialización JSON, ni un runtime asíncrono, ni un cliente HTTP, ni parseo de argumentos de línea de comandos. No es un olvido: es una postura. La std de Rust promete estabilidad perpetua —lo que entra jamás puede romper—, así que se restringe a lo verdaderamente universal y delega el resto en crates.io, donde las librerías pueden evolucionar, subir mayores y competir. El resultado es que ser productivo en Rust exige conocer un canon: media docena de crates fundacionales que la comunidad ha coronado como estándares de facto. No dominarlas es reinventar mal lo que decenas de miles de proyectos ya comparten. Esta lección es el mapa de ese canon.

Por qué la stdlib es pequeña a propósito

La decisión de fondo es un intercambio entre dos garantías incompatibles. La std ofrece estabilidad absoluta: código escrito hace años sigue compilando, porque la biblioteca estándar nunca publica una versión mayor que rompa. Pero esa misma inmovilidad sería veneno para una API de serialización o un runtime async, dominios donde el conocimiento del arte avanza rápido y a veces hace falta rehacer las abstracciones. Meter serde o tokio en la std los congelaría en su primer diseño para siempre.

Al dejarlos fuera, Rust les concede lo que necesitan: serde y tokio pueden iterar, aprender de sus errores y publicar mayores cuando corresponde, sin arrastrar a la std ni romper la promesa del lenguaje. El precio es que el recién llegado debe saber qué instalar. La std conserva lo eterno —tipos, colecciones, Result, hilos, Iterator— y el ecosistema aporta lo que evoluciona. Conocer el canon es, por tanto, parte de saber Rust.

Las crates fundacionales

Estas son las columnas del ecosistema, las que aparecen en el Cargo.toml de una fracción enorme de todos los proyectos:

Un vistazo a serde basta para captar por qué estas crates dominan: la ergonomía es la de la biblioteca estándar, pero el poder es de una librería que pudo evolucionar. Deriva dos traits y tu tipo habla ya con cualquier formato del ecosistema:

use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize)]
struct Config { host: String, puerto: u16 }

let c = Config { host: "localhost".into(), puerto: 8080 };
let json = serde_json::to_string(&c)?;            // a JSON
let vuelta: Config = serde_json::from_str(&json)?; // y de vuelta
let toml = toml::to_string(&c)?;                   // el MISMO tipo, otro formato

El struct no sabe nada de JSON ni de TOML: serde separa el modelo de datos del formato, y esa abstracción es la que convierte un tipo cualquiera en universalmente serializable.

Más allá de esta primera fila hay una segunda que también conviene tener en el radar: anyhow y thiserror para errores (que ya recorriste), tracing para observabilidad estructurada, regex para expresiones regulares, rand para aleatoriedad, itertools para adaptadores extra de iterador, sqlx y diesel para bases de datos, criterion para benchmarks, y proptest para pruebas basadas en propiedades. Ninguna vive en la std, y todas son, en la práctica, tan estándar como si lo estuvieran.

El grafo de la web asíncrona

Las crates no son islas: se apilan. El ejemplo canónico es la pila web de tokio, donde cada capa se construye sobre la anterior y tower aporta un vocabulario común de middleware —Service— que tanto el servidor como el cliente reutilizan:

flowchart TD
MIO[mio E/S del sistema epoll o kqueue] --> TOKIO[tokio runtime tareas y temporizadores]
TOKIO --> HYPER[hyper implementacion de HTTP]
HYPER --> TOWER[tower abstraccion Service y middleware]
TOWER --> AXUM[axum servidor web]
TOWER --> REQWEST[reqwest cliente HTTP]
style TOKIO fill:#89b4fa,color:#11111b
style TOWER fill:#f9e2af,color:#11111b
style AXUM fill:#a6e3a1,color:#11111b
style REQWEST fill:#cba6f7,color:#11111b

Entender este apilamiento es entender por qué elegir tokio como runtime arrastra decisiones: axum, reqwest, sqlx y buena parte del mundo async asumen tokio por debajo. La coordinación no es casual; es lo que permite que middleware escrito para tower funcione sin cambios en un servidor axum y en un cliente reqwest.

Las lenguas francas: traits que todos hablan

El activo más sutil del ecosistema no son las crates sino ciertos traits que se han vuelto vocabulario universal. serde::Serialize es el caso arquetípico: miles de crates lo implementan para sus tipos, y miles de formatos lo consumen, de modo que cualquier tipo «serde-compatible» habla con cualquier formato «serde-compatible» sin que sus autores se conocieran jamás. Lo mismo hacen Future (que tokio ejecuta pero cualquiera puede producir), el trait Service de tower, o Error de la std. Estas interfaces compartidas son el tejido conectivo: convierten un montón de librerías independientes en un ecosistema donde las piezas encajan.