Por qué Rust no trae runtime: async es del lenguaje, ejecutarlo no

Aprendes async y .await, escribes tu primera función asíncrona, la llamas desde main… y no compila, o no ejecuta nada. La razón desconcierta a todo el que viene de otros lenguajes: la librería estándar de Rust no incluye un runtime. Define la sintaxis async/.await, el trait Future y toda la maquinaria de tipos, pero no trae la pieza que ejecuta un future hasta el final, ni la que integra con la red, ni la que reparte tareas entre hilos. Para eso tienes que traer una crate externa —Tokio, smol, Embassy—. Esto no es un olvido ni una obra a medias: es una negativa deliberada, y entender por qué ilumina toda la filosofía de Rust.

Lo que el lenguaje sí define

Rust aporta la forma de la computación asíncrona, y la aporta en core —no solo en std—, lo que significa que async funciona incluso sin sistema operativo. En concreto:

• La sintaxis async/.await y la transformación del compilador a una máquina de estados.
• El trait Future (en core::future), con su método poll.
• Los tipos Poll, Context y Waker (en core::task), y Pin para futures auto-referenciales (nivel 33).

pub trait Future {
    type Output;
    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}

Esto es una interfaz, no un motor. Define qué significa “ser un future” y cómo se le pide que avance un paso —poll—, pero no dice quién llama a poll, ni cuándo, ni desde qué hilo. Es un contrato esperando a que alguien lo cumpla.

Lo que falta: el runtime

Un Future inerte necesita que algo lo conduzca, y ese algo —el runtime— reúne varias piezas que std deliberadamente no incluye:

• Executor: el bucle que llama a poll una y otra vez sobre las tareas hasta que devuelven Ready. Sin executor, un future es un valor que nadie avanza.
• Reactor o driver de E/S: integra con epoll, kqueue, IOCP o io_uring; despierta las tareas cuando un socket o fichero está listo, y fabrica los Waker reales.
• Planificador de tareas: reparte las tareas entre hilos trabajadores e implementa spawn.
• Temporizadores: sleep, timeouts y todo lo que dependa del reloj.

Ninguna de estas piezas vive en la librería estándar. Por eso este código, aparentemente razonable, no llega a ninguna parte por sí solo:

// Esto NO arranca: main no puede ser async a secas,
// y nadie conduciria el Future que produce.
async fn main() {
    hacer_algo().await; // no hay executor que avance este await
}

Falta el motor. En cuanto traes uno —con #[tokio::main], que verás en la lección cinco—, el mismo código cobra vida.

¿Qué hace ese motor, en esencia? “Conducir” un future no es misterioso: es hacerle poll una y otra vez hasta que termina. Un executor mínimo cabe en un comentario:

// Un executor de juguete, en esencia, no es mas que esto:
//   1. toma un future y lo fija en su sitio
//   2. lo avanza con poll
//   3. si dice Pending, se duerme hasta que un waker avise
//   4. al despertar, vuelve a 2
//   5. si dice Ready, entrega el valor y termina
// Tokio hace justo esto, pero con robo de trabajo entre hilos,
// un reactor de E/S sobre epoll/kqueue y temporizadores.

La lección cuatro abre esa mecánica del poll. Lo que importa ahora es que ese bucle —trivial de enunciar, delicado de hacer eficiente y multihilo— es precisamente lo que std decidió no incluir.

Por qué es deliberado

La ausencia no es pereza de los diseñadores; es coherencia con lo que Rust promete. Cuatro razones lo sostienen.

Primero, no_std y embebido. Rust corre en microcontroladores sin heap ni sistema operativo. Un runtime cosido a std sería inservible ahí. Que el runtime sea elegible es lo que permite a Embassy ofrecer async en bare metal, sobre el mismo trait Future que usa un servidor:

#![no_std]
// En un microcontrolador no hay std, pero el trait Future vive en core:
use core::future::Future;
// La sintaxis async y .await funciona igual; solo cambia el motor que la conduce.

Que la sintaxis y el trait vivan en core y no en std no es un tecnicismo: es lo que hace que el mismo idioma async sirva desde la nube hasta un chip de kilobytes.

Segundo, no hay un modelo único correcto. Multihilo con robo de trabajo (Tokio), un hilo por núcleo sobre io_uring (Glommio, monoio), un solo hilo para tareas que no cruzan hilos… cada carga real prefiere uno distinto. Cocer uno en el lenguaje petrificaría esa decisión para todos.

Tercero, coste cero. El principio de Rust es “no pagas por lo que no usas”. El mecanismo async del lenguaje no impone ni una asignación ni un hilo; el coste llega solo con el runtime que tú elijas, y en su justa medida.

Cuarto, evolución. Dejar el runtime como biblioteca permite que compita, itere y mejore sin atarse al ritmo lento y conservador de la estabilización del lenguaje. Tokio ha reescrito su planificador varias veces; de haber estado en std, cada mejora habría requerido una edición del lenguaje y una promesa de estabilidad eterna.

Ninguna de estas cuatro razones es un accidente histórico que una crate oficial pudiera enmendar: son consecuencias directas de dos compromisos que Rust no piensa romper —correr en todas partes, del servidor al metal desnudo, y no cobrarte por lo que no pides—. Un runtime cosido a std traicionaría los dos a la vez.

flowchart TD
L[El lenguaje y core definen la forma] --> L1[Sintaxis async y await]
L --> L2[El trait Future y su metodo poll]
L --> L3[Poll Context Waker y Pin]
R[El runtime externo aporta el motor] --> R1[Executor que hace poll en bucle]
R --> R2[Reactor de entrada salida sobre epoll kqueue]
R --> R3[Temporizadores planificador y spawn]
L2 -. no se conduce solo .-> R1
style L fill:#cba6f7,color:#11111b
style R fill:#fab387,color:#11111b
style L2 fill:#89b4fa,color:#11111b
style R1 fill:#a6e3a1,color:#11111b

El ecosistema de runtimes

Como el runtime es una decisión tuya, conviene conocer el mapa. No hace falta que los domines ahora; basta saber que existen y para qué sirve cada uno.

El grueso del ecosistema orbita Tokio, pero la propia variedad es la prueba de que la decisión de diseño acertó: cada nicho —red, embebido, latencia extrema— encontró o construyó su motor sobre el mismo Future.