Rust aan de edge: wanneer het loont, wanneer niet

Rust is een serieuze investering. De compile-tijden, de borrow-checker ramp-up, het kleinere library-ecosysteem in sommige domeinen. Die investering op de verkeerde plek uitgeven is een van de duurdere fouten die een team kan maken. We hebben nu genoeg Rust gereleased om een echte mening te hebben over waar het zijn plek verdient en waar absoluut niet.

Drie workloads waar Rust ronduit wint

Edge runtimes zijn de eerste. Cloudflare Workers, Fastly Compute, Deno Deploy met native modules. Wanneer de workload parse-en-route is op sub-milliseconde budgets, geeft Rust je een latency-floor die V8 niet kan halen. We hebben een Rust-service voor de API van een klant die drie tot vijf milliseconden van elk request strippt, wat op hun volume optelt tot echt geld.

De tweede is datapipelines die stream-processing nodig hebben zonder GC-pauzes. Arrow, Polars, custom binaire formaten. Alles waar een 200ms GC-pauze de streaming-garantie ruïneert. Rust geeft je voorspelbaar allocatie-gedrag op een manier die Go en Node niet kunnen.

De derde is alles dat zwaar FFI raakt: native bindings naar een C/C++ library, system-level integraties, codecs. Het Rust binding-ecosysteem is nu volwassen genoeg dat dit vaak schoner is dan de equivalente Node- of Python-wrapper.

Waar Rust de verkeerde keuze is

• CRUD-API's. Het performance-plafond doet er niet toe; het developer-velocity-plafond wel. Gebruik TypeScript op Node, Go, of zelfs Python.
• Alles waar het team geen onderhouder zal vasthouden die Rust kan lezen. De borrow checker is geen code smell, maar een Rust-codebase die uit actieve zorg valt wordt moeilijker te onboarden dan het JS-equivalent.
• Frontend. WASM voor hot loops, zeker. Je component-framework vervangen door Yew of Leptos zonder specifieke reden: nee.
• Lijmwerk. Drie SaaS-API's aan elkaar plakken, een webhook handler schrijven, een admin tool bouwen. De investering is verspild op deze vormen.

Hoe we een Rust-bruggehoofd structureren

Wanneer Rust gerechtvaardigd is, houden we het klein en geïsoleerd. Eén binary of service met een smal contract: een HTTP-endpoint, een Kafka-consumer, een CLI, geschreven in Rust, pratend met de rest van het systeem via een normaal protocol (JSON over HTTP, Protobuf, goed gedefinieerde CSV). Het oppervlak is een contract, geen library-grens. De rest van het systeem blijft in welke taal er al is.

Deze vorm laat een TypeScript-vloeiende engineer de Rust-service zelden aanraken en overleven. Ze lezen het contract, niet de borrow checker. De Rust-expertise zit bij één of twee engineers die het dragen; de rest van het team werkt op het contract.