Git annonce l’adoption de Rust et son caractère obligatoire dans le système de build

 (lore.kernel.org)
15 points par GN⁺ 2025-09-21 | 1 commentaires | Partager sur WhatsApp
  • Le projet Git a officiellement annoncé qu’il allait introduire Rust dans son cœur, et qu’à partir de Git 3.0, Rust deviendrait une exigence obligatoire pour la build
  • Cette série de patchs est menée comme un test ballon comparable à l’introduction passée de fonctionnalités C99, avec pour objectif de mettre progressivement en place l’infrastructure nécessaire à l’adoption de Rust
  • Comme première étape, le module varint.c, avec très peu de dépendances, a été converti en Rust afin de valider l’interopérabilité C-Rust et les outils de build
  • Pour l’instant, seule la build avec Meson est prise en charge ; par la suite, le projet prévoit d’ajouter la prise en charge du Makefile ainsi que, dans la CI, la validation des builds Rust et des contrôles de cohérence de formatage basés sur cargo format
  • Il s’agit d’un changement important qui laisse à la communauté Git et aux distributeurs le temps de s’adapter aux nouvelles exigences de la toolchain Rust, tout en améliorant à long terme la sûreté du code et sa capacité d’évolution

Contexte de l’introduction de Rust

  • Git étudie depuis longtemps une évolution du langage utilisé afin d’améliorer sa stabilité et sa maintenabilité
  • L’introduction de Rust signifie un renforcement de la sûreté mémoire, l’usage d’une toolchain moderne et la possibilité d’optimisations de performance
  • Elle vise aussi à construire une base de code plus robuste grâce à l’adoption d’un langage moderne
  • En annonçant à l’avance que Rust deviendra indispensable au moment de la sortie de Git 3.0, le projet veut laisser à l’écosystème le temps de se préparer
  • Le périmètre du code Rust sera élargi progressivement, avec à terme l’objectif de réimplémenter en Rust certaines fonctionnalités clés

Série de patchs expérimentale

  • Le projet a choisi varint.c comme premier module porté vers Rust
    • il est très simple et sans dépendances
    • il permet de vérifier l’interop C ↔ Rust
    • il permet de mener l’expérience sans impact sur l’ensemble des fonctionnalités de Git
  • Tous les tests passent avec la version varint.rs

Changements dans le système de build

  • Pour l’instant, la prise en charge de Rust n’a été ajoutée que dans le système de build Meson
  • Le projet prévoit ensuite d’ajouter la prise en charge de Rust dans le Makefile
  • Des travaux sont également nécessaires côté CI
    • validation de la build Rust et de son bon fonctionnement
    • garantie de la cohérence du style de code via cargo format
    • autres automatisations liées au tooling et à la maintenance

Suite du plan

  • Ce travail se concentre davantage sur l’expérimentation du processus d’adoption que sur les fonctionnalités Rust elles-mêmes
  • Par la suite, davantage de composants internes de Git, y compris le module xdiff, pourraient être réécrits en Rust
  • Le projet prévoit d’étendre progressivement l’usage de Rust afin d’amener l’ensemble de l’écosystème à s’adapter à un environnement de build fondé sur Rust

Points à retenir

  • Git se prépare à l’une des transitions de langage les plus importantes de son histoire
  • Le caractère obligatoire de Rust peut apporter sûreté, maintenabilité et potentiel d’évolution à long terme
  • Pour les distributeurs et les développeurs, la mise en place d’un environnement de développement Rust deviendra incontournable dans l’écosystème Git

À lire aussi

1 commentaires

 
GN⁺ 2025-09-21
Avis Hacker News
  • Dans une autre discussion sur l’idée de rendre Rust obligatoire, l’auteur estime qu’il vaudrait mieux l’introduire d’abord comme dépendance optionnelle, puis ne le rendre obligatoire que plus tard, une fois le support de Rust ajouté à gcc
    Lien vers la discussion connexe
    • Il souligne le manque de cohérence du compilateur gcc ; par exemple, gcj (gcc pour Java) n’est presque utilisé par personne
      Comme le support de Rust concerne aussi un langage sans standard formel, il soupçonne qu’avec le temps l’implémentation prendra beaucoup de retard (comme ce fut le cas pour Java autrefois)
  • Il se demande pourquoi on cherche à introduire Rust dans Git
    Git semble déjà être un outil très abouti, qui n’aurait besoin que de maintenance ou d’améliorations, sans nécessiter assez de nouveau code massif pour justifier l’introduction d’un nouveau langage
    Contrairement à Linux, qui a continuellement besoin de nouveaux pilotes, il ne voit pas de raison équivalente pour Git
    Il aimerait que quelqu’un lui explique ce qu’il lui manque
    • Git continue à gagner des fonctionnalités, même si ce n’est pas très visible
      On peut consulter les changements de Git dans les RelNotes, ou de façon plus lisible dans la catégorie Git du blog GitHub
    • Si l’on essaie des outils comme jj ou git-branchless, on change d’avis sur l’idée que git serait « terminé »
      Par exemple, git-branchless propose des fonctions comme les fusions en mémoire, écrites en Rust
    • Il y a de nombreuses réponses utiles dans ce message
      Pour ce qui concerne Rust, on peut aussi chercher davantage sur cette mailing list
      (Il précise qu’il ne porte pas lui-même de jugement pour ou contre, et que quelqu’un d’autre le fera sans doute)
    • Les anciens projets C attirent de moins en moins de développeurs
      Presque personne ne veut développer Git en C, alors que des développeurs intéressés par une réécriture en Rust sont très motivés pour rejoindre le projet
    • Le C n’est pas sûr
  • Il se demande pourquoi on cherche sans cesse à introduire Rust partout
    Git est très abouti et n’ajoutera probablement pas tant de nouveau code que cela
    Rust est bien plus complexe que le C
    Si l’on a vraiment besoin de fonctionnalités orientées objet, utiliser simplement du C++98 serait bien plus simple et plus facile à comprendre que le C++ récent ou Rust
  • Il estime que le titre est quelque peu trompeur
    Rust ne sera pas obligatoire pour les futurs patchs, mais devrait le devenir dans le système de build
    • Un intervenant le remercie et dit avoir reflété cela dans le titre
      Si c’est incorrect, il pourra encore le modifier
    • Une autre question demande ce que cela signifie exactement
      Est-ce nécessaire pour construire le système de build lui-même, ou aussi obligatoire pour construire l’application ?
  • Une personne, en admettant qu’elle vieillit et doit accepter le changement, se plaint que jusque-là il suffisait de connaître le C pour contribuer à Git ou au noyau, alors qu’il faut désormais aussi connaître Rust, et que la complexification progressive de la toolchain augmente la barrière à l’entrée
    Elle a beaucoup investi dans Git et construit plusieurs projets autour de lui, et ne veut pas perdre sa capacité à le hacker
    • Il pense qu’une attitude réticente à apprendre du nouveau n’est pas adaptée à ce secteur
      En pratique, Rust est plus facile à apprendre que le C moyen (surtout le C bogué), et certainement plus facile que d’assimiler le code source de Git ou de Linux
    • Même si l’on a construit soi-même un client Git et un serveur web, cela n’affectera pas la capacité à hacker Git, puisque le format des dépôts Git ne change pas
    • À noter que Git utilise déjà plusieurs langages
      D’après GitHub : C 50 %, Shell 38 %, Perl 4 %, et le reste en TCL/Python, etc.
      Perl/TCL sont même plus atypiques encore
      Le projet a grossi avec beaucoup de code bricolé ajouté un peu partout, et il est désormais temps d’améliorer la sécurité et les performances, ainsi que de nettoyer cet ancien code de fortune
      Rust semble bien adapté à cela
    • Il précise qu’en tant qu’ingénieur logiciel, il est normal de savoir manipuler plusieurs langages, donc l’ajout d’un langage n’est pas un gros problème
    • Beaucoup de jeunes développeurs, lui compris, préfèrent Rust et n’ont pas envie d’apprendre le C
      Le fait que Git utilise un peu de Rust ne devrait pas gêner le développement de clients ou serveurs Git écrits par soi-même
  • Quelqu’un demande des explications supplémentaires sur l’idée que l’introduction de Rust est impossible sur certaines plateformes et difficile sur d’autres
    • Sur les systèmes Linux, toute bibliothèque doit être utilisée comme bibliothèque système, mais Rust n’a pas d’ABI stable, donc il ne peut pas être utilisé comme véritable bibliothèque partagée
      Les notes de version de Debian mentionnent aussi les problèmes liés aux paquets Rust/Go
      Lors de la compilation des paquets Rust, les problèmes de liens statiques imposent souvent des reconstructions fréquentes, ce qui est peu pratique en usage réel
      Si Rust continue d’ignorer la question de l’ABI stable et des bibliothèques partagées, pourtant indispensables sur Linux, cela risque de susciter encore plus de plaintes que le C
      Il pense qu’il faut être plus prudent sur les grandes architectures logicielles
    • Sur certaines plateformes propriétaires peu visibles, un compilateur C maison est pris en charge, mais pas LLVM
      On peut chercher le mot-clé NonStop dans cet article pour voir un exemple
    • C’est parce que le compilateur Rust ne prend pas en charge certaines plateformes (combinaisons OS/architecture)
      Dans le RESF et ailleurs, on dit parfois que « la plateforme ne supporte pas Rust », mais en réalité il faut que le compilateur Rust la prenne en charge pour que cela fonctionne vraiment
    • Rust repose sur LLVM et couvre donc moins de plateformes que GCC
    • Il recommande de consulter la section « Tier 3 » de la liste de support des plateformes dans la documentation officielle de Rust
  • Quelqu’un se demande quels changements arriveront avec git 3.0
    git semble stabilisé en 2.x, donc il ne voit pas pourquoi casser la compatibilité
  • Autrefois, dans les environnements de cross-compilation, on partait du principe que la compilation, l’exécution et l’édition du code se faisaient dans des contextes différents
    Il se demande si la culture de développement récente ne s’est pas éloignée de cette maîtrise des toolchains
    Le contrôle de source, le build et l’environnement d’exécution étaient distincts, nécessitaient des copies distantes ou de l’exécution à distance, et les règles de build devaient obligatoirement détecter la plateforme cible
    • Au contraire, il trouve que la toolchain Rust rend la cross-compilation plus facile que n’importe quel autre langage compilé
      Avec un seul flag --target, on peut compiler pour une centaine de plateformes sans problème particulier
      Le vrai souci viendrait plutôt du fait qu’une partie des développeurs de Git tiennent à leurs anciennes machines de développement figées
    • Il pense que la plupart des développeurs n’ont tout simplement jamais vraiment appris la cross-compilation
      Elle a toujours été traitée comme un citoyen de seconde zone, et dans les projets externes il ne s’attend même pas à ce qu’elle fonctionne correctement
      Certaines distributions Linux imposent même de compiler sur le vrai matériel, comme pour le Raspberry Pi
      C’est pourquoi personne ne fait vraiment l’effort de bien la prendre en charge
    • Indépendamment de Rust, l’état actuel de la cross-compilation est selon lui proche de la « catastrophe »
      Linux est particulièrement mauvais sur ce point, car l’architecture de glibc a vieilli au point de rendre difficile le ciblage du plus petit dénominateur commun glibc sur n’importe quel matériel
      La plupart des projets n’essaient même pas de prendre en charge la cross-compilation
      Zig essaie d’améliorer la situation
  • Il soutient qu’il vaudrait mieux repousser l’introduction jusqu’à ce que le frontend Rust lié à gcc soit suffisamment mature
    Git étant un outil central, le risque des changements est élevé, et en faire une dépendance obligatoire en à peine six mois lui paraît dangereux
  • Rust présente, selon lui, une forte courbe d’apprentissage et une grande complexité, un peu comme les langages fonctionnels
    Cette complexité sert à attraper plus d’erreurs à la compilation, mais rend en contrepartie le langage lui-même assez complexe
    Il ne recommande donc pas son adoption
    Il croit savoir que le noyau a lui aussi refusé Rust
    Ajouter à un noyau déjà complexe un système de types digne de Haskell et un système de macros de niveau Lisp ne ferait qu’augmenter la complexité
    Il est difficile de suivre du code Rust qui utilise serde
    À l’inverse, le Unmarshal de Go est bien plus facile à suivre
    • À l’inverse, il trouve les langages fonctionnels et Rust plus explicites que le C ou Go
      Parce qu’ils permettent de faire porter davantage d’informations au compilateur
      Il n’a jamais eu de gros problèmes avec Serde ; en revanche, il a plus souvent dû déboguer le Unmarshal de Go
      Quant à l’affirmation selon laquelle le noyau aurait refusé Rust, il s’agissait en réalité d’un conflit entre deux développeurs à propos de l’emplacement de stockage des headers
    • Le C est simple, mais écrire du C à la fois sûr et performant est extrêmement complexe
      Rust a une barrière à l’entrée plus élevée que le C, mais l’écart entre du « Rust minimal » et du « Rust rapide et sûr » est bien plus faible qu’en C
    • Il est souligné que, même si l’on dit Rust complexe, le C l’est lui aussi loin d’être peu complexe
    • C’est précisément cette commodité des vérifications à la compilation qui fait la différence de Rust
      Cela est jugé aussi important que le borrow checker
    • Pour quelqu’un qui a de l’expérience avec TypeScript et qui a appris via les linters à gérer les références, le déballage de Result et la gestion des erreurs, Rust est finalement assez facile à apprendre
      Sa syntaxe est aussi permissive
      Le noyau Linux n’a d’ailleurs pas réellement refusé Rust