Rust en 2025 : viser le logiciel fondamental
(smallcultfollowing.com)- Rust fête cette année son 10e anniversaire et s’impose de plus en plus comme un langage clé pour le développement de logiciels fondamentaux (foundational software)
- Le logiciel fondamental désigne la couche qui sert de base à tout le reste, comme les noyaux de systèmes d’exploitation, les plateformes cloud, les appareils embarqués ou les outils CLI
- Rust abaisse les barrières grâce à un système de types qui garantit la sûreté mémoire, tout en offrant des performances et une fiabilité de niveau C/C++
- La mission de Rust ne se limite pas simplement à la couche de base : des projets comme Dioxus, Tauri et Leptos étendent aussi son impact au développement d’applications de plus haut niveau
- À l’avenir, les principaux axes d’investissement prévus portent sur l’interopérabilité entre langages, l’extension du système de types et le renforcement de l’écosystème
La vision de Rust : le logiciel fondamental
- La vision centrale de Rust est de rendre plus facile l’écriture et la maintenance du logiciel fondamental
- Le logiciel fondamental comprend les noyaux de systèmes d’exploitation, les infrastructures cloud, les appareils embarqués et les outils CLI qui constituent la base de tous les systèmes
- Rust est déjà adopté dans de nombreux endroits, notamment les noyaux Windows et Linux, le moteur de recherche de VSCode
ripgrep, Deno et le gestionnaire de paquets Pythonuv
- Pour ce type de logiciel, performances, fiabilité et productivité sont toutes essentielles à la fois
- Si la base s’effondre, c’est toute la couche supérieure qui en subit les conséquences, d’où l’importance cruciale de la stabilité
- Une baisse de performance dans la base devient une limite de performance pour les couches supérieures, ce qui impose un minimum d’overhead
Performances, fiabilité et productivité du logiciel fondamental
- Le logiciel fondamental, comme tout logiciel, répond à des exigences variées, mais ici chaque aspect est encore plus critique
- La fiabilité est la priorité absolue. Si la base cède, tout ce qui repose dessus échoue
- L’overhead de performance détermine la limite de performance des couches supérieures et doit donc être minimisé
- Jusqu’ici, il existait essentiellement deux options pour répondre à ces exigences
- C/C++ : offrent une grande liberté, mais exigent en contrepartie une exécution sans faute
- Java, Go et autres langages de haut niveau : nécessitent des techniques de codage particulières pour préserver les performances, avec des restrictions sur l’usage des abstractions et des commodités
- Rust change l’approche traditionnelle en combinant abstractions à coût nul et système de types garantissant la sûreté mémoire
- Il devient ainsi un outil permettant d’écrire en toute sécurité du code de haut niveau tout en obtenant simultanément des performances bas niveau et la stabilité mémoire
Abaisser la barrière d’entrée et renforcer les développeurs
- Dans les présentations de Rust, on compare souvent le système de types et les vérifications statiques à des « épinards » : bons pour la santé, mais qu’on n’a pas envie de manger
- En pratique, le système de types est un outil extrêmement puissant pour les développeurs
- Les débutants peuvent apprendre, à travers lui, à construire de bonnes architectures logicielles
- Les experts peuvent repérer plus vite les erreurs dans leurs propres conceptions structurelles
- La formule de Yehuda Katz, « les abstractions que je crée dans un état de concentration aident mon moi futur fatigué », résume bien cette idée
Au-delà du logiciel fondamental
- Même si la mission de Rust est centrée sur le logiciel fondamental, cela ne signifie pas que les autres domaines sont négligés
- Des projets comme Dioxus, Tauri et Leptos étendent Rust vers des domaines d’applications plus haut niveau, comme les interfaces GUI ou les pages web
- Les principaux atouts de Rust restent fondamentalement concentrés sur le logiciel fondamental, mais ces initiatives ne doivent pas être ignorées
Objectifs ambitieux et croissance
- Comme le logiciel fondamental exige un contrôle fin des détails de bas niveau, on a souvent tendance à considérer que l’accessibilité et l’ergonomie y sont moins importantes
- En réalité, plus le niveau de contrôle requis est élevé, plus l’ergonomie devient importante
- Si l’on aide les développeurs à se concentrer uniquement sur ce qui compte vraiment, la productivité peut fortement augmenter
- Les projets qui poussent Rust vers des usages plus haut niveau créent des opportunités pour rendre la programmation Rust plus confortable
- Ces améliorations rejaillissent ensuite directement sur le développement du logiciel fondamental
- L’essentiel est d’améliorer l’ergonomie sans perdre le contrôle ni la fiabilité
L’importance du support de l’ensemble de la stack
- Une autre raison de rendre agréable le développement d’applications de haut niveau en Rust est la possibilité de construire une stack complète avec une seule technologie
- Des développeurs qui, au départ, n’envisageaient Rust que pour certaines parties comme les services de data plane finissent souvent par l’étendre à l’ensemble de leur pile
- Cela tient au fait que Rust offre une forte productivité, ainsi que le partage de bibliothèques et de code dans un langage unique
- Un code intrinsèquement simple reste simple, quel que soit le langage dans lequel il est écrit
L’expérience de l’approfondissement progressif (Iterative Deepening)
- Idéalement, la première expérience avec Rust devrait être simple, puis permettre, à mesure que le projet avance, d’étendre progressivement davantage de contrôle de manière locale
- Cela paraît simple en théorie, mais c’est en pratique un problème très difficile
- Beaucoup de projets échouent soit parce que la barrière d’entrée pour les débutants est trop élevée, soit parce que l’apprentissage des niveaux de contrôle plus poussés demande trop de connaissances
- Rust n’y parvient pas toujours, mais le travail d’amélioration se poursuit en continu
La suite du programme
- Cet article est le premier d’une série, et les quatre suivants présenteront les investissements nécessaires pour rendre Rust encore mieux adapté au logiciel fondamental
- Interopérabilité fluide entre langages (smooth language interop) et extensibilité
- Clarification des objectifs via le système de types (clarity of purpose)
- Renforcement de l’écosystème : meilleures recommandations, meilleurs outils et mobilisation de la Rust Foundation
- Le dernier article abordera l’organisation de l’open source Rust, avec pour objectif de faire de la contribution et de la maintenance des activités aussi accessibles et agréables que possible
15 commentaires
Rust a beau avoir l’air pas mal, j’ai l’impression que c’est la seule langue que j’hésite à adopter à cause de son fandom toxique (?)
J’aurais aimé qu’il existe un gestionnaire de paquets standard pour C ou C++. Quand je vois Cargo, c’est toujours ce que je me dis.
Les épinards sont pourtant tellement bons....
Aujourd’hui, il n’y a pratiquement plus d’endroit où Rust n’est pas utilisé.
Je travaille bien dans un grand groupe, mais il n’y a aucun domaine où l’on utilise Rust. S’il vous plaît, n’induisez pas les gens en erreur.
Ne cherchez pas la bagarre.
Pfff ;;
Ne me cherchez pas, hein tremblement
Ohlala ; ;
Pfff;;;
Tout le reste mis à part, j’en peux plus en ce moment à cause des rustacéens. Hors ligne, c’est un ultra-minoritaire parmi les minoritaires, mais en ligne c’est presque Daech... Franchement, j’aimerais bien qu’ils se regroupent quelque part et restent entre eux...
Chez les adeptes de Rust, on peut souvent se demander s’ils l’utilisent eux-mêmes vraiment correctement.
Quand même... vous aimez Rust, n’est-ce pas ?
Vous pouvez détester les fanatiques de Rust, mais s’il vous plaît, aimez Rust, s'il vous plaît...
Même s’ils se sont fait rosser avec FFmpeg, ils racontent quand même qu’il faudrait écrire tout le code en Rust, ou je ne sais quoi.
Discussion sur Hacker News
En parlant de logiciels fondamentaux, l’aspect le plus regrettable de Rust serait selon certains son ABI. Pour créer un OS en Rust et fournir des services riches, il faut que les applications puissent continuer à utiliser les bibliothèques après une mise à niveau de l’OS, sans avoir à les recompiler. Windows résout ce problème avec COM, Apple l’a fait un temps avec le dynamic dispatch d’ObjC (et aujourd’hui avec l’ABI de Swift), Android avec la JVM et le bytecode. Rust, en pratique, ne prend guère en charge autre chose que
extern "C", ce qui limite l’usage des bibliothèques dynamiques. Fournir une ABI sans couche VM (JVM, .NET) est extrêmement difficile, et comme cela impose de ne jamais modifier les détails d’implémentation une fois fixés, on comprend que la priorité soit basse. En pratique, seuls Swift et COM ont vraiment réussi avec ce modèle. Si Rust introduisait une ABI complète, il se rapprocherait d’un langage presque parfait. (Gérer les dépendances sous forme binaire réduirait aussi fortement les temps de compilation)opt-in), c’est parce qu’il recherche les zero-cost abstractions. Une ABI stable s’accompagne d’une baisse de performances, comme le montre le cas de C++ (explication sur l’ABI de C++). Pour charger dynamiquement des plugins Rust depuis Rust (dlopen), il existe des outils comme stabby et abi_stable, qui fonctionnent plutôt bien. Pour une interopérabilité plus générale entre langages, crABI (proposition crABI) pourrait devenir une alternative à l’avenir. Mais ce n’est pas un problème que Rust peut résoudre seul : il faut aussi le soutien et la coopération d’autres langages, ainsi que de plusieurs communautés comme celles des distributions Linux. Il est aussi mentionné que, comme Rust est un langage où l’on choisit explicitement les modes d’I/O et d’allocation mémoire, une architecture à la Swift où tout repose sur des bibliothèques partagées ne lui conviendrait peut-être pas.repr(wasm)/extern "wasm", mais avec wit-bindgen ou la cible wasm32-wasip2, ce n’est pas difficile à utiliser. Vidéo de présentation des Wasm Componentsextern "C". Et il semble aussi y avoir eu des propositions pour étendre l’ABIexternà davantage de typesJ’adore vraiment Rust, mais j’aimerais que quelques problèmes chroniques agaçants reçoivent davantage d’attention
opt-in), ou que les items/fichiers internes au crate soient automatiquement répartis en unités de compilation selon le graphe de dépendancesEn réfléchissant à l’expression « Smooth, iterative deepening », certains pensent que Rust accorde trop d’importance à la compatibilité cross-language, au risque d’ajouter de la complexité et de nuire à la sécurité. Dans ce cas, il vaudrait mieux aider en remplaçant les couches les plus basses du système, comme libc. Go fait très peu d’appels cross-language. Google a construit des fondations solides en développant directement ses bibliothèques essentielles, alors qu’avec Rust il existe de multiples versions des bibliothèques de base, dont beaucoup restent incomplètes
Il est souligné que « éviter les allocations, éviter de déclencher le GC » n’est pas vraiment cohérent avec les concepts modernes de GC et de JIT. Les GC modernes ont parfois une latence stop-the-world quasi nulle, et l’usage CPU global du GC dépend surtout du ratio entre la mémoire résidente et la taille du heap. Le JIT dispose de plus d’opportunités d’optimisation que l’AOT, et peut explorer plus agressivement grâce aux optimisations spéculatives. En réalité, ce qui compte le plus, ce sont la latence de démarrage/de warm-up, le surcoût mémoire et la performance moyenne plutôt que la performance du pire cas dégradé. De plus, la gestion manuelle de la mémoire n’est pas nécessairement plus efficace, et même si l’usage réel de RAM triple, l’écart de coût peut être nul. Il est aussi recommandé de regarder cette présentation de l’ISMM, qui traite très bien du sujet
Certains estiment que les commentaires et discussions signalés ont bien cerné les enjeux. Des questions comme « faisons un standard de langage avec une spécification officielle » ou « il faut plusieurs implémentations » sont importantes en pratique. En particulier, @infogulch a bien mis en avant qu’un langage doit disposer d’une spécification officielle pour devenir une base industrielle (commentaire de référence)
Les gens remettent souvent en cause l’idée même que Rust devrait avoir une spécification, ce qui montrerait à quel point le génie logiciel manque de véritable ingénierie
En réponse à un commentaire disant que Rust est « un langage utilisé seulement par des gens qui veulent avoir l’air d’être des programmeurs », quelqu’un explique qu’en tant que personne qui aime profondément programmer, Rust a été une révélation. Il ne veut absolument pas revenir à l’époque où le C++ était une souffrance extrême. Et il ne juge pas importantes ni la standardisation du langage (don de la spécification Ferrocene) ni la multiplicité des implémentations. Python et Java fonctionnent très bien en reposant largement sur une implémentation centrale. C++, à force de vouloir prendre en charge plusieurs compilateurs, n’a fait qu’empirer des problèmes complexes propres à chaque plateforme. Il ne voit pas ce que signifie concrètement le « bazar » de cargo, et trouve au contraire l’écosystème C++ bien plus pénible