Git kündigt Einführung von Rust und verpflichtende Nutzung im Build-System an

 (lore.kernel.org)
15 Punkte von GN⁺ 2025-09-21 | 1 Kommentare | Auf WhatsApp teilen
  • Das Git-Projekt hat offiziell angekündigt, künftig Rust im Core einzuführen, und dass Rust ab Git 3.0 zu einer verpflichtenden Voraussetzung für den Build wird
  • Diese Patch-Serie wird ähnlich wie die frühere Einführung von C99-Funktionen als experimentelle Einführung (test balloon) vorangetrieben und soll schrittweise die Infrastruktur für die Rust-Einführung schaffen
  • Als ersten Schritt wird das nahezu abhängigkeitfreie Modul varint.c nach Rust konvertiert, um die C-Rust-Interoperabilität und das Build-Tooling zu prüfen
  • Derzeit wird nur der Meson-Build unterstützt; künftig sollen Makefile-Unterstützung sowie in der CI Rust-Build-Validierung und Konsistenzprüfungen des Formatierungsstils auf Basis von cargo format ergänzt werden
  • Dies ist eine wichtige Veränderung, die der Git-Community und Distributoren Zeit zur Anpassung an neue Anforderungen an die Rust-Toolchain geben und langfristig die Code-Sicherheit und Erweiterbarkeit erhöhen soll

Hintergrund der Rust-Einführung

  • Git hat im Interesse von Stabilität und Wartbarkeit eine sprachliche Weiterentwicklung geprüft
  • Die Einführung von Rust bedeutet mehr Speichersicherheit, die Nutzung moderner Toolchains und die Sicherung von Potenzial für Performance-Optimierung
  • Zugleich soll durch die Einführung einer modernen Sprache eine robustere Codebasis aufgebaut werden
  • Mit der frühzeitigen Ankündigung, dass Rust zum Zeitpunkt des Git-3.0-Releases zwingend erforderlich sein wird, soll dem Ökosystem Vorbereitungszeit verschafft werden
  • Der Umfang des Rust-Codes soll schrittweise erweitert werden; langfristig ist geplant, auch einige Kernfunktionen in Rust neu zu implementieren

Experimentelle Patch-Serie

  • Als erstes Modul für Rust wurde varint.c ausgewählt
    • Sehr einfach und ohne Abhängigkeiten
    • Eignet sich zur Prüfung der C ↔ Rust-Interoperabilität
    • Kann ohne Auswirkungen auf die Gesamtfunktionalität von Git experimentell getestet werden
  • Alle Tests wurden mit der Version varint.rs erfolgreich bestanden

Änderungen am Build-System

  • Derzeit wird Rust-Unterstützung nur im Meson-Build-System ergänzt
  • Künftig soll auch das Makefile Rust unterstützen
  • Auch bei der CI sind Vorbereitungen nötig
    • Validierung von Rust-Build und Funktion
    • Sicherstellung eines konsistenten Code-Stils mit cargo format
    • Weitere Automatisierung für Tooling und Wartung

Weitere Pläne

  • Bei dieser Arbeit liegt der Fokus weniger auf Rust-Funktionen selbst als auf dem Experiment mit dem Einführungsprozess
  • Danach könnten weitere interne Git-Funktionen, darunter das xdiff-Modul, in Rust neu geschrieben werden
  • Durch die schrittweise Ausweitung von Rust soll das gesamte Ökosystem an eine Rust-basierte Build-Umgebung herangeführt werden

Implikationen

  • Git bereitet einen der wichtigsten Sprachwechsel seiner Geschichte vor
  • Durch die verpflichtende Nutzung von Rust können Sicherheit, Wartbarkeit und langfristige Weiterentwicklungsmöglichkeiten gestärkt werden
  • Distributoren und Entwickler werden künftig im Git-Ökosystem verpflichtend eine Rust-Entwicklungsumgebung aufbauen müssen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-09-21
Hacker-News-Kommentare
  • In einem anderen Thread zur Diskussion, Rust verpflichtend einzuführen, meint der Verfasser, es sei besser, Rust zunächst als optionale Abhängigkeit einzuführen und es erst dann verpflichtend zu machen, wenn Unterstützung für Rust in gcc hinzugefügt wurde.
    Link zur entsprechenden Diskussion
    • Es wird betont, dass der gcc-Compiler inkonsistent sei; zum Beispiel nutze fast niemand gcj (gcc für Java).
      Da Rust-Unterstützung zudem eine Sprache ohne Standard betreffe, bestehe der Verdacht, dass Implementierungen mit der Zeit stark hinterherhinken könnten, wie früher bei Java.
  • Es wird gefragt, warum Git überhaupt Rust einführen wolle.
    Git wirke bereits wie ein ausgereiftes Werkzeug, das eher Wartung und kleinere Verbesserungen brauche; es scheine keinen Bedarf an umfangreichem neuen Code zu geben, der die Einführung einer neuen Sprache rechtfertigen würde.
    Anders als bei Linux, wo ständig neue Treiber nötig seien, sei bei Git kein vergleichbarer Grund erkennbar.
    Der Kommentator bittet darum, zu erklären, ob ihm etwas entgehe.
    • Bei Git werden fortlaufend neue Funktionen ergänzt, auch wenn das nicht auffällig ist.
      Änderungen an Git lassen sich in den RelNotes nachsehen oder etwas übersichtlicher im Git-Kategorie-Bereich des GitHub-Blogs.
    • Wer Tools wie jj oder git-branchless ausprobiert, denkt vielleicht anders darüber, ob Git schon „fertig“ ist.
      git-branchless enthält etwa Funktionen wie In-Memory-Merges, die in Rust geschrieben sind.
    • In diesem Beitrag gibt es mehrere Antworten, die als Referenz nützlich sein könnten.
      Weitere Rust-bezogene Inhalte lassen sich in der betreffenden Mailingliste finden.
      (Es wird nicht direkt bewertet; vielmehr heißt es, dass das sicher jemand anders tun werde.)
    • Bei alten C-Projekten nimmt der Zustrom an Entwicklern allmählich ab.
      Kaum jemand möchte Git in C entwickeln, während Entwickler, die an einer Neuschreibung in Rust interessiert sind, mit großem Interesse dazukommen.
    • C ist unsicher.
  • Es wird infrage gestellt, warum Rust weiterhin an so vielen Stellen eingeführt werden soll.
    Git sei ausgereift und werde vermutlich auch künftig nicht viel neuen Code hinzufügen.
    Rust sei im Vergleich zu C deutlich komplexer.
    Wenn man wirklich objektorientierte Funktionen brauche, wäre selbst nur C++98 immer noch viel einfacher und verständlicher als modernes C++ oder Rust.
  • Der Titel sei etwas irreführend formuliert.
    Rust werde nicht für künftige Patches verpflichtend, sondern solle innerhalb des Build-Systems verpflichtend werden.
    • Jemand bedankt sich dafür und sagt, der Titel sei entsprechend angepasst worden.
      Falls das falsch sei, könne er erneut korrigiert werden.
    • Danach folgt die Rückfrage, was das genau bedeute.
      Unklar sei, ob es nötig sei, um das Build-System selbst zu bauen, oder ob es auch für das Bauen der Anwendung verpflichtend sei.
  • Ein älterer Kommentator meint, er müsse Veränderungen wohl akzeptieren, beklagt aber, dass man früher nur C kennen musste, um an Git oder der Kernel-Entwicklung mitzuwirken, während man nun zusätzlich Rust lernen müsse und die Toolchain immer komplexer werde, was die Einstiegshürde erhöhe.
    Er habe stark in Git investiert und mehrere Projekte darauf aufgebaut und wolle die Hackbarkeit von Git nicht verlieren.
    • Die Haltung, nichts Neues lernen zu wollen, sei in dieser Branche ungeeignet.
      Tatsächlich sei Rust leichter zu lernen als typisches C (vor allem fehleranfälliges C) und auf jeden Fall einfacher als sich in den Git- oder Linux-Quellcode einzuarbeiten.
    • Selbst wenn man einen Git-Client und einen Webserver selbst gebaut habe, ändere sich das Git-Repository-Format nicht, sodass die Hackbarkeit nicht beeinträchtigt werde.
    • Git besteht übrigens schon jetzt aus mehreren Sprachen.
      Laut GitHub sind es 50 % C, 38 % Shell, 4 % Perl und der Rest TCL/Python usw.
      Perl/TCL seien eher die ungewöhnlicheren Ausnahmen.
      Das Projekt sei mit vielen hier und da angeflanschten Hack-Lösungen gewachsen, und nun sei es an der Zeit, Sicherheit und Performance zu verbessern und alten Hack-Code aufzuräumen.
      Rust erscheine dafür geeignet.
    • Als Softwareingenieur könne man in der Regel problemlos mehrere Sprachen beherrschen; eine zusätzliche Sprache sei daher kein großes Problem.
    • Viele jüngere Entwickler, mich eingeschlossen, bevorzugen Rust und wollen C nicht lernen.
      Dass Git teilweise Rust nutzt, werde die Entwicklung eines selbstgebauten Git-Clients oder Servers wohl nicht behindern.
  • Zu der Aussage, dass die Einführung von Rust auf einigen Plattformen unmöglich und auf anderen schwierig sei, wird um nähere Erläuterung gebeten.
    • Auf Linux-Systemen müsse jede Bibliothek als Systembibliothek nutzbar sein, aber Rust habe keine stabile ABI und könne daher nicht als echte Shared Library verwendet werden.
      Auch die Debian-Release-Notes nennen Probleme rund um Rust-/Go-Pakete.
      Beim Bauen von Rust-Paketen müsse wegen statischer Link-Probleme oft neu gebaut werden, was im praktischen Einsatz unkomfortabel sei.
      Wenn die Rust-Seite das Thema stabile ABI/Shared Libraries ignoriert, das für Linux-OS zwingend wichtig ist, könnte das sogar mehr Beschwerden hervorrufen als C.
      Bei großer Softwarearchitektur müsse man vorsichtiger sein.
    • Auf wenig sichtbaren proprietären Plattformen gibt es eigenen C-Compiler-Support, aber keine Möglichkeit für LLVM-Support.
      Wer im diesem Artikel nach dem Stichwort NonStop sucht, findet ein Beispiel.
    • Der Grund sei, dass der Rust-Compiler bestimmte Plattformen (OS/Architektur-Kombinationen) nicht unterstützt.
      In RESF und ähnlichen Kreisen heiße es oft „die Plattform unterstützt Rust nicht“, aber in Wirklichkeit müsse der Rust-Compiler diese Plattform unterstützen, damit es tatsächlich funktioniert.
    • Da Rust auf LLVM basiert, ist es stärker eingeschränkt als die von GCC unterstützten Plattformen.
    • Es wird auf den Abschnitt „Tier 3“ in der offiziellen Liste unterstützter Plattformen von Rust verwiesen.
  • Es wird gefragt, welche Änderungen es in git 3.0 geben werde.
    git wirke mit 2.x bereits stabilisiert, sodass es keinen Grund zu geben scheine, die Kompatibilität zu brechen.
    • Als Antwort wird auf das Dokument git 3.0 Breaking Changes verwiesen.
    • Die Standard-Hashfunktion soll auf SHA-256 umgestellt werden.
  • Früher habe man es in Cross-Compile-Umgebungen als Grundvoraussetzung angesehen, dass Build, Ausführung und Codebearbeitung auf verschiedenen Systemen stattfinden.
    Es wird infrage gestellt, ob sich die aktuelle Entwicklungskultur nicht von dieser Art des Toolchain-Einsatzes entfernt habe.
    Quellcodeverwaltung, Build- und Laufzeitumgebung seien verschieden gewesen, weshalb Remote-Kopien oder Remote-Ausführung nötig gewesen seien, und in Build-Regeln sei die Erkennung der Zielplattform unverzichtbar gewesen.
    • Im Gegenteil: Die Rust-Toolchain wirke so, als mache sie Cross-Compiling einfacher als jede andere kompilierte Sprache.
      Mit nur einem --target-Flag lasse sich für rund 100 Plattformen ohne besondere Probleme bauen.
      Das eigentliche Problem sei wohl, dass einige Git-Entwickler an ihren jeweils alten/fixierten Entwicklungsmaschinen festhielten.
    • Die meisten Entwickler hätten Cross-Compiling in Wirklichkeit nie richtig gelernt.
      Cross-Compiling sei immer ein Bürger zweiter Klasse, und bei externen Projekten erwarte man oft gar nicht erst, dass es sauber funktioniere.
      Manche Linux-Distributionen würden etwa für Raspberry Pi nur Builds auf echter Hardware zulassen.
      Deshalb unternehme auch kaum jemand ernsthafte Anstrengungen, das ordentlich zu unterstützen.
    • Unabhängig von Rust/Zig sei der heutige Zustand des Cross-Compilings nahezu eine „Katastrophe“.
      Besonders unter Linux sei das gravierend, weil die glibc-Struktur veraltet sei und es dadurch schwierig werde, auf beliebige Hardware gegen eine minimale glibc zu zielen.
      Die meisten Projekte versuchten nicht einmal, Cross-Compile-Support bereitzustellen.
      Zig bemühe sich, das zu verbessern.
  • Es wird argumentiert, dass man die Einführung besser verschieben sollte, bis das Rust-Frontend für gcc ausreichend ausgereift ist.
    Git sei ein zentrales Werkzeug des Projekts, daher seien Änderungen mit hohem Risiko verbunden, und es sei gefährlich, Rust schon in einem so kurzen Zeitraum wie sechs Monaten zu einer Pflichtabhängigkeit zu machen.
  • Rust habe ähnlich wie funktionale Sprachen eine steile Lernkurve und sei komplex.
    Diese Komplexität diene dazu, mehr Fehler schon zur Compile-Zeit abzufangen, mache aber die Sprache selbst ziemlich kompliziert.
    Aus diesem Grund wird von einer Einführung abgeraten.
    Soweit bekannt, habe auch der Kernel Rust abgelehnt.
    Wenn man zu einem ohnehin komplexen Kernel noch ein Haskell-ähnliches Typsystem und ein Makrosystem auf Lisp-Niveau hinzufüge, steige die Komplexität weiter.
    Rust-Code über serde nachzuverfolgen sei schwierig.
    Dagegen lasse sich Go mit Unmarshal viel leichter nachvollziehen.
    • Ich empfinde funktionale Sprachen und Rust im Gegenteil als klarer als C oder Go.
      Das liege daran, dass man mehr Informationen im Compiler unterbringen könne.
      Mit Serde hatte ich nie große Probleme; deutlich häufiger musste ich das Verhalten von Gos Unmarshal debuggen.
      Die Behauptung, der Kernel habe Rust abgelehnt, treffe so nicht zu; tatsächlich habe es einen Konflikt zwischen zwei Entwicklern über den Speicherort von Headern gegeben.
    • C ist zwar einfach, aber sicheres und performantes C ist äußerst komplex.
      Rust habe zwar eine höhere Einstiegshürde als C, doch die Lücke zwischen „minimalem Rust“ und „schnellem, sicherem Rust“ sei viel kleiner als bei C.
    • Es wird darauf hingewiesen, dass Rust als komplex bezeichnet werde, C aber ebenfalls keineswegs unkompliziert sei.
    • Gerade diese Bequemlichkeit durch Prüfungen zur Compile-Zeit sei ein Unterscheidungsmerkmal von Rust.
      Sie werde als ähnlich wichtig angesehen wie der Borrow Checker.
    • Wer Erfahrung mit TypeScript habe und durch Linter gelernt habe, mit Referenzen sowie Result-Unwrapping/Fehlerbehandlung umzugehen, für den sei Rust durchaus gut erlernbar.
      Auch die Syntax sei nachsichtig.
      Der Linux-Kernel habe Rust tatsächlich nicht abgelehnt.