Rust im Jahr 2025: Auf dem Weg zu Foundational Software

• Rust feiert in diesem Jahr sein 10-jähriges Bestehen und etabliert sich als zentrale Sprache für die Entwicklung von Foundational Software
• Foundational Software bezeichnet die Schicht, die allem zugrunde liegt, etwa Betriebssystem-Kernel, Cloud-Plattformen, Embedded-Geräte und CLI-Tools
• Rust bietet Performance und Zuverlässigkeit auf C/C++-Niveau und senkt zugleich dank eines Typsystems mit garantierter Speichersicherheit die Hürden
• Rusts Mission beschränkt sich nicht nur auf den Basisbereich, sondern wirkt mit Projekten wie Dioxus, Tauri, Leptos auch auf die Entwicklung höherer Anwendungsebenen aus
• Künftig sind Sprachinteroperabilität, Ausbau des Typsystems und Stärkung des Ökosystems als zentrale Investitionsbereiche geplant

---

Rusts Vision: Foundational Software

• Rusts Kernvision ist es, Foundational Software einfacher zu schreiben und zu warten
  • Dazu zählen Betriebssystem-Kernel, Cloud-Infrastruktur, Embedded-Geräte und CLI-Tools, also die Grundlagen aller Systeme
  • Rust wird bereits in vielen Bereichen eingesetzt, darunter im Windows- und Linux-Kernel, in der VSCode-Suchmaschine ripgrep, in Deno und im Python-Paketmanager uv
• Bei solcher Software sind Performance, Zuverlässigkeit und Produktivität gleichzeitig entscheidend
  • Wenn die Grundlage versagt, wirkt sich das auf alle darüberliegenden Schichten aus, daher ist Stabilität unverzichtbar
  • Leistungseinbußen setzen die Grenzen für die Performance der höheren Schichten, deshalb ist minimaler Overhead nötig

Performance, Zuverlässigkeit und Produktivität von Foundational Software

• Foundational Software hat wie jede Software vielfältige Anforderungen, nur ist hier jeder einzelne Aspekt noch wichtiger
  • Zuverlässigkeit hat höchste Priorität. Wenn das Fundament zusammenbricht, scheitert alles, was darauf aufbaut
  • Performance-Overhead bestimmt die Leistungsgrenze der höheren Schichten und muss daher minimiert werden
• Bisher gab es zur Erfüllung dieser Anforderungen im Wesentlichen zwei Optionen
  • C/C++: bietet große Freiheit, verlangt dafür aber ein entsprechend hohes Maß an Perfektion
  • Höhere Programmiersprachen wie Java oder Go: erfordern spezielle Codierweisen, um die Performance zu halten, und schränken den Einsatz von Abstraktion und Komfort ein
• Rust verändert diesen Ansatz durch die Kombination aus Zero-Cost-Abstraktionen und einem Typsystem, das Speichersicherheit garantiert
• Damit wird es möglich, High-Level-Code sicher zu schreiben und zugleich Low-Level-Performance und Speicherstabilität zu erreichen

Hürden senken und Entwickler stärken

• In Rust-Vorträgen werden Typsystem und statische Prüfungen oft mit „Spinat“ verglichen: gut für einen, aber nicht unbedingt beliebt
• In der Praxis ist das Typsystem jedoch ein äußerst wirkungsvolles Werkzeug für Entwickler
• Einsteiger können durch das Typsystem lernen, wie erfolgreiche Softwarestrukturen aufgebaut werden
• Erfahrene Entwickler entdecken Fehler in ihren eigenen Architekturentwürfen schneller

• Yehuda Katz’ Aussage, dass „Abstraktionen, die man in einem Zustand tiefer Konzentration schafft, dem müden zukünftigen Ich helfen“, fasst das sehr gut zusammen

Bereiche außerhalb der Foundational Software

