Rust n'est pas le langage par défaut du web front, mais il occupe une place croissante **côté serveur** et **via WebAssembly** dans le navigateur. Créé par Graydon Hoare chez Mozilla, le langage est aujourd'hui porté par la Rust Foundation. Des acteurs comme AWS (Firecracker) ou Discord l'utilisent pour des composants sensibles à la latence ou à la charge. Ce n'est pas un remplacement automatique de Node.js ou PHP. C'est un choix d'ingénierie quand la robustesse et la performance priment sur la vitesse de mise en marché initiale. ### Performances et sécurité mémoire Rust compile vers du code natif et **n'a pas de ramasse-miettes**. La mémoire est gérée à la compilation via le modèle d'ownership, les emprunts (`borrow`) et le vérificateur d'emprunts. Les erreurs de données partagées ou de fuites sont en grande partie détectées **avant** la production, ce qui réduit une classe de bugs difficiles à reproduire sous forte charge. Moins de pauses liées au GC sur des services à fort trafic (API, workers, proxies). Le compilateur refuse de nombreuses opérations risquées. Le coût se paie en temps de compilation et en courbe d'apprentissage. Les abstractions autour des threads et de l'async (écosystème Tokio, etc.) ciblent des backends exigeants. ### Rust et l'écosystème web (JavaScript) Sur le web, Rust intervient surtout **en complément** de JavaScript : - **Backend** : frameworks comme Axum ou Actix Web pour des API et microservices. - **WebAssembly** : compilation vers WASM (wasm-bindgen) pour exécuter du code performant dans le navigateur, parfois publié en paquets npm. L'interopérabilité existe, mais la **stack complète en Rust** (du front au back) reste rare pour une PME. On combine le plus souvent Rust (module critique) et JavaScript/TypeScript (reste de l'app). Idéal pour des endpoints à forte charge ou des traitements CPU-bound. Utile pour éditeurs, calcul client ou codecs, pas pour tout remplacer React ou Next.js. Des crates peuvent être exposées au front via WASM. Ce n'est pas l'équivalent d'un backend Node « full stack ». ### Limites réalistes - **Courbe d'apprentissage** : ownership, lifetimes, async. Comptez plusieurs semaines avant d'être productif si l'équipe ne vient que du JavaScript ou du PHP. - **Écosystème web** : crates matures côté serveur, mais moins de CMS, thèmes et hébergeurs « clé en main » qu'autour de PHP ou Node. - **Temps de build** : compilations plus longues qu'un interprété. Anticipez la CI et l'expérience développeur. - **Recrutement** : profils Rust disponibles, mais moins nombreux que JavaScript en France. Pour une PME, Rust se justifie surtout sur un **périmètre précis** (service critique, binaire CLI, module WASM), pas comme refonte globale d'un site vitrine ou d'un e-commerce déjà stable sous Next.js ou WordPress. ### Cas d'usage pertinents - API et microservices à forte charge ou latence sensible. - Outils internes, agents, pipelines de traitement. - Modules WebAssembly pour accélérer une partie du front. - Infrastructures cloud (ex. microVM, proxies) où la sécurité mémoire est un critère fort. Messagerie, jeux, agrégation d'événements, là où Discord a documenté des gains mesurables. Contrats stables, charge prévisible, équipe prête à maintenir du Rust. Refonte « pour la mode » d'un monolithe PHP/JS qui fonctionne déjà. ## Sources - Rust (langage), Wikipédia - Site officiel Rust - Discord, passage de Go à Rust - AWS, Firecracker (open source, Rust) En résumé, Rust apporte des **promesses solides** sur la performance et la fiabilité mémoire, avec des **limites organisationnelles et web** qu'il faut intégrer avant de basculer une équipe ou un produit existant.

#web

Rust pour le web : promesses et limites