Rust Hebdo #1 : Sortie de la version stable 1.99.0 et Tokio dévoile un framework Web full-stack

📦 Suivi des versions

Sortie de Rust 1.99.0 stable (Date de publication : 01/10/2026)

La dernière version stable entre officiellement dans l’ère 1.99, à un pas seulement de la 2.0 ou d’une refonte majeure. Cette mise à jour se concentre principalement sur l’interopérabilité FFI de bas niveau et la consolidation des manipulations de mémoire avec unsafe. Retrouvez notre analyse détaillée sur : /lang/2026-10-01-rust-1-99-release/

1. Stabilisation des fonctions variadiques extern "C" Auparavant, Rust ne pouvait invoquer des fonctions variadiques C que de manière externe via la FFI (comme libc::printf). Désormais, les développeurs peuvent utiliser les ABI extern "C" ou extern "C-unwind" et le type sous-jacent VaList (compatible avec va_list) pour définir et implémenter directement des fonctions variadiques en Rust. Cela fait tomber les frontières entre langages et élimine le besoin d’écrire des couches d’encapsulation (glue code) en C lors de la réécriture de bibliothèques historiques.
2. Consultation de la disposition mémoire des pointeurs bruts vers des types non Sized Trois fonctions destinées aux pointeurs bruts (raw pointers), dont Layout::for_value_raw et mem::size_of_val_raw, sont désormais stables. Auparavant, dans les allocateurs de mémoire personnalisés, l’inspection des métadonnées pour des pointeurs non alignés ou des types à taille dynamique (DST) exigeait une conversion forcée en références, ce qui entraînait un risque élevé de comportement indéfini (UB). La nouvelle API autorise la lecture légitime de la disposition mémoire directement depuis un pointeur brut, renforçant ainsi les garanties de sécurité des opérations de bas niveau.

Commentaire de la rédaction : De la stabilisation du déréférencement des pointeurs bruts en 1.82 à l’achèvement de l’API de disposition mémoire en 1.99, l’équipe officielle de Rust a mené une stratégie progressive sur plus de deux ans pour s’affranchir de la dépendance obligatoire aux références dans les contextes unsafe de bas niveau. Cela réduit concrètement la charge cognitive lors de l’implémentation de structures de données concurrentes hautement performantes.

---

📝 Articles de fond

Tokio dévoile le framework Web full-stack Topcoat et vise l’expérience offerte par Rails

• Que s’est-il passé : L’équipe Tokio a partagé les avancées de Topcoat, un framework full-stack misant sur le principe du « tout compris » (batteries-included). Il intègre l’ORM Toasty, un moteur de vues, l’envoi de courriels et des fonctionnalités réactives côté client comparables à Phoenix LiveView dans sa version 0.9.
• Pourquoi c’est important : Son créateur a été un contributeur majeur de Ruby on Rails, et ambitionne d’associer la formidable frugalité en ressources d’un binaire Rust autonome (~20 Mo d’empreinte mémoire) à la rapidité de prototypage réputée de Rails permettant de « monter un site en 15 minutes ».
• Qui est concerné : Les développeurs Web full-stack. Jusqu’à présent, l’écosystème Web de Rust reposait principalement sur des micro-frameworks comme Axum ou Actix, exigeant un assemblage manuel. Topcoat trace une voie officielle de haut niveau pour concevoir rapidement des applications métier CRUD.
• Commentaire de la rédaction : Alors que le paysage des bibliothèques réseau de bas niveau est désormais mature et stabilisé, voir Tokio se lancer dans le full-stack n’est pas un hasard. Face aux écosystèmes Node.js ou Go, Rust manquait d’un framework prescripteur fédérateur. Topcoat s’appuie sur la génération de code boilerplate par macros pour réduire les annotations explicites de durées de vie (lifetimes) : une illustration parfaite de calcul investi à la compilation pour faire gagner un temps précieux aux développeurs.

Accélération du compilateur : le temps moyen diminue de 4,5 % en septembre

• Que s’est-il passé : Le rapport de performance de Nicholas Nethercote pour septembre révèle une baisse moyenne de 4,57 % du temps d’horloge réelle sur 629 benchmarks. L’activation du PGO (optimisation guidée par les profils) sur Clippy a permis d’atteindre jusqu’à 18 % de gain, tandis que la montée de version vers LLVM 23 a apporté une accélération générale supplémentaire de 1,2 %.
• Pourquoi c’est important : Réaliser 5 % d’accélération sur un cycle de développement reste un exploit rare. La percée majeure découle d’une refonte algorithmique (comme l’optimisation des parcours du graphe de flot de contrôle ou CFG, faisant chuter les invocations de apply_effects_in_block de 1,5 million à 90 000). Par ailleurs, le vérificateur d’emprunts Polonius Alpha, d’une bien meilleure précision, a été activé sur Nightly.
• Qui est concerné : L’ensemble des développeurs Rust. Pour des projets de plusieurs millions de lignes, 4,5 % d’amélioration se traduisent par plusieurs minutes économisées lors de chaque compilation locale et réduisent directement les coûts de calcul sur les serveurs CI/CD.
• Commentaire de la rédaction : Là où C++ mise sur les Modules pour remédier à la lenteur des builds, Rust continue d’extraire de la performance à la force des refactorisations algorithmiques du compilateur et des dividendes de LLVM. Les 18 % gagnés grâce au PGO illustrent également que les outils d’analyse statique internes de Rust figuraient parmi les principaux goulots d’étranglement de la chaîne d’outils.

Le mécanisme de cache de Miri expose à des fuites d’identifiants sur GitHub Actions

• Que s’est-il passé : L’équipe de réponse aux vulnérabilités de Rust a émis un bulletin d’alerte indiquant que cargo miri stocke au moment de l’exécution des variables d’environnement liées au build dans le répertoire target/. Si un projet met en cache target/ de façon globale dans GitHub Actions et autorise l’accès depuis les pull requests (PR), un attaquant peut soumettre une PR afin d’extraire et divulguer des secrets à hauts privilèges mis en cache par la branche principale.
• Pourquoi c’est important : Cette faille ne provient pas d’un bogue dans le code de Miri lui-même, mais d’une vulnérabilité secondaire découlant de la combinaison du fonctionnement de l’outil et des règles de mise en cache des services d’intégration continue.
• Qui est concerné : Les mainteneurs de projets open-source activant Miri avec un cache global dans leur CI, tout particulièrement les bibliothèques de bas niveau qui s’appuient massivement sur des tests automatisés pour valider la sûreté mémoire.
• Commentaire de la rédaction : En consultant l’historique des CVE, on constate que de telles attaques par élévation de privilèges via la mémoire cache sont survenues à plusieurs reprises dans l’écosystème NPM. La communauté Rust a pris l’habitude de mettre en cache l’intégralité du dossier target/ pour accélérer la CI ; cet événement met en lumière une faille de conception où les artéfacts de test et les données d’environnement ne sont pas isolés.

La chaîne d’outils hôte Windows 32 bits tire sa révérence

• Que s’est-il passé : L’équipe officielle a annoncé qu’à partir de Rust 1.100.0, les cibles i686-pc-windows-msvc et gnu seront rétrogradées du Tier 1 (qui fournit les exécutables hôtes comme rustc) vers le statut std-only. Les développeurs devront désormais compiler des binaires 32 bits par compilation croisée depuis des environnements 64 bits.
• Pourquoi c’est important : Windows 32 bits a atteint sa fin de vie en octobre 2025. De plus, la compilation de l’immense chaîne d’outils sur les environnements i686 provoquait de nombreux plantages (comme des erreurs de mémoire saturée OOM lors de la compilation de LLVM avec GNU C++), de sorte que le coût de maintenance de la CI dépassait désormais les bénéfices réels.
• Qui est concerné : Les développeurs de logiciels industriels ou de systèmes d’entreprise historiques. Il restera toujours possible de compiler des exécutables 32 bits, mais il ne sera plus envisageable d’installer directement le compilateur Rust sur un système 32 bits pour y développer localement.
• Commentaire de la rédaction : Ce passage forcé à la compilation croisée démontre que les besoins en ressources des infrastructures de compilation modernes telles que LLVM 23 excèdent désormais les limites physiques d’un espace d’adressage 32 bits (4 Go de RAM). Il s’agit d’une évolution naturelle dictée par le renouvellement du matériel.

---

🔥 Débats communautaires

• Framework Topcoat : Rust a-t-il vraiment besoin de son Rails ?

  • Popularité : 113 points / 100 commentaires (Hacker News)
  • Points de friction : Certains développeurs en entreprise ont exprimé des réticences, le créateur du framework ayant honnêtement admis dans son annonce qu’il « ne sait pas où cela va mener », ce qui soulève des interrogations quant à sa viabilité en production. En revanche, un autre courant fait l’éloge du projet en le comparant à Phoenix LiveView d’Elixir, estimant que pour de petites équipes, une solution complète et standardisée avec ORM et vues réactives s’avère bien plus productive que l’assemblage manuel d’un faisceau de micro-dépendances (Axum + SQLx + Tera).

• Pourquoi le compilateur Rust est-il toujours aussi lent ?

  • Popularité : 262 points / 153 commentaires (Hacker News)
  • Points de friction : Tout en saluant le gain de 4,5 % de performances, la communauté s’est penchée sur les causes fondamentales de cette lenteur. Un camp rappelle que les abstractions à coût nul (monomorphisation des génériques, développement des macros) et la vérification des emprunts imposent une complexité algorithmique intrinsèquement supérieure à celle du C. L’autre camp a analysé des commits précis pour prouver que les vrais coupables étaient d’anciens algorithmes de parcours de graphes (CFG) mal optimisés, et que le modèle d’analyse à la demande de Polonius supprimera définitivement ces calculs redondants.

---

À suivre la semaine prochaine

• Avancée de Polonius Beta : Avec l’activation par défaut du vérificateur d’emprunts Polonius Alpha dans Nightly, la communauté attend ses premiers retours sur des scénarios complexes de durées de vie intriquées. Les structures de données complexes sous forme de graphes, autrefois sujettes à de faux positifs lors de la vérification des emprunts, pourront potentiellement être réécrites sans avoir recours à unsafe.