Rust aan de edge: wanneer het loont, wanneer niet

Rust is een flinke investering. De compile-tijden, de tijd die de borrow checker kost om onder de knie te krijgen, het kleinere library-ecosysteem in sommige domeinen. Die investering op de verkeerde plek besteden is een van de duurdere fouten die een team kan maken. We hebben inmiddels genoeg Rust live gezet 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. Als de workload neerkomt op parsen en routeren binnen een budget onder de milliseconde, geeft Rust je een latency-ondergrens die V8 niet haalt. We draaien een Rust-service voor de API van een klant die drie tot vijf milliseconden van elk request afhaalt, wat op hun volume oploopt tot echt geld.

De tweede zijn datapipelines die stream-processing nodig hebben zonder GC-pauzes. Arrow, Polars, eigen binaire formaten. Alles waar een GC-pauze van 200ms de streaming-garantie om zeep helpt. Rust geeft je voorspelbaar allocatie-gedrag op een manier die Go en Node niet voor elkaar krijgen.

De derde is alles dat zwaar op FFI leunt: native bindings naar een C/C++ library, integraties op systeemniveau, codecs. Het binding-ecosysteem van Rust is inmiddels volwassen genoeg dat dit vaak overzichtelijker is dan de vergelijkbare Node- of Python-wrapper.

Waar Rust de verkeerde keuze is

• CRUD-API's. Het performance-plafond doet er niet toe; de snelheid waarmee ontwikkelaars werken wel. Gebruik TypeScript op Node, Go, of desnoods Python.
• Alles waar het team niemand zal houden die Rust kan lezen en onderhouden. De borrow checker is geen code smell, maar een Rust-codebase waar niemand meer actief naar omkijkt is lastiger over te dragen dan het JS-equivalent.
• Frontend. WASM voor hot loops, prima. Maar je component-framework vervangen door Yew of Leptos zonder concrete reden: nee.
• Lijmwerk. Drie SaaS-API's aan elkaar knopen, een webhook handler schrijven, een admin tool bouwen. Bij dat soort werk is de investering weggegooid.

Hoe we een Rust-bruggehoofd structureren

Als 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, die met de rest van het systeem praat via een gewoon protocol (JSON over HTTP, Protobuf, goed gedefinieerde CSV). Het raakvlak is een contract, geen library-grens. De rest van het systeem blijft in de taal die er al was.

Door die opzet hoeft een ontwikkelaar die vlot is in TypeScript de Rust-service zelden aan te raken. Ze lezen het contract, niet de borrow checker. De Rust-kennis zit bij één of twee ontwikkelaars die het dragen; de rest van het team werkt op het contract.