Qu’implique le fait qu’Ubuntu utilise Rust ?

• L’adoption de Rust par Ubuntu montre que, dans le cycle d’adoption des technologies, Rust est en train de passer des early adopters au grand public du marché, en franchissant le gouffre
• Canonical a adopté Rust comme langage par défaut pour les nouveaux logiciels d’infrastructure, en remplacement de certains usages de C, C++ et Python, tout en investissant à la fois financièrement et en réputation dans le développement d’utilitaires sûrs en mémoire
• Comme les utilisateurs de la majorité précoce (Early Majority) veulent des « standards du secteur » et de la compatibilité avec les workflows existants, le remplacement d’utilitaires en mode drop-in est une stratégie clé pour franchir ce gouffre
• La question de l’extension de la bibliothèque standard de Rust revient sur le devant de la scène, avec une réévaluation de l’idée de « Rust Platform », rejetée en 2016, qui pourrait en réalité mieux convenir à la majorité précoce
• Une structure capable de transformer l’adoption en investissement, ainsi que la capacité d’inclusion fondée sur l’empathie de la communauté open source, sont essentielles pour la prochaine phase de croissance de Rust

---

Le « franchissement du gouffre » de Rust varie selon les domaines

• Le fait que Rust ait franchi le gouffre dans le Technology Adoption Life Cycle dépend du domaine considéré
• Chez Amazon, Rust s’est solidement imposé pour construire de vastes data planes ou des agents sensibles aux ressources, mais il reste souvent perçu comme excessif pour le développement généraliste
• Dans le domaine des Safety Critical Software, il existe des réussites, mais la plupart des acteurs du secteur restent encore en mode observation

L’importance des « clients de référence »

• La clé pour franchir le gouffre est de disposer de clients de référence (reference customers)
• Les premiers adopteurs achètent des agents du changement (change agents), tandis que la majorité précoce cherche à améliorer la productivité de l’existant en minimisant les ruptures
• Voir des organisations similaires réussir est le facteur le plus convaincant pour adopter une nouvelle technologie
• Le succès de Rust au sein de l’équipe S3 est convaincant pour les grandes équipes de services, mais beaucoup moins directement pour les équipes qui développent des services CRUD

La stratégie d’adoption de Rust par Ubuntu (Canonical)

• Lors de Rust Nation, le VP of Engineering de Canonical, Jon Seager, a présenté une keynote intitulée « Rust Adoption At Scale with Ubuntu »
• Canonical limitait jusqu’ici ses langages de développement internes à Python, C/C++ et Go, mais y a récemment ajouté Rust comme langage par défaut pour les nouveaux travaux d’infrastructure
• À l’image de la keynote de Lars Bergstrom sur l’adoption de Rust chez Google, l’approche combine vision et pragmatisme
  • C’est précisément le type de caractéristiques nécessaires pour passer des premiers adopteurs à la majorité précoce

Investir dans des utilitaires sûrs en mémoire

• Jon Seager a indiqué qu’Ubuntu devait soutenir la création d’utilitaires fondés sur la sûreté mémoire dans une logique de « pay it forward »
• Canonical finance actuellement le développement de sudo-rs et ntpd-rs au sein de la Trifecta Tech Foundation, ainsi que le travail de uutils sur coreutils
• L’idée est qu’Ubuntu essaie et valide d’abord ces nouveautés, afin que d’autres distributions puissent ensuite en bénéficier
• Les utilitaires drop-in qui s’intègrent tels quels dans les workflows existants répondent au besoin de la majorité précoce de minimiser les discontinuités

Les attentes des nouveaux adopteurs : étendre la bibliothèque standard

