Tu primer programa async con Tokio

Has entendido el porqué; toca ver el cómo. Tokio es el runtime que aporta justo lo que el lenguaje omite: el executor que conduce tus futures, el reactor que habla con la red, el planificador que reparte tareas entre hilos. Con tres piezas tienes un programa async real: #[tokio::main] para arrancar el runtime y bloquear sobre tu main asíncrono, tokio::spawn para lanzar tareas que corren a la vez, y join! para solapar esperas independientes. En este último paso se paga, contante y sonante, la promesa de la lección uno: dos esperas de cien milisegundos que juntas costaban doscientos pasan a costar cien.

Preparar el terreno: la dependencia y #[tokio::main]

Primero, la dependencia. El feature full activa todo lo que necesitas para empezar:

[dependencies]
tokio = { version = "1", features = ["full"] }

Y el “hola mundo” async:

#[tokio::main]
async fn main() {
    println!("hola desde una tarea async");
}

#[tokio::main] es una macro que reescribe tu async fn main en una fn main síncrona normal que construye un runtime y llama a block_on sobre el cuerpo async. En esencia, expande a esto:

fn main() {
    tokio::runtime::Runtime::new().unwrap().block_on(async {
        println!("hola desde una tarea async");
    });
}

block_on es el puente del mundo síncrono al asíncrono: conduce un future hasta el final sobre el hilo actual. Por defecto el runtime es multihilo, con tantos hilos trabajadores como núcleos; si prefieres uno de un solo hilo, #[tokio::main(flavor = "current_thread")].

async fn main y el primer await

Un .await de verdad necesita algo que espere. Para simular la latencia de E/S usamos tokio::time::sleep, que cede la tarea mientras el temporizador corre —a diferencia de std::thread::sleep, que bloquearía el hilo trabajador entero—:

use tokio::time::{sleep, Duration};

async fn descargar(nombre: &str) -> String {
    sleep(Duration::from_millis(100)).await; // simula la latencia de la red
    format!("datos de {nombre}")
}

#[tokio::main]
async fn main() {
    let datos = descargar("informe").await;
    println!("{datos}");
}

spawn: tareas concurrentes

tokio::spawn toma un future y lo entrega al runtime como una tarea independiente que empieza a correr enseguida, quizá en otro hilo trabajador. Devuelve un JoinHandle sobre el que puedes hacer .await para recoger su resultado:

use tokio::time::{sleep, Duration};

#[tokio::main]
async fn main() {
    let mut handles = Vec::new();
    for i in 0..3 {
        let h = tokio::spawn(async move {
            sleep(Duration::from_millis(100)).await;
            i * 10
        });
        handles.push(h);
    }
    for h in handles {
        let valor = h.await.unwrap(); // JoinHandle produce un Result
        println!("tarea produjo {valor}");
    }
}

Las tres tareas corren concurrentemente: sus sleep se solapan, así que el tiempo total de reloj es de unos cien milisegundos, no trescientos. Dos detalles importan. spawn exige que el future sea Send + 'static —debe poder moverse a otro hilo y no depender de préstamos locales—, un anticipo de Send/Sync del nivel 30. Y el JoinHandle entrega un Result porque la tarea podría entrar en pánico o ser cancelada.

Concurrencia real: join! y el ahorro

tokio::join! avanza varios futures a la vez en la misma tarea —sin spawn, sin requerir Send— y termina cuando todos han terminado, devolviendo sus resultados en una tupla:

use tokio::time::{sleep, Duration};

async fn descargar(nombre: &str) -> String {
    sleep(Duration::from_millis(100)).await;
    format!("datos de {nombre}")
}

#[tokio::main]
async fn main() {
    // Secuencial: 100 + 100 = 200 ms
    let a = descargar("A").await;
    let b = descargar("B").await;
    println!("secuencial: {a}, {b}");

    // Concurrente: max(100, 100) = 100 ms
    let (a, b) = tokio::join!(descargar("A"), descargar("B"));
    println!("concurrente: {a}, {b}");
}

Aquí está el pago del nivel entero. Dos esperas independientes que sumaban doscientos milisegundos pasan a costar cien, porque el runtime las solapa: mientras una duerme, la otra avanza. Y escala sin límite práctico —diez descargas concurrentes siguen costando unos cien milisegundos en vez de un segundo—. La lección uno prometió “solapar la espera”; join! es esa promesa hecha código.

flowchart TD
M[tokio main arranca el runtime] --> S[Camino secuencial]
M --> C[Camino concurrente con join]
S --> S1[await descargar A cien ms]
S1 --> S2[await descargar B cien ms]
S2 --> ST[Total doscientos ms]
C --> C1[join avanza A y B a la vez]
C1 --> CT[Total cien ms el maximo]
style S fill:#89b4fa,color:#11111b
style C fill:#cba6f7,color:#11111b
style ST fill:#f38ba8,color:#11111b
style CT fill:#a6e3a1,color:#11111b