Future & .await, ou le calcul qui ne se lance pas Future & .await, or the computation that doesn't start

La concurrence sans threads : attendre sans bloquer, pas calculer en parallèle.Concurrency without threads: waiting without blocking, not computing in parallel.

Le Vol 7 parlait de parallélisme : faire tourner plusieurs calculs en même temps, sur plusieurs cœurs. L'async répond à un besoin différent, qu'on confond sans cesse avec celui-là : attendre sans bloquer. Pense à un serveur qui tient dix mille connexions, dont chacune dort la plupart du temps en attendant le réseau. Lancer dix mille threads serait un gâchis — chacun coûte sa pile, son changement de contexte. On veut une poignée de threads qui jonglent entre des milliers de tâches en sommeil, reprenant chacune juste quand sa donnée arrive. C'est l'async. En Rust, une async fn ne retourne pas sa valeur : elle retourne un Future, une valeur qui décrit le calcul à mener. Et .await est l'opérateur qui dit « mène ce calcul à terme, mais si tu dois attendre, rends la main pour qu'autre chose avance ».Vol 7 spoke of parallelism: running several computations at once, on several cores. Async answers a different need, constantly confused with that one: waiting without blocking. Picture a server holding ten thousand connections, each asleep most of the time waiting on the network. Spawning ten thousand threads would be waste — each costs its stack, its context switch. You want a handful of threads juggling thousands of sleeping tasks, resuming each just when its data arrives. That's async. In Rust, an async fn doesn't return its value: it returns a Future, a value describing the computation to carry out. And .await is the operator that says 'carry this computation to completion, but if you must wait, yield so something else can advance'.

// async fn ne RETOURNE pas un T — il retourne un Future<Output = T>
async fn charger(url: &str) -> String {
    // … une requête réseau : on ATTEND la réponse sans bloquer le thread
    reponse
}

#[tokio::main]                          // le runtime : il fournit l'exécuteur qui fait tourner les Futures
async fn main() {
    let page = charger("/index").await; // .await : suspend CETTE tâche jusqu'à ce que le Future soit prêt
    println!("{}", page.len());         // … et pendant l'attente, l'exécuteur fait avancer d'autres tâches
}

Appeler une async fn ne lance rien : le Future attend qu'on le réclame.Calling an async fn launches nothing: the Future waits to be claimed.

Voici la surprise qui désarçonne tout dev venant de JavaScript, et le piège le plus courant du débutant en async Rust. La syntaxe est identique — async, await, presque mot pour mot. Le modèle, lui, est inversé. En JS, une promesse est eager : fetch(url) déclenche la requête à l'instant où on l'écrit, qu'on l'attende ou non. En Rust, un Future est lazy : appeler charger(url) ne fait strictement rien — on obtient un objet inerte qui décrit le travail à faire, et ce travail ne commence qu'au .await (ou à un spawn). La conséquence pratique mord vite : un Future qu'on oublie d'attendre ne s'exécute jamais. Pas de crash, pas d'exception — juste un avertissement du compilateur, et une fonction qui n'a tout simplement pas tourné. C'est le bug silencieux par excellence.Here's the surprise that throws every dev coming from JavaScript, and the most common beginner trap in async Rust. The syntax is identical — async, await, almost word for word. The model, though, is inverted. In JS, a promise is eager: fetch(url) triggers the request the instant you write it, awaited or not. In Rust, a Future is lazy: calling charger(url) does strictly nothing — you get an inert object describing the work to do, and that work only begins at .await (or a spawn). The practical consequence bites fast: a Future you forget to await never runs. No crash, no exception — just a compiler warning, and a function that simply didn't run. It's the silent bug par excellence.

// Rust : le Future est INERTE jusqu'au .await (lazy)
charger("/a");                // ✕ rien ne se passe — AUCUNE requête envoyée
//   warning: unused implementer of `Future` that must be used
//   note: futures do nothing unless you `.await` or poll them

let fut = charger("/a");      // gardé dans une variable : toujours inerte
let reponse = fut.await;      // ← c'est SEULEMENT ici que le travail démarre

// oublier le .await ? la fonction ne s'exécute JAMAIS. pas d'erreur fatale,
// juste un avertissement — le bug silencieux le plus fréquent en async Rust.

« Futures do nothing unless you .await or poll them » — le compilateur le dit lui-même. Un Future est une valeur comme une autre : la créer ne la déclenche pas, exactement comme construire une struct n'exécute aucune logique. C'est cohérent avec tout le reste de Rust — rien d'implicite, rien qui parte dans ton dos — mais c'est l'inverse exact du réflexe JS. Le corollaire heureux : tu contrôles précisément quand le travail commence, et tu peux composer des Future avant d'en lancer aucun.'Futures do nothing unless you .await or poll them' — the compiler says so itself. A Future is a value like any other: creating it doesn't trigger it, exactly as building a struct runs no logic. It's consistent with all the rest of Rust — nothing implicit, nothing firing behind your back — but it's the exact inverse of the JS reflex. The happy corollary: you control precisely when the work starts, and you can compose Futures before launching any.

Un Future est une machine à états que l'exécuteur fait avancer par poll.A Future is a state machine the executor advances by poll.