• Lors d’un dîner, Jon Seager a déclaré qu’il fallait réexaminer la politique de petite bibliothèque standard de Rust
• C’est une demande récurrente depuis des années ; il ne s’agit pas simplement de fournir une grande bibliothèque standard, mais d’envisager une alternative sous forme de projet appelée « Battery Packs »
• La Rust Platform proposée en 2016 — l’idée de reconnaître certaines crates comme une bibliothèque standard étendue — avait été rejetée par les premiers adopteurs à l’époque, mais pourrait en réalité convenir à la majorité précoce
  • À l’époque, l’opinion dominante était qu’ajouter des dépendances dans Cargo.toml suffisait

La nécessité de changer pour continuer à croître

• Pour passer des premiers adopteurs à la majorité précoce, le message doit être celui d’un « standard du secteur » et non d’un produit « state-of-the-art »
• Rust a réussi à gagner en reconnaissance dans l’industrie ; désormais, il doit devenir le meilleur choix non pas en fonction de « ce qu’il pourrait être », mais de « ce qu’il est réellement »
  • Ces deux dimensions peuvent parfois entrer en tension
• Pour parler aux pragmatiques, il faut de la patience, une compréhension des enjeux du secteur concerné et une présence dans les conférences de l’industrie

Une structure qui transforme l’adoption en investissement

• L’élargissement de l’adoption de Rust entraîne une hausse de la demande envers le projet Rust et son écosystème
• Pour des organisations open source comme Canonical, les relations inter-organisations et les contributions comptent davantage que les $$
  • Les développeurs de Rust for Linux ont d’abord été aidés par les maintainers de Rust, puis ils ont progressivement commencé à corriger eux-mêmes les bugs, tandis que les maintainers évoluaient vers un rôle de mentor
• Fait intéressant, les financements proviennent souvent davantage d’entreprises qui envisagent d’adopter Rust que de celles qui l’ont déjà adopté
  • Des premiers adopteurs en interne poussent l’adoption dans leur organisation et allouent des budgets au développement de fonctionnalités « table stakes »
• D’après Alexandru Radovici, du Rust Foundation Silver Member Directory, de nombreuses entreprises de logiciels critiques pour la sécurité disposent de financements pour combler les lacunes de Rust, mais ne savent pas comment les utiliser

Le rôle de l’open source et l’importance de l’empathie

• L’open source est une excellente plateforme pour franchir le gouffre, mais les cliques et les « traditions orales » peuvent devenir des barrières à l’entrée
• Une idée peut être rejetée à cause d’un mauvais terme employé, ou une seule réponse impolie peut suffire à faire partir un nouveau contributeur
• Ce dont Rust a le plus besoin pour sa prochaine phase de croissance, c’est d’empathie dans l’open source
• L’essentiel est d’aller là où Rust peut aider les gens, puis de les soutenir et leur donner les moyens d’agir

[GN⁺]

Avis sur Hacker News

• Le fait qu’Ubuntu utilise un userland sous licence non GPL signifie qu’on pourrait autoriser davantage de TiVoization dans l’écosystème Linux
  Combiné à la direction prise par Amutable du camp systemd, cela pourrait faire émerger des distributions Linux fermées que les utilisateurs ne pourraient pas modifier
  Du point de vue des entreprises, un environnement fermé avec vérification complète des signatures peut être attractif. Imaginer un monde où même ls ou cd deviennent closed source a quelque chose d’étrangement apocalyptique

  • util-linux et BSD ne vont pas disparaître. Si Ubuntu ne vous plaît pas, il suffit de ne pas l’utiliser. Debian était bien plus stable
  • Il y a une raison pour laquelle on parlait de GNU/Linux. Android/Linux n’a pas non plus de userland GPL, et la plupart des concurrents dans l’embarqué ne sont pas GPL non plus. Au final, Linux n’est qu’un noyau
  • Historiquement, je suis peut-être naïf, mais je ne pense pas que ce type de changement soit forcément mauvais. Je préfère les utilitaires open source, mais je trouve acceptable qu’il existe aussi des alternatives fermées respectant les spécifications. Les entreprises pourraient ainsi injecter davantage de financement dans les projets open source
  • Honnêtement, Ubuntu ressemble à l’Apple de Linux : plus fort en marketing qu’en qualité. On utilise la famille Debian surtout parce que son coût de maintenance est faible, et personnellement je pense que Fedora ou OpenSUSE représentent l’avenir
  • Si ce changement conduit 95 % des utilisateurs Linux à utiliser le même OS, ce ne sera peut-être pas une si mauvaise chose

