Respuesta

La asincronía en Rust se implementa a través de Future — un objeto que representa una tarea cuyo resultado se obtendrá en el futuro. Las funciones declaradas con async fn devuelven una estructura generador anónima que implementa el trait Future. Para ejecutar código asincrónico, se utiliza un runtime (por ejemplo, Tokio o async-std), ya que la biblioteca estándar no contiene un event loop incorporado.

Las principales características de Rust:

• Abstracciones de costo cero — el compilador transforma el código async en una máquina de estados sin asignaciones en el montón, si la tarea lo permite.
• Ausencia de un recolector de basura nativo — todos los recursos son gestionados explícitamente, lo que requiere especial atención a los lifetime y la propiedad.
• Send/Sync — restricciones sobre la portabilidad y sincronización de tareas entre hilos.

Ejemplo:

use tokio::time::sleep;
use std::time::Duration;

async fn foo() {
    println!("Hola");
    sleep(Duration::from_secs(1)).await;
    println!("Mundo!");
}

#[tokio::main]
async fn main() {
    foo().await;
}

Pregunta con trampa

¿Puede una función asincrónica en Rust ejecutarse inmediatamente al ser llamada por defecto? ¿Por qué?

Respuesta: No. La llamada a async fn no devuelve un resultado, sino un objeto de tipo Future (máquina de estados). Para la ejecución real se requiere llamar a .await o pasar el Future al runtime. La llamada en sí solo crea una descripción de la tarea, pero no la ejecuta.

Ejemplo:

async fn answer() -> u32 { 42 }
let fut = answer(); // aquí no hay ejecución, solo creación de future
let result = fut.await; // la ejecución comienza aquí

Ejemplos de errores reales debido a la falta de conocimiento sobre los matices del tema

---

Historia

En un proyecto de backend de alto carga, un desarrollador junior declaró varias funciones async, pero no llamó a .await en ninguna parte. Como resultado, los hilos principales se ejecutaron de manera sincrónica, lo que llevó a una caída en el rendimiento y un aumento en el tiempo de respuesta de 3 veces.

Historia

En un microservicio, se utilizó una API asincrónica, interactuando a través de tokio. Durante la migración, el desarrollador intentó usar async-std y tokio al mismo tiempo, olvidando que debe haber solo un event loop. Como resultado, se produjeron bloqueos y pánicos en el runtime, ya que ambos runtimes entraron en conflicto.

Historia

Uno de los miembros del equipo olvidó las restricciones Send/Sync en los tipos utilizados dentro de Future. Al intentar compartir future entre hilos, la aplicación falló con un error de compilación que requería la implementación de Send para una determinada estructura, lo que requirió una revisión de la arquitectura del almacenamiento de estado.