• Auch wenn Rusts Mission auf Foundational Software fokussiert ist, bedeutet das nicht, dass andere Bereiche ignoriert werden
• Projekte wie Dioxus, Tauri, Leptos erweitern Rust auch in Richtung höherer Anwendungsebenen wie GUIs und Webseiten
• Rusts wichtigste Stärken liegen zwar grundsätzlich im Bereich Foundational Software, doch diese Versuche sollten nicht übersehen werden

Ambitionierte Ziele und Wachstum

• Da Foundational Software Kontrolle über Details auf niedriger Ebene erfordert, wird Zugänglichkeit und Ergonomie oft als weniger wichtig angesehen
• Gerade weil diese Detailkontrolle nötig ist, ist gute Usability umso wichtiger
• Wenn Entwickler sich nur auf die wirklich wichtigen Teile konzentrieren können, steigt die Produktivität deutlich

• Projekte, die den Einsatz von Rust auf höherer Ebene vorantreiben, eröffnen Chancen, das Programmieren mit Rust insgesamt komfortabler zu machen
• Diese Verbesserungen fließen dann direkt auch in die Entwicklung von Foundational Software zurück
• Entscheidend ist, die Kontrolle und Zuverlässigkeit zu bewahren und zugleich die Ergonomie zu erhöhen

Warum Full-Stack-Unterstützung wichtig ist

• Ein weiterer Grund, warum angenehme Entwicklung von High-Level-Anwendungen in Rust wichtig ist, besteht darin, dass sich damit der gesamte Stack mit einer einzigen Technologie aufbauen lässt
• Entwickler, die Rust zunächst nur in Teilbereichen wie Data-Plane-Services einsetzen wollten, weiten den Einsatz häufig auf den gesamten Bereich aus
• Der Grund dafür ist Rusts hohe Produktivität und die Möglichkeit, Bibliotheken und Code in einer Sprache gemeinsam zu nutzen
• Im Kern bleibt einfacher Code in jeder Sprache einfach

Die Erfahrung von Iterative Deepening

• Idealerweise sollte die erste Erfahrung mit Rust einfach sein, und mit dem Fortschritt eines Projekts sollte sich schrittweise und lokal mehr Kontrolle hinzufügen lassen
• Das klingt einfach, ist in der Praxis aber eine sehr schwierige Aufgabe
• Viele Projekte scheitern daran, dass die Einstiegshürde für Anfänger hoch ist oder dass für höhere Kontrollstufen sehr viel Wissen erforderlich ist
• Rust gelingt das nicht immer, arbeitet aber kontinuierlich daran, sich in diesem Punkt zu verbessern

Der weitere Plan

• Dieser Text ist der erste Beitrag einer Reihe; in vier weiteren Teilen sollen die Investitionsfelder vorgestellt werden, die Rust besser für Foundational Software machen sollen
  • Sprachinteroperabilität (smooth language interop) und Erweiterbarkeit (extensibility)
  • Klarheit des Ziels durch das Typsystem (clarity of purpose)
  • Stärkung des Ökosystems: bessere Leitlinien, Werkzeuge und Nutzung der Rust Foundation
  • Der letzte Beitrag behandelt die Organisation von Rust-Open-Source-Projekten und wie Beiträge und Wartung möglichst zugänglich und angenehm gestaltet werden können

[yeorinhieut]

Rust wirkt zwar irgendwie ganz ordentlich, ist für mich aber wohl die einzige Sprache, die ich wegen ihres toxischen Fandoms(?) meide.

[aer0700]

Ich wünschte, es gäbe für C oder C++ einen standardmäßigen Paketmanager. Wenn ich mir Cargo anschaue, denke ich das immer wieder.

[cosine20]

Wie lecker Spinat doch ist....

[t7vonn]

Heutzutage gibt es praktisch keinen Bereich mehr, in dem Rust nicht eingesetzt wird.

[lostid]

Ich arbeite zwar bei einem ziemlich großen Unternehmen, aber es gibt dort keinen Bereich, in dem Rust eingesetzt wird. Bitte stellen Sie das nicht verzerrt dar.

[t7vonn]

Legen Sie sich nicht mit mir an.

[bobross0]

Boah...;;

[crawler]

Legt euch bitte nicht mit mir an, zitter zitter