• Le vrai gouffre (chasm) que Rust doit franchir, c’est la prise en charge du lien dynamique avec une ABI sûre
  Il faut pouvoir modifier une bibliothèque tout en garantissant la sûreté, et obtenir une stabilité d’ABI au niveau du C pour permettre l’adoption de Rust dans le monde C/C++

  • Rust peut déjà communiquer via l’ABI C. Il offre des capacités de lien dynamique au même niveau que C++
  • La stabilité d’ABI en C++ est l’un des principaux freins à l’évolution du langage. On ne peut pas modifier le layout des classes de la STL, et les templates implémentés dans les headers sont difficiles à optimiser plus tard. Rust ne devrait pas prendre en charge une “stable ABI”
  • L’efficacité de Rust repose sur la monomorphisation à la compilation. Pour construire une ABI, il faut envisager la spécialisation au moment de l’édition de liens. Ce n’est pas juste déplacer la génération de code vers le linker : il faut traiter avec soin la “forme (shape)” des paramètres de fonction
  • Le lien dynamique aide aussi à réduire le temps de compilation en build de debug. Les bibliothèques inchangées n’ont pas besoin d’être recompilées, et le surcoût à l’exécution est minime
  • Il est regrettable que la communauté Rust préfère souvent la licence MIT à la GPL. La GPL est favorable aux utilisateurs, la MIT est favorable aux entreprises. J’ai l’impression que le mouvement “Rewrite-it-in-Rust” se concentre davantage sur la diffusion du langage que sur la protection des utilisateurs

• Plus que l’adoption de Rust par Ubuntu, le vrai problème est qu’ils continuent à gérer des builds importants avec des scripts curl|bash
  C’est évident quand on regarde le snapcraft.yaml de firefox-snap

  • Quand on parle de curl|bash, on pense généralement à des modifications de configuration aléatoires ou à des changements dans .bashrc, mais ici il s’agit simplement d’exécuter un script d’installation d’une toolchain statique. C’est très années 90, mais relativement sûr
  • Beaucoup de distributions embarquent une version de Rust beaucoup trop ancienne. Le Rust de Debian ou d’Ubuntu LTS est complètement dépassé, d’où sans doute leur aversion pour le lien statique
  • Même si on exécute quelque chose via curl, une bonne vérification de hash suffit à rendre ça acceptable

• Le fait que le projet Rust Coreutils soit sous licence MIT me dérange
  Même si la philosophie de la FSF est parfois critiquée, la GPL protège l’open source. Si Canonical bascule tout Ubuntu vers MIT, difficile de savoir ce qui pourrait arriver

  • La GPL était autrefois puissante, mais aujourd’hui, avec les systèmes automatisés de blanchiment de copyright, beaucoup de code finit converti en MIT/BSD ou en code propriétaire. La FSF n’a pas non plus de solution
  • Les débats sur les licences sont sans fin. La GPL limite l’adoption, tandis que MIT est plus flexible. Au fond, tout dépend de l’objectif recherché — veut-on un OSS utilisable par tous, ou empêcher les entreprises d’en tirer profit sans contribuer
  • Je me demande concrètement quel type de “mauvaise action” deviendrait possible si Coreutils passait sous MIT

• À cause de rust-coreutils, il était impossible d’installer CUDA Toolkit. L’incident est documenté sur le forum NVIDIA

  • Le fil lié semble plutôt indiquer un problème lié à gzip. Ce n’était apparemment pas à cause de dd
  • Franchement, rust-coreutils n’a pas de raison d’exister. Après une installation d’Ubuntu, la première chose à faire est de réinstaller les vrais coreutils et sudo