Sous la syntaxe, le mécanisme est étonnamment simple. Future est un trait avec une seule méthode, poll, qui rend Poll : soit Ready(valeur) si le calcul est terminé, soit Pending s'il faut encore attendre. L'exécuteur du runtime appelle poll ; tant qu'il reçoit Pending, il met la tâche de côté et va poller d'autres tâches prêtes. Comment sait-il quand revenir ? La tâche, en rendant Pending, laisse un waker — un signal que la ressource (le socket, le timer) déclenchera dès qu'elle sera prête, replaçant la tâche dans la file. Et le async fn que tu écris ? Le compilateur le réécrit en une machine à états : chaque .await devient un point de suspension où l'état local est sauvegardé, pour pouvoir reprendre exactement là plus tard. Tu écris du code linéaire ; le compilateur en fait un automate.Beneath the syntax, the mechanism is surprisingly simple. Future is a trait with a single method, poll, returning Poll: either Ready(value) if the computation is done, or Pending if more waiting is needed. The runtime's executor calls poll; as long as it gets Pending, it sets the task aside and polls other ready tasks. How does it know when to come back? The task, returning Pending, leaves a waker — a signal the resource (the socket, the timer) will fire as soon as it's ready, putting the task back in the queue. And the async fn you write? The compiler rewrites it into a state machine: each .await becomes a suspension point where local state is saved, to resume exactly there later. You write linear code; the compiler makes it an automaton.

trait Future {
    type Output;
    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}
enum Poll<T> { Ready(T), Pending }    // soit la valeur est prête, soit « repasse plus tard »

// .await se traduit (en gros) par : « poll ce Future ; s'il rend Pending, RENDS LA MAIN
// à l'exécuteur en laissant un waker, et reprends quand la ressource sera prête ».

async fn requete() -> String {
    let socket = connecter().await;       // ← point de suspension 1
    let octets  = socket.lire().await;    // ← point de suspension 2
    decoder(octets)
}
// le compilateur RÉÉCRIT cette fonction en une machine à états : un enum dont chaque
// variante est « où en est-on entre deux .await ». poll() fait avancer d'un état au
// suivant ; entre deux appels, l'état (le socket, les variables locales) est SAUVEGARDÉ.

Tirer un runtime async pour du calcul — et bloquer l'exécuteur qu'on vient d'installer.Pulling an async runtime for computation — and blocking the executor you just installed.

Une fois async/await en main, la tentation est de tout y passer — comme on a vu le réflexe Mutex partout au Vol 7. Mais l'async ne sert qu'à une chose : ne pas gaspiller un thread pendant qu'on attend. Il ne rend aucun calcul plus rapide. Pire : un calcul lourd, ou un appel bloquant classique (std::thread::sleep, une lecture de fichier synchrone, une requête SQL bloquante) placé dans une tâche async, monopolise le thread de l'exécuteur — car il n'y a pas de .await pour rendre la main. Toutes les autres tâches de ce thread gèlent, le temps que le calcul finisse. Le gain de l'async s'effondre exactement là où on croyait l'étendre. Le contre-exemple le plus pur : monter tout un runtime pour un programme CPU-bound qui n'avait besoin que de threads.Once async/await is in hand, the temptation is to route everything through it — as we saw the Mutex-everywhere reflex in Vol 7. But async serves only one thing: not wasting a thread while you wait. It makes no computation faster. Worse: a heavy computation, or a classic blocking call (std::thread::sleep, a synchronous file read, a blocking SQL query) placed in an async task, monopolizes the executor's thread — because there's no .await to yield. All the other tasks on that thread freeze until the computation finishes. Async's gain collapses exactly where you thought you'd extend it. The purest counter-example: spinning up a whole runtime for a CPU-bound program that needed only threads.

#[tokio::main]
async fn main() {
    tokio::join!(
        servir_requetes(),               // veut juste attendre le réseau (I/O-bound)
        async {
            std::thread::sleep(CINQ_S);  // ✕ appel BLOQUANT dans une tâche async
            compresser(gros_fichier);    //   calcul LOURD, aucun .await → ne rend jamais la main
        },
    );
    // pendant ces secondes, servir_requetes() est GELÉ : le thread de l'exécuteur
    // est monopolisé. on a tiré tokio… pour du CPU, qui voulait juste des threads.
}

#[tokio::main]
async fn main() {
    tokio::join!(
        servir_requetes(),
        async {
            tokio::time::sleep(CINQ_S).await;              // ✓ attente qui REND la main
            tokio::task::spawn_blocking(|| compresser(gros_fichier))
                .await.unwrap();                           // ✓ le CPU part sur un pool dédié
        },
    );
}
// et si le programme est PUREMENT CPU-bound ? alors pas d'async du tout : des threads (Vol 7).

Deux corrections, deux principes. L'attente passe par la version async de l'outil — tokio::time::sleep().await au lieu de std::thread::sleep — pour que la tâche rende la main au lieu de geler le thread. Et le calcul lourd sort de l'exécuteur via spawn_blocking, qui le confie à un pool de threads dédié, laissant les tâches I/O respirer. Mais le vrai réflexe est en amont : si le programme est essentiellement du calcul, l'async n'a rien à y faire. Des threads (Vol 7), un scope, un Arc<Mutex> si besoin — et pas une ligne de runtime async.Two fixes, two principles. The wait goes through the async version of the tool — tokio::time::sleep().await instead of std::thread::sleep — so the task yields instead of freezing the thread. And the heavy computation leaves the executor via spawn_blocking, which hands it to a dedicated thread pool, letting the I/O tasks breathe. But the real reflex is upstream: if the program is essentially computation, async has no business there. Threads (Vol 7), a scope, an Arc<Mutex> if needed — and not a line of async runtime.