async fn y .await: la sintaxis de una función perezosa

A primera vista una async fn parece una función normal con una palabra extra delante. La diferencia es profunda: no devuelve su resultado, devuelve un Future que promete ese resultado más adelante, y ese Future nace inerte. Llamar a la función no ejecuta su cuerpo; construye un valor que no ha hecho nada todavía. Solo cuando lo conduces con .await empieza a avanzar, y en cada .await el código puede pausarse y devolver el control a quien lo ejecuta. Dos ideas, y solo dos, bastan para entender la sintaxis entera: los futures son perezosos, y .await es el punto donde una función cede mientras espera.

La sintaxis: async fn devuelve un Future

La palabra async delante de una fn transforma su firma. El tipo que escribes como retorno se convierte en el Output de un Future anónimo:

async fn leer_usuario(id: u64) -> String {
    format!("usuario-{id}")
}

// El compilador la reescribe, en esencia, a esto:
fn leer_usuario(id: u64) -> impl Future<Output = String> {
    async move { format!("usuario-{id}") }
}

Donde antes leías “devuelve un String”, ahora lees “devuelve algo que, al avanzarlo hasta el final, producirá un String”. Ese “algo” es un tipo anónimo que el compilador fabrica y que implementa el trait Future; su tipo asociado Output es el valor prometido. No puedes nombrarlo, pero sí referirte a él con impl Future<Output = String>.

Perezoso: llamar no es ejecutar

Aquí está el giro mental más importante del nivel. En la mayoría de los lenguajes, invocar una función empieza su trabajo; una promesa de JavaScript arranca en el instante en que la creas. En Rust es al revés: un Future es perezoso. Construirlo no corre ni una línea de su cuerpo.

let futuro = leer_usuario(7); // NO se ejecuta nada; futuro esta inerte
// ... el cuerpo de leer_usuario aun no ha corrido ...
let nombre = futuro.await;    // AHORA empieza a avanzar hasta terminar

Esta pereza tiene una consecuencia práctica inmediata: un Future que construyes y no avanzas no hace absolutamente nada. El compilador lo sabe y marca Future como #[must_use], avisándote si descartas uno. El error de principiante clásico es llamar a una async fn y olvidar el .await:

async fn registrar(evento: &str) { /* escribe en un log ... */ }

async fn demo() {
    registrar("inicio");        // BUG: crea un Future y lo tira; no registra nada
    registrar("inicio").await;  // correcto: lo avanza hasta el final
}

En una base de código grande este olvido es de los bugs más insidiosos: compila, no lanza ningún error en tiempo de ejecución, y simplemente no hace lo que creías. El compilador te cubre las espaldas con el aviso must_use, pero solo si lo escuchas en vez de silenciarlo.

.await: ceder el control mientras se espera

El operador .await hace dos cosas a la vez. Primero, avanza el future hacia su resultado. Segundo, y decisivo, si el future todavía no está listo —el socket no tiene datos, el temporizador no venció—, .await cede: devuelve el control a quien conduce la tarea (el runtime), que puede dedicar el hilo a otras tareas listas. Cuando el recurso esperado por fin está disponible, la ejecución se reanuda exactamente donde se pausó.

Dos detalles de sintaxis importan. .await es postfijo —se escribe x.await, no await x—, lo que encadena de maravilla con métodos y con el operador ?. Y solo puede aparecer dentro de un contexto async: una async fn o un bloque async.

use tokio::fs;

async fn tamano_total(a: &str, b: &str) -> std::io::Result<usize> {
    let uno = fs::read(a).await?; // cede mientras el disco responde
    let dos = fs::read(b).await?; // solo EMPIEZA cuando el primero termino
    Ok(uno.len() + dos.len())
}

Observa un matiz que decide el rendimiento: los .await son secuenciales por defecto. dos no arranca hasta que uno terminó. Eso es correcto cuando hay dependencia real, pero desperdicia la ocasión de solapar dos esperas independientes —para eso están join! y spawn, que verás en la lección cinco—. Entre dos puntos de .await, el código corre de un tirón, sin interrupción; el .await marca los únicos lugares donde la función puede pausarse.

flowchart TD
A[Llamas a una async fn] --> B[Devuelve un Future inerte]
B --> C[No se ejecuta nada de su cuerpo]
C --> D[Haces await sobre el Future]
D --> E[El runtime empieza a avanzarlo]
E --> F{El valor esta listo}
F -->|no| G[await cede el control al runtime]
G --> E
F -->|si| H[await devuelve el valor y sigue]
style B fill:#89b4fa,color:#11111b
style C fill:#f38ba8,color:#11111b
style G fill:#fab387,color:#11111b
style H fill:#a6e3a1,color:#11111b

Bloques async y la forma del valor

No solo las fn pueden ser async. Un bloque async { ... } es una expresión que produce un Future, ideal para fabricar trabajo al vuelo o preparar una tarea para spawn. Como un closure, captura su entorno por referencia o, con async move, por valor.

let trabajo = async move {
    let x = paso_uno().await;
    paso_dos(x).await
};
// trabajo: impl Future; sigue inerte hasta que alguien lo avance

El bloque se lleva consigo todo lo que necesita recordar a través de sus .await, igual que la async fn. Sea función o bloque, el resultado es siempre lo mismo: un valor perezoso que representa un cómputo suspendible, listo para pasarse, componerse o entregarse a un runtime.

La elección entre capturar por referencia o con async move no es cosmética. Un bloque que se va a spawn como tarea independiente casi siempre necesita async move, porque debe poseer sus datos: la tarea puede sobrevivir al ámbito donde nació, y una referencia prestada a ese ámbito sería inválida.

let nombre = String::from("Ada");

// Sin move: el bloque toma prestado nombre; solo vale mientras el prestamo dure.
let saludo = async { format!("hola {nombre}") };

// Con move: el bloque se lleva nombre; puede vivir por su cuenta, apto para spawn.
let saludo = async move { format!("hola {nombre}") };

Es la misma disciplina de ownership que ya conoces de los closures, aplicada ahora a un valor que representa un cómputo aún sin ejecutar.