Cela fait 10 ans que je parie sur Rust, et voici ce que j’attends pour la suite

• Article qui revient sur 10 années d’adoption de Rust en production depuis juste après la sortie de Rust 1.0, et sur les attentes pour les 10 prochaines années
• Au début, il a fallu composer avec des problèmes de compatibilité entre versions, des temps de build élevés et l’adaptation au borrow checker
• La communauté et l’écosystème Rust ont progressé rapidement grâce à un excellent sens de la programmation et à une forte culture communautaire, avec une concentration marquée de développeurs très talentueux autour de Rust
• Rust est désormais un “choix sûr” pour les systèmes généraux et le backend, et les progrès de la bibliothèque standard comme la maturité de l’écosystème de crates ont fortement réduit l’incertitude
• Le texte présente en détail les défis restants et les axes de progrès de Rust, notamment la vitesse de build, la portabilité, les fonctionnalités const, la concurrence et l’extension à davantage de domaines
• Les 10 prochaines années devraient apporter des compilations plus rapides, une expansion vers davantage de domaines et une transformation de l’expérience développeur, avec une boucle de rétroaction positive de l’écosystème Rust appelée à s’accélérer

---

• En juin 2015, environ un mois après l’effervescence liée à la sortie de Rust 1.0, l’auteur a écrit son premier code Rust
• Après avoir utilisé C, Python et JavaScript, il a découvert Rust et n’a plus regardé en arrière
• Il partage 10 ans de réflexion à partir de son expérience dans deux startups construites sur Rust et de plus de 500 000 lignes de code écrites

Les débuts ont été difficiles - The early days were painful

• Lors des premières adoptions de Rust, la compatibilité des versions entre les crates et le compilateur était très instable, et même de petits correctifs imposaient souvent une mise à jour complète de l’environnement de build
• Le borrow checker et la gestion des lifetimes paraissaient difficiles à appréhender, et les temps de compilation augmentaient fortement à mesure que les types complexes se multipliaient
• Chaque nouvelle fonctionnalité ou correction de bug donnait l’impression de devoir mettre à jour “toutes les versions du monde”, et trouver des versions compatibles demandait énormément de temps

L’excellence de la communauté Rust - The people were and are exceptional

• L’écosystème Rust s’appuie sur une culture de programmation remarquable, tournée vers des implémentations simples et élégantes, ainsi que des performances rapides et robustes
• Par rapport à TypeScript ou Python, la structure des dépendances en Rust est bien plus propre et les builds bien plus simples
• L’engagement des bénévoles de la communauté et leur attitude prudente du type “pas maintenant / pas encore” ont joué un rôle central
• À Londres, recruter des développeurs Rust a constitué un avantage important, et le niveau moyen des développeurs Rust est très élevé

Rust est devenu un pari sûr (dans certains domaines) - Rust has become a safe bet (in some domains)

• Au début, l’absence de nombreuses briques dans la bibliothèque standard (std) obligeait à écrire soi-même des fonctions utilitaires et des correctifs, mais aujourd’hui l’essentiel est intégré dans std et dans les crates, ce qui réduit fortement l’incertitude
• La prévisibilité des builds et des mises à niveau, la réduction des dépendances externes, le respect du semver, ainsi que les améliorations du borrow checker et du moteur d’inférence ont considérablement stabilisé l’expérience Rust
• Les nouvelles crates comme jiff, polars ou tauri ont été développées à partir des leçons du passé, tandis que tokio, hyper ou regex ont déjà fait leurs preuves en production
• Autrefois, réinventer la roue était inévitable ; aujourd’hui, il est possible de se concentrer sur la logique métier pour développer des applications performantes et robustes

L’environnement de développement que Rust offre aujourd’hui - Rust today feels like what programming should be

• Rust est un langage conçu avec une vraie empathie pour les programmeurs, grâce à un système de build concis et robuste, d’excellents messages d’erreur et lints, une documentation remarquable, une très bonne intégration IDE et une CI / des tests de régression puissants
• Parmi les grands projets open source, peu de langages sont aussi favorables aux programmeurs que Rust
• Les investissements de long terme de très nombreuses communautés et de leurs contributeurs sont le facteur clé qui a façonné Rust tel qu’il est aujourd’hui

Ce que j’attends des 10 prochaines années - What I’m looking forward to over the next 10 years

Des builds plus simples et plus rapides - Simpler and faster builds

• L’auteur s’attend à ce que se poursuive le remplacement de dépendances complexes ou lentes par des alternatives plus simples et plus rapides
• Parmi les pistes prometteuses : une bibliothèque standard entièrement en Rust, moins de dépendances envers le linker système et les bibliothèques système, de la cryptographie pure Rust, des BTreeMap persistants, ou encore des moteurs de jeu basés sur Rust
• Chez Tably aussi, la vitesse de compilation du frontend et du backend s’est améliorée de 60 % ces derniers mois

Une meilleure portabilité et moins de #[cfg()] - Improved portability and less #[cfg()]

• Tester les nombreuses combinaisons de plateformes et d’options reste difficile, et #[cfg()] entraîne du code non testé, une documentation incomplète et des problèmes d’IDE
• Déplacer #[cfg()] dans le système de traits pourrait permettre de meilleures garanties selon la plateforme ou les options, moins de recompilations, un cache MIR et une CI plus rapide

Que tout le code devienne const - Everything being const

• Faire davantage de travail à la compilation permettrait de réduire la dépendance aux macros et aux build scripts, tout en évitant plus tôt certaines erreurs d’exécution
• Les possibilités restent limitées aujourd’hui, mais l’objectif est d’aller vers un Rust où “tout le code peut s’exécuter dans un contexte const”

Simplifier la concurrence - Simpler concurrency

• Le modèle asynchrone actuel de Rust est complexe en pratique, avec des contraintes comme static, la cancellation-safety ou certaines limitations liées aux traits
• Comme avec les anciens user-space green threads (libgreen), il faudrait viser une concurrence plus simple au niveau du langage

Devenir excellent dans davantage de domaines - Excelling in more domains

• L’usage de Rust dans le navigateur web, en particulier autour de wasm / rustwasm, reste encore largement à défricher, avec des défis comme les stack traces cross-browser
  • Des frameworks comme leptos ou sycamore continuent de progresser, mais il reste encore de la marge
• Rapid prototyping, logique métier, GUI, machine learning, développement de jeux : dans tous ces domaines où Rust n’a pas encore complètement percé, l’auteur s’attend à des progrès continus

Conclusion

• L’avenir de la croissance de Rust paraît très clair et prometteur
• Plus son adoption augmente, plus les capacités d’ingénierie et de test progressent, ce qui crée un cercle vertueux d’amélioration et d’adoption élargie
• Les 10 années à venir devraient concrétiser des compilations plus rapides, une application à des domaines variés et une expérience de développement plus fluide
• L’auteur attend avec impatience la nouvelle décennie de Rust

[ndrgrd]

Rust a beaucoup de qualités, mais le langage est trop exigeant.
Quand on utilise Rust, on a l’impression de faire des recherches sur le langage lui-même plutôt que de se concentrer sur l’implémentation de l’idée.

Pour migrer un projet existant, par exemple depuis C++, cela ne pose sans doute pas de problème particulier,
mais je ne suis pas sûr que ce soit vraiment confortable à utiliser pour concrétiser de nouvelles idées.

[felizgeek]

Je recommande Python pour le prototypage.

[ndrgrd]

Personnellement, comme je préfère les systèmes de types, j'utilise actuellement C# et je trouve que c'est satisfaisant à ce niveau.

[codemasterkimc]

Personnellement, si l’on pense à l’environnement de la planète, c’est RUST. Du code Spring legacy vers Axum !!!

[GN⁺]

Avis Hacker News

• C’est un billet très positif et il correspond aussi à mon expérience. Mais si je devais citer un point sombre, ce serait celui-ci :
  "async a un coût de complexité relativement élevé en raison de la borne static, de la sûreté de l’annulation, ainsi que des limitations liées aux traits et à dyn. À l’heure actuelle, rien n’indique vraiment que ce problème sera résolu. La bifurcation entre primitives synchrones et asynchrones, ainsi que les caractéristiques propres à l’écosystème, augmentent le async tax (coût supplémentaire). Les solutions fondées sur les effects ne semblent pas particulièrement prometteuses non plus."
  "Avant Rust 1.0, il y avait une solution appelée libgreen. Elle permettait d’implémenter la concurrence en espace utilisateur sans bifurcation, mais elle a finalement été supprimée en raison de coûts importants en performances, portabilité et maintenance. Je pense que cela vaudrait la peine d’y réfléchir de nouveau si l’on disposait de capacités d’ingénierie suffisantes. Un jour, j’aimerais créer un PoC qui fasse un wrapping zero-cost de std::{fs, net} et fiber::{spawn, select} avec des generators"
  • Je suis d’avis que l’idée selon laquelle "la borne 'static augmente la complexité" relève d’un choix de conception du runtime async Tokio, plutôt que du design global de Rust. Le runtime async Embassy fonctionne sans cette borne, mais en contrepartie il faut gérer soi-même le pinning. La borne 'static vise en réalité à réduire la complexité
• Ayant découvert Rust fin 2022 et m’y étant plongé pour l’étudier, je trouve toujours fascinants les retours d’expérience de ceux qui ont appris le langage à l’époque plus difficile de 2015. J’ai eu la chance de pouvoir l’apprendre à un moment où Rust était plus mature, ce qui a un peu adouci une courbe d’apprentissage déjà raide. En ce moment, j’ai l’impression de revivre avec Zig ce que le billet décrit des débuts de Rust. Zig semble se situer à un stade similaire à celui du Rust des premiers jours. Cela dit, je l’utilise déjà avec plaisir
  • Il existe une forte culture du "laisser les choses en meilleur état qu’on ne les a trouvées". L’idée s’est imposée que si un outil ou un langage prête à confusion, ce n’est pas la faute de l’utilisateur. Si quelque chose m’a embrouillé, cela embrouillera aussi d’autres personnes, donc l’améliorer à chaque fois qu’on le constate profite énormément à tout le monde. Le proverbe selon lequel le deuxième meilleur moment pour planter un arbre, c’est aujourd’hui, s’applique bien ici. Grâce à cette culture, quelqu’un qui a essayé Rust par le passé et s’y est cassé les dents peut vivre une expérience nettement meilleure un an plus tard. C’est pourquoi le meilleur conseil à donner à un débutant Rust était : "attends juste 6 mois"
  • Si un langage est adopté par des Big Tech comme MSFT, Google, ou par de grands projets open source comme Linux, c’est déjà la preuve que son écosystème est suffisamment mature. Mais pour Zig, je n’ai pas encore cette certitude, car il ne montre pas encore de (grands) changements par rapport aux outils existants
• J’ai l’impression que Rust encourage la programmation fonctionnelle. Au départ, j’essayais de créer un parseur qui modifiait son état interne à chaque advance, mais c’était difficile à cause de la mutabilité et du système d’emprunt (borrowing), donc j’ai dû passer à un parseur sans état. J’ai fini par adopter une structure qui renvoie des index au lieu de modifier un index interne. Je me demande si ce genre de situation, où les approches habituelles fonctionnent mal et obligent à repenser sa manière de faire en Rust, est fréquent
  • J’ai eu une expérience similaire. Dans les cas simples, un style mutable et impératif ne pose pas vraiment de problème, mais à mesure que la complexité augmente, je bascule vers un style fonctionnel et j’essaie d’éviter autant que possible les mutations. À cause du borrow checker et des lifetimes, les patterns traditionnels deviennent difficiles, et on tend naturellement vers le fonctionnel. Cela peut être pénible si l’on n’a pas l’habitude d’implémenter ainsi, mais c’est aussi une expérience où le compilateur devient bien plus satisfaisant
• Async/await est la seule raison pour laquelle je n’utilise pas Rust
  • En réalité, je pense que async/await est l’une des principales raisons d’utiliser Rust. Cela simplifie énormément les patterns de concurrence. Au début, j’avais l’impression qu’il s’agissait d’une sorte de contagion maligne où tout le code finissait forcément par devoir devenir async, mais une fois qu’on apprend à interagir avec du code async, cela devient confortable. En général, spawn, spawn_blocking, futures::stream couvrent 90 % des usages, et si l’on pose correctement des "frontières", l’async n’a même pas besoin de se propager
  • Je peux comprendre dans une certaine mesure. Mais pour moi, async/await s’intègre parfaitement à Rust, au point que c’est devenu l’une de mes principales raisons de l’utiliser. J’aime aussi la syntaxe et le problème du function colouring ne me dérange pas vraiment. En particulier avec Tokio, comme il existe des versions async de toutes les fonctions standard nécessaires, on a l’impression que les solutions se mettent bien en place. Ce genre de point peut certes constituer une barrière, mais comme il est bien plus facile d’écrire des programmes concurrents et que les performances sont correctes, j’en suis satisfait. Je tâtonne un peu sur des sujets comme la cancellation, mais je considère que c’est davantage une limite de ma compétence
  • Aujourd’hui, tout cela n’est-il pas déjà fourni ?