Antwoord

Asynchroniteit in Rust wordt geïmplementeerd via Future — een object dat een taak vertegenwoordigt waarvan de uitkomst in de toekomst zal worden verkregen. Functies die zijn gedeclareerd met async fn retourneren een anonieme generatorstructuur die de Future-trait implementeert. Voor de uitvoering van asynchrone code wordt een runtime gebruikt (bijvoorbeeld Tokio of async-std), aangezien de standaardbibliotheek geen ingebouwde event loop heeft.

Belangrijkste kenmerken van Rust:

• Zero-cost abstractions — de compiler transformeert async-code in een state machine zonder heap-allocaties, indien de taak dat toelaat.
• Geen native garbage collector — alle bronnen worden expliciet beheerd, wat bijzondere aandacht vereist voor lifetime en eigenaarschap.
• Send/Sync — beperkingen op de overdraagbaarheid en synchronisatie van taken tussen threads.

Voorbeeld:

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

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

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

Vraag met een valstrik

Kan een asynchrone functie in Rust standaard onmiddellijk worden uitgevoerd bij aanroep? Waarom?

Antwoord: Nee. De aanroep van async fn retourneert niet het resultaat, maar een object van het type Future (state machine). Voor daadwerkelijke uitvoering is het nodig om .await aan te roepen of de Future aan de runtime door te geven. De aanroep creëert alleen een beschrijving van de taak, maar voert deze niet uit.

Voorbeeld:

async fn answer() -> u32 { 42 }
let fut = answer(); // hier is er geen uitvoering, alleen de creatie van future
let result = fut.await; // de uitvoering begint hier

Voorbeelden van werkelijke fouten door onbekendheid met de nuances van het onderwerp

---

Verhaal

In een highload backend-project verklaarde een junior ontwikkelaar verschillende async-functies, maar riep nergens .await aan. Hierdoor werden de belangrijkste threads synchronisch uitgevoerd, wat leidde tot méér dan drie keer zo hoge responstijden en een prestatieverlies.

Verhaal

In een microservice gebruikten ze een async API, waarbij ze door Tokio interactie hadden. Bij de migratie probeerde de ontwikkelaar async-std en Tokio tegelijk te gebruiken, en vergat dat er maar één event loop moest zijn. Dit resulteerde in vastlopen en runtime panic, omdat beide runtimes conflicteerden.

Verhaal

Een van de teamleden vergat de Send/Sync-beperkingen op de types die binnen Future werden gebruikt. Bij het proberen om een future tussen threads te delen, crashte de applicatie met een compilatiefout die om de implementatie van Send voor een bepaalde structuur vroeg, wat leidde tot een herziening van de architectuur voor statusopslag.