[shakespeares]

Krass ;;

[qwas5544]

Boah;;;

[lostid]

Mal ganz davon abgesehen, wegen der heutigen Rust-Fanatiker drehe ich fast durch. Offline sind sie selbst unter den Minderheiten eine absolute Randgruppe, online aber fast wie ISIS ... Ach, wenn sie sich doch einfach irgendwo an einem Ort versammeln und nur unter sich bleiben würden ...

[ifmkl]

Bei manchen, die wie Rust-Evangelisten auftreten, fragt man sich oft, ob sie es selbst überhaupt richtig verwenden.

[skageektp]

Trotzdem ... Sie mögen Rust doch, oder?
Ihr dürft Rust-Fanatiker hassen, aber bitte liebt Rust ;_;

[taeunlee99]

Selbst wenn man wie bei FFmpeg Prügel bezieht, müsse man dennoch den gesamten Code in Rust schreiben oder so ähnlich.

[GN⁺]

Hacker-News-Kommentare

• Wenn es um Kernsoftware geht, ist das größte Manko von Rust meiner Meinung nach die ABI. Wenn man ein OS in Rust bauen und reichhaltige Dienste anbieten will, müssen Anwendungen auch nach einem Upgrade des OS nutzbar bleiben, ohne Bibliotheken neu kompilieren zu müssen. Windows löst dieses Problem mit COM, Apple tat es früher mit dynamic dispatch in ObjC (und heute mit der Swift-ABI), Android mit der JVM und Bytecode. Rust unterstützt faktisch nur extern "C", daher ist die Nutzung dynamischer Bibliotheken eingeschränkt. Eine ABI ohne VM-Schicht (JVM, .NET) bereitzustellen ist extrem schwierig, und weil man einmal festgelegte Implementierungsdetails niemals mehr ändern darf, ist es nachvollziehbar, dass das keine hohe Priorität hat. Tatsächlich waren nur Swift und COM mit so einem Modell wirklich erfolgreich. Wenn Rust eine vollständige ABI bekäme, wäre es fast eine perfekte Sprache. (Wenn Abhängigkeiten in Binärform verwaltet würden, würden auch die Compile-Zeiten stark sinken.)

  • Es wird erklärt, dass Rust standardmäßig nur eine optionale (opt-in) ABI-Stabilität anstrebt, weil die Sprache zero-cost abstractions verfolgt. Eine stabile ABI geht mit Performance-Verlusten einher, wie auch das Beispiel von C++ belegt (Erklärung zur C++-ABI). Zum dynamischen Laden von Plugins zwischen Rust-Komponenten (dlopen) gibt es Werkzeuge wie stabby und abi_stable, die ziemlich gut funktionieren. Für allgemeinere Sprachinteroperabilität könnte crABI (crABI-Vorschlag) künftig eine Alternative sein. Das ist allerdings kein Problem, das Rust allein lösen kann; dafür braucht es Unterstützung und Zusammenarbeit vieler Communities, etwa anderer Sprachen und Linux-Distributionen. Außerdem wird erwähnt, dass Rust I/O und Speicherallokation explizit auswählt, weshalb ein Modell wie bei Swift, das alles über Shared Libraries löst, möglicherweise nicht gut passt.
  • Fast dasselbe Problem soll derzeit mit Wasm Components gelöst werden. Wenn WebAssembly ein portables Befehlsformat ist, dann sind WebAssembly Components ein portables Ausführungs-/Linking-Format. Es ist nicht ganz so unkompliziert wie repr(wasm)/extern "wasm", aber mit wit-bindgen oder dem Ziel wasm32-wasip2 lässt es sich ohne große Mühe nutzen. Einführungsvideo zu Wasm Components
  • Es wird angezweifelt, ob das wirklich nötig ist. Es wäre zwar bequemer, mehr verschiedene „Dinge“ (slices, trait objects usw.) über Interfaces zu übergeben, aber praktisch lässt sich mit der extern "C"-ABI bereits alles Nötige erledigen. Und es soll auch Vorschläge geben, die extern-ABI auf mehr Typen auszuweiten.
  • Auf einer Rust-Konferenz habe man zu diesem Thema einen Vortrag gesehen, der sich stark am Swift-Ansatz orientierte. Vermutlich wird es sich künftig in diese Richtung entwickeln.
  • Tatsächlich gibt es so etwas schon. Es heißt einfach „C“.

• Ich mag Rust wirklich sehr, aber es gibt einige dauerhaft nervige Probleme, die mehr Aufmerksamkeit bekommen sollten.

  • 1. Das Problem selbstreferenzieller Structs. Zum Beispiel möchte man Quelltextdatei und den geparsten AST im selben Struct ablegen, aber das ist derzeit nicht einfach. Etwas wie Offset-Referenzen wäre hilfreich.
  • 2. Die orphan rule. Ich verstehe den Grund, aber sie ist trotzdem lästig. Man kann das mit neuen Features lösen (manchmal ist sogar 2- bis 3-faches Wrapping nötig!), aber ob es wirklich so sein muss, ist fraglich.
  • 3. Um akzeptable Compile-Zeiten zu bekommen, muss man Projekte in viele kleine Crates aufteilen. Ich verstehe warum, aber das Ergebnis ist nicht gut. Eine Crate wird als eine Compile-Einheit behandelt, weil zirkuläre Abhängigkeiten erlaubt sind. In den meisten Codebasen gibt es solche Zyklen aber in Wirklichkeit nicht, daher wäre es gut, das als opt-in zu behandeln oder Items/Dateien innerhalb einer Crate automatisch anhand des Abhängigkeitsgraphen in Compile-Einheiten aufzuteilen.
  • Das sind nur ein paar Punkte, die mir spontan einfallen, aber es gibt sicher noch mehr. Rust ist trotz konstruktiver Kritik die beste Sprache meines Lebens.
    • Es wird darauf hingewiesen, dass Rust keine zirkulären Abhängigkeiten zwischen Crates erlaubt, wohl aber zwischen Modulen innerhalb einer Crate. Man glaube zwar, dass die meisten Codebasen keine Zyklen enthalten, aber schon ein Modul mit einem test-Submodul fällt unter diese Regel. Um Tests sauber zu trennen, müsste man alle Testfunktionen im Crate-Root definieren, was in der Praxis ineffizient ist.
    • Den Punkten 1 und 2 stimme man vollständig zu. Als Punkt 4 wünsche man sich außerdem partial self borrows, also eine Funktion, mit der Methoden nur Teile eines Structs ausleihen. Bei Punkt 3 brauche es zuvor eher bessere Unterstützung dafür, mehrere Crates gemeinsam zu veröffentlichen.
    • Zur orphan rule wird um nähere Erläuterung gebeten: Geht es darum, dass Rust eine bessere Alternative einführen sollte, oder nur darum, dass man Features braucht, mit denen sich das umgehen lässt?
    • Der Kritik an der orphan rule wird voll zugestimmt. In Application-Crates sollte man sie vielleicht deaktivieren können, oder die Regel lockern, wenn durch proc macro und Ähnliches ausreichend Hygiene garantiert ist.

• Über den Ausdruck „Smooth, iterative deepening“ nachdenkend, scheint Rust die Cross-Language-Kompatibilität zu stark zu betonen, was eher die Komplexität erhöht und die Sicherheit gefährden könnte. Hilfreicher wäre es in so einem Fall, eher die unterste Schicht des Systems wie libc zu ersetzen. Go führt fast keine sprachübergreifenden Aufrufe aus. Google hat Kernbibliotheken selbst entwickelt und damit das Fundament gestärkt, während bei Rust viele unterschiedliche Versionen grundlegender Bibliotheken nebeneinander existieren und vieles unvollständig ist.

  • Es wird betont, dass eine der zentralen Herausforderungen der Informatik der letzten 20 Jahre darin bestand, mehrere Programme auf derselben Maschine effizient miteinander kommunizieren zu lassen. Meist versucht man, das Microsoft-DLL-Modell über Source und State zu umgehen, oder Objekt-Request-Broker wie CORBA konnten sich nicht durchsetzen. Gleiches gilt für RPC im QNX-Stil. Deshalb wiederholt sich bis heute nur der Versuch, Dinge gewaltsam zusammenzukleben, die eigentlich nicht gut zusammenpassen.
  • In der Praxis kann man zwar alles auch über Sockets lösen, aber Sockets sind rohe Byte-Streams und damit eigentlich die falsche Abstraktion; sie werden trotzdem genutzt, weil sie gut handhabbar sind.
    • Aus meiner Sicht geht es in dem Beitrag nicht darum, einen echten sprachübergreifenden Ersatz für Shared Libraries wie DLL/COM/Wasm Components zu schaffen, sondern um das praktische Bedürfnis, C++ schrittweise auf Rust zu migrieren. Für eine allgemeine Verbesserung der Speichersicherheit ist die Frage „Was machen wir mit bestehenden Programmen?“ zentral, und das heutige Interop-Niveau zwischen Rust und C++ reicht dafür nicht aus. Wenn beide Sprachen auf Source-Ebene sauber zusammenarbeiten könnten, würde die reale Chance steigen, dass Rust einen großen Teil des C++-Einsatzfelds ersetzt.
    • Manchmal scheinen Sockets plus Protokoll fast die bestmögliche Cross-Language-Abstraktion zu sein. Dann stellt sich die Frage, welche Abstraktion für sprachübergreifende Aufrufe denn tatsächlich ideal wäre.

• Es wird hervorgehoben, dass „Allokationen vermeiden, keinen GC triggern“ nicht zu modernen Konzepten von GC und JIT passt. Moderner GC hat teils nahezu keine stop-the-world-Latenz mehr, und der gesamte CPU-Aufwand für GC hängt stark vom Verhältnis zwischen resident set und Heap-Größe ab. JIT hat gegenüber AOT sogar mehr Optimierungsmöglichkeiten und kann aggressiver explorieren (dank spekulativer Optimierung). Wirklich relevant sind Start-/Warmup-Latenz, Speicher-Overhead und durchschnittliche Performance, nicht die verschlechterte Worst-Case-Performance. Außerdem ist manuelle Speicherverwaltung nicht zwingend effizienter, und selbst wenn der tatsächliche RAM-Verbrauch dreimal so hoch wäre, könnten die Kosten trotzdem null sein. Empfehlenswert ist dazu auch dieser ISMM-Konferenzvortrag.

  • Es wird konkret nachgefragt, was genau gemeint ist mit der Aussage, JIT sehe mehr Optimierungsmöglichkeiten. JIT sei am Ende doch nur eine Ergänzung zu AOT.
  • Hier wird gefragt, welche konkrete Implementierung mit „modernem GC“ gemeint ist.

• Es wird gesagt, dass die markierten Kommentare und die Diskussion die Kernfragen gut getroffen hätten. Fragen wie „Lasst uns einen Sprachstandard mit offizieller Spezifikation schaffen“ und „Wir brauchen mehrere Implementierungen“ seien praktisch sehr wichtig. Besonders @infogulch habe gut herausgestellt, dass eine Sprache eine offizielle Spezifikation braucht, wenn sie zur industriellen Grundlage werden soll (Referenzkommentar).

  • Es wird mit einem gewissen Witz darauf hingewiesen, dass weder der Grund für die Markierung klar sei noch dass Sprachen ohne formale Standards oder ohne mehrere Implementierungen daran gehindert worden wären, industrielle Grundlagen zu werden. Ruby hat zwar einen alten ISO-Standard, aber der gilt nur für diese Version, und bei Python ist de facto die Implementierung selbst der Standard. Für Rust gilt Ähnliches, und aus Sicht der meisten Mainstream-Nutzer wäre das kein Grund, die Sprache zu wechseln.
  • Aus Interesse an einem „offiziellen Sprachstandard“ habe man gesucht und rust-lang/reference gefunden. Das Rust-Projekt nehme die Spezifikation der Sprache sehr ernst. Im jüngeren Vision-Blogbeitrag werde der Fortschritt ausführlich beschrieben. Die Spezifikationsarbeit ist sehr groß und schwierig, aber sie wird weiterhin aktiv vorangetrieben; sogar am Wochenende werden PRs in den Master-Branch gemergt.
  • Auch der Punkt mit mehreren Implementierungen dürfte hilfreich sein, da alternative Rust-Compiler wie gccrs bereits offiziell entwickelt werden.
  • Aus skeptischer Sicht erfüllen sowohl LLMs als auch Rust letztlich nur einen Teil der Erwartungen und bringen allenfalls eine leichte Produktivitätssteigerung. Der Haltung mancher in der Community, ihren Einfluss ohne Verantwortung auszuweiten, wird jedoch nicht zugestimmt.
  • Es wird um genauere Erklärung gebeten, was mit einem „published language standard“ gemeint ist und welchen praktischen Nutzen er hat.
  • Mit Rust selbst habe man kein Problem, wohl aber mit der Haltung einiger Nutzer, die Bedeutung einer formalen Spezifikation nicht zu verstehen. Die Lebensdauer und Zuverlässigkeit jedes rechnergestützten Systems hängen davon ab, wie formal man sich seiner Spezifikation nähert. Ohne klare Spezifikation ist man vollständig darauf angewiesen, dass irgendeine Implementierung zufällig bei irgendeiner Eingabe funktioniert hat; ein System auf einer so fragilen Grundlage aufzubauen ist gefährlich. In der Informatik ist die Spezifikation das eigentliche System, die Implementierung nur eine nachgelagerte Optimierung.

• Leute stellen oft schon die Frage infrage, ob Rust überhaupt eine Spezifikation haben sollte, und genau das zeigt, wie wenig tatsächliches Engineering es im Software Engineering gibt.

  • Software Engineering sei kein echtes Engineering. Anders als bei Brücken oder Hochhäusern muss man etwas nicht dreimal bauen, um es richtig zu machen; bei Software ist genau das oft sogar ein guter Ansatz.

• Zu einem Kommentar, Rust sei „eine Sprache für Leute, die nur wie Programmierer aussehen wollen“, sagt jemand, dass man selbst Programmieren liebe und Rust deshalb wie ein frischer Schock gewesen sei. Man wolle auf keinen Fall in die Zeit zurück, in der C++ extrem schmerzhaft war. Auch Sprachstandard (Spende der Ferrocene-Spezifikation) oder die Anzahl der Implementierungen halte man nicht für entscheidend. Python und Java funktionieren ebenfalls gut, obwohl sich alles auf eine zentrale Implementierung stützt. C++ habe durch die Unterstützung mehrerer Compiler letztlich nur die plattformspezifische Komplexität vergrößert. Was genau mit dem „Durcheinander“ von cargo gemeint sei, sei unklar; aus C++-Sicht sei es dort viel unbequemer gewesen.

  • Es wird gefragt, was an cargo konkret problematisch sei.
  • Zusätzlich wird bezweifelt, ob Standards und Implementierungsvielfalt bei Sprachen wirklich so wichtig sind, ob das nicht zu früh wäre und ob Rust heute so erfolgreich wäre, wenn es schon früh so viel Energie darauf verwendet hätte. Der Artikel wolle offenbar ohnehin nicht den großen Rundumersatz für alles propagieren, sondern eher Unterstützung und Eignung für bestimmte Zielanwendungen hervorheben.
  • cargo sei derzeit der beste Paketmanager unter den großen Sprachen weltweit. Er habe aus dem Scheitern früherer Paketmanager gut gelernt, sei sehr ausgereift und auch infrastrukturell auf hohem Niveau. Ein paar Verbesserungen wie Namespaces oder vollständig reproduzierbare Builds wären noch denkbar, aber cargo in seiner heutigen Form auf eine andere Sprache zu übertragen, wäre fast unmöglich. Kaum eine Sprache verfüge über eine derart gute Infrastruktur.