• Le concept de “Crossing the chasm” est intéressant. Au-delà du cas des coreutils dans Ubuntu, Rust a beaucoup d’autres gouffres à franchir
  Il y a Rust for Linux ou Rust dans l’automobile, mais cela semble encore se limiter surtout au niveau des drivers

  • Rust s’étend dans plusieurs directions. pyo3 (remplacement de modules Python), Dioxus (framework web proche de React), Ferrocine (compilateur pour l’automobile) en sont de bons exemples. Le projet DARPA TRACTOR accélère aussi l’adoption de Rust
  • Le document Project Goals de Rust (lien) permet de voir où la communauté choisit d’investir ses efforts
  • Rust lui-même est excellent, mais une partie de la communauté pose problème en se contentant de réécrire en Rust des logiciels stables existants tout en récupérant la marque. Ubuntu semble tomber lui aussi dans cette forme de virtue signaling

• L’idée qu’on pourra changer la bibliothèque standard plus tard est dangereuse. Les utilisateurs veulent des systèmes stables et de qualité, plus que des “gouffres” à franchir

  • Dans le cas de Rust, il est moins question de “remplacer” la stdlib que d’y ajouter des éléments, ce qui est facile. Une nouvelle release sort toutes les 6 semaines, avec à chaque fois plus de 10 fonctionnalités ajoutées. Il y a déjà plusieurs centaines de fonctionnalités dans la stdlib

• L’immaturité de l’écosystème Rust freine son adoption. Beaucoup de crates sont encore en version pré-1.0 ou ne sont guère plus que de simples wrappers C. Pour la crypto ça va, mais pour des choses comme SAML, c’est difficile à trouver

  • Il ne faut pas trop s’inquiéter des versions pré-1.0. La culture Rust respecte très strictement la SemVer, donc beaucoup retardent la déclaration en 1.0. Des crates profondément liées à l’API, comme libc, ont aussi du mal à changer de version. Personnellement, je me réfère à des listes curatoriales comme blessed.rs
  • gettext n’est devenu 1.0 qu’au bout de 30 ans
  • Le module cryptography de Python exigeait une toolchain Rust, ce qui rendait l’installation impossible dans un environnement Termux. C’est pénible de voir des projets Python devenir plus lourds à cause de dépendances Rust

• Il existe un mouvement qui consiste à “traduire à l’intuition” du code C++ en Rust pour changer de licence. Par exemple, sudo-rs a en réalité un bilan de sécurité pire que la version C

  • Il y a beaucoup trop de propagande autour de Rust, de l’IA et de la sûreté. J’ai adoré Rust au début, mais les polémiques autour de la licence MIT et la promotion excessive finissent par devenir fatigantes

• L’immense bibliothèque standard de .NET est vraiment agréable. On peut faire la plupart des tâches de manière standard, et si une implémentation étrange apparaît, la majorité pousse à la standardisation

  • Je pense que la petite stdlib de Rust est une erreur. La stdlib est la seule dépendance toujours présente, donc même si elle n’est pas parfaite, elle devrait inclure davantage d’outils
  • Mais du point de vue d’un programmeur système, une grosse stdlib pose au contraire problème. .NET repose sur un GC, donc ce n’est pas gênant, mais Rust et C++ doivent aussi fonctionner en environnement bare metal. Une stdlib volumineuse devient lourde dans des contextes contraints en mémoire (<64K)
    Les modules std/core de Rust sont déjà trop gros, au point qu’il faut des astuces comme les weak symbols sur microcontrôleur.
    Une petite stdlib facilite la stabilité de l’API et réduit la charge de maintenance. C++ a beaucoup souffert de ce problème, donc Rust doit rester prudent