10 Jahre auf Rust gesetzt – und worauf ich mich als Nächstes freue

• Ein Beitrag, der 10 Jahre praktische Einführung von Rust direkt nach dem Release von Rust 1.0 sowie die Erwartungen an die kommenden zehn Jahre zusammenfasst
• In der Anfangszeit waren Probleme mit der Versionskompatibilität, Build-Zeiten und die Eingewöhnung an den Borrow Checker schwierig
• Die Rust-Community und das Ökosystem entwickelten sich dank eines „außergewöhnlichen Programmierverständnisses“ und einer starken Gemeinschaftskultur schnell weiter; besonders auffällig ist, wie viele hervorragende Entwickler zu Rust strömen
• Heute ist Rust in allgemeinen System- und Backend-Bereichen zu einer „soliden Wahl“ geworden; durch die Weiterentwicklung der Standardbibliothek und die Reife des Crate-Ökosystems hat die Unsicherheit deutlich abgenommen
• Der Artikel zeigt konkret verbleibende Aufgaben und Entwicklungsrichtungen für Rust auf, etwa Build-Geschwindigkeit, Portabilität, const-Funktionen, Concurrency und die Ausweitung auf verschiedene Domänen
• Für die kommenden zehn Jahre werden schnellere Kompilierung, eine breite Ausweitung auf weitere Domänen und Innovationen bei der Developer Experience erwartet; zugleich dürfte sich die positive Feedback-Schleife des Rust-Ökosystems weiter beschleunigen

---

• Im Juni 2015, etwa einen Monat nachdem die erste Begeisterung rund um Rust 1.0 abgeklungen war, wurde der erste Rust-Code geschrieben
• Nach Jahren mit C, Python und JavaScript führte die Begegnung mit Rust dazu, dass es kein Zurück mehr gab
• Auf Basis der Erfahrung mit zwei Rust-Startups und mehr als 500.000 geschriebenen Codezeilen teilt der Autor eine Rückschau auf zehn Jahre

Die Anfangszeit war hart - The early days were painful

• Bei der frühen Einführung von Rust war die Versionskompatibilität zwischen Crates und Compiler äußerst instabil; selbst kleine Bugfixes zwangen oft zu einem Update der gesamten Build-Umgebung
• Das Konzept des Borrow Checkers und das Management von Lifetimes fühlten sich schwierig an, und mit zunehmender Komplexität der Typen stiegen die Compile-Zeiten drastisch an
• Immer wenn neue Funktionen oder Bugfixes nötig waren, mussten gefühlt „alle Versionen der Welt“ aktualisiert werden; viel Zeit ging dafür drauf, kompatible Versionen zu finden

Die Außergewöhnlichkeit der Rust-Community - The people were and are exceptional

• Im Rust-Ökosystem hat sich eine herausragende Programmierkultur etabliert, die einfache und elegante Implementierungen sowie schnelle und robuste Performance anstrebt
• Im Vergleich zu TypeScript oder Python ist die Abhängigkeitsstruktur in Rust deutlich sauberer und der Build einfacher
• Das engagierte Mitwirken von Community-Freiwilligen und die vorsichtige Haltung „jetzt noch nicht / noch nicht soweit“ spielen eine Schlüsselrolle
• In London war Rust bei der Suche nach Entwicklern ein großer Vorteil, und das durchschnittliche Fähigkeitsniveau von Rust-Entwicklern ist sehr hoch

Rust ist zu einer sicheren Wette geworden (in einigen Domänen) - Rust has become a safe bet (in some domains)

• In der Anfangszeit mussten wegen fehlender Funktionen in der Standardbibliothek (std) Utility-Funktionen und Patches oft selbst geschrieben werden; heute steckt das meiste in std und in Crates, wodurch die Unsicherheit stark gesunken ist
• Durch vorhersehbarere Builds und Upgrades, weniger externe Abhängigkeiten, Einhaltung von semver sowie Verbesserungen beim Borrow Checker und der Inferenz-Engine ist die Nutzung von Rust deutlich stabiler geworden
• Neue Crates wie jiff, polars und tauri entstehen auf Basis früherer Learnings, und tokio, hyper, regex und andere sind in der Praxis erprobt
• Früher ließ sich das „Neuerfinden des Rads“ kaum vermeiden, heute kann man sich auf die Business-Logik konzentrieren und zugleich performante sowie robuste Anwendungen entwickeln

Die Entwicklungsumgebung, die Rust heute bietet - Rust today feels like what programming should be

• Rust ist eine Sprache mit Einfühlungsvermögen für Entwickler: kompaktes und robustes Build-System, erstklassige Fehlermeldungen und Lints, hervorragende Dokumentation und IDE-Integration sowie starke CI- und Regressionstests
• Unter großen Open-Source-Projekten gibt es kaum eine Sprache, die so programmerfreundlich ist wie Rust
• Die langfristigen Investitionen zahlloser Communities und Mitwirkender sind ein Schlüsselfaktor dafür, dass Rust heute dort steht, wo es steht

Worauf ich mich in den nächsten 10 Jahren freue - What I’m looking forward to over the next 10 years

Einfachere und schnellere Builds - Simpler and faster builds

• Es ist zu erwarten, dass die Arbeit weitergeht, komplexe oder langsame Abhängigkeiten durch einfache und schnelle Alternativen zu ersetzen
• Erwartet werden neue Ansätze wie eine Standardbibliothek in reinem Rust, weniger Abhängigkeit von System-Linkern und Bibliotheken, pure-Rust-Kryptografie, persistente BTreeMaps und Spiel-Engines auf Rust-Basis
• Auch bei Tably hat sich in den vergangenen Monaten die Kompilierungsgeschwindigkeit von Frontend und Backend um 60 % verbessert

Mehr Portabilität und weniger #[cfg()] - Improved portability and less #[cfg()]

• Es ist schwierig, die vielen Kombinationen aus Plattformen und Optionen zu testen; zudem führt #[cfg()] zu ungetestetem Code, unvollständiger Dokumentation und IDE-Problemen
• Wenn #[cfg()] in das Trait-System verlagert würde, könnte das Garantien für Plattformen und Optionen, weniger Recompilierung, MIR-Caching und schnellere CI ermöglichen

Wenn aller Code const wäre - Everything being const

• Wenn mehr Arbeit schon zur Compile-Zeit erledigt wird, sinkt die Abhängigkeit von Makros und Build-Skripten, und Laufzeitfehler lassen sich früher verhindern
• Derzeit ist das noch begrenzt, doch langfristig geht die Richtung zu einem Rust, in dem „aller Code in einem const-Kontext ausführbar“ ist

Einfachere Concurrency - Simpler concurrency

• Das aktuelle Async-Modell von Rust ist durch Dinge wie 'static-Bounds, Cancellation-Safety und Trait-Einschränkungen komplex und erschwert die praktische Arbeit
• Nötig ist eine einfachere, auf Sprachebene verankerte Form von Concurrency, ähnlich den früheren User-Space-Green-Threads (libgreen)

In mehr Domänen überzeugen - Excelling in more domains

• Der Einsatz von Rust im Webbrowser, insbesondere bei wasm/rustwasm, ist noch nicht vollständig erschlossen; unter anderem bleiben Themen wie Cross-Browser-Stacktraces offen
  • Frameworks wie leptos und sycamore entwickeln sich weiter, dennoch gibt es weiterhin viel Verbesserungspotenzial
• Auch in Bereichen wie Rapid Prototyping, Business-Logik, GUI, Machine Learning und Game Development, in denen Rust noch nicht vollständig durchgebrochen ist, sind weitere Fortschritte zu erwarten

Fazit

• Die Zukunft des Rust-Wachstums ist sehr klar und vielversprechend
• Je stärker die Einführung zunimmt, desto mehr wachsen Engineering- und Test-Kompetenzen; dadurch entsteht ein positiver Kreislauf aus breiterer Akzeptanz und weiteren Verbesserungen
• In den kommenden zehn Jahren dürften schnellere Kompilierung, der Einsatz in vielfältigen Bereichen und eine reibungslose Developer Experience Realität werden
• Die neuen zehn Jahre von Rust machen Vorfreude

[ndrgrd]

Rust ist zwar insgesamt gut, aber die Sprache verlangt einfach zu viel.
Wenn man Rust benutzt, hat man manchmal das Gefühl, eher Rust als Sprache zu studieren, statt sich auf die eigentliche Umsetzung einer Idee zu konzentrieren.

Für die Migration bereits bestehender Projekte, etwa aus C++, dürfte das kein großes Problem sein,
aber ich bin mir nicht sicher, ob es wirklich angenehm ist, sie zu verwenden, wenn man neue Ideen umsetzen will.

[felizgeek]

Für Prototyping empfehle ich Python.

[ndrgrd]

Ich persönlich bevorzuge Typsysteme und nutze derzeit C#, womit ich in diesem Umfang zufrieden bin.

[codemasterkimc]

Persönlich denke ich mit Blick auf die Umwelt der Erde an RUST. Legacy-Spring-Code nach Axum!!!

[GN⁺]

Hacker-News-Kommentare

• Ein sehr positiver Artikel, der sich auch mit meinen Erfahrungen deckt. Wenn ich aber einen düsteren Ausblick nennen müsste, dann diesen Punkt:
  "async bringt vergleichsweise hohe Komplexitätskosten mit sich – wegen static bounds, Cancellation-Safety sowie Einschränkungen rund um Traits und dyn. Derzeit sieht es nicht danach aus, als würde sich dieses Problem lösen. Die Aufspaltung zwischen synchronen/asynchronen Primitiven und die Eigenheiten des Ökosystems erhöhen die async tax (zusätzliche Kosten). Auch auf Effects basierende Lösungen wirken nicht besonders vielversprechend."
  "Vor Rust 1.0 gab es mit libgreen eine Lösung. Sie implementierte Nebenläufigkeit im User Space ohne bifurcation (Aufspaltung), wurde aber wegen erheblicher Kosten bei Performance, Portabilität und Wartbarkeit letztlich entfernt. Wenn die nötige Engineering-Kapazität vorhanden wäre, fände ich es durchaus wert, noch einmal darüber nachzudenken. Irgendwann würde ich gern ein PoC bauen, das std::{fs, net} und fiber::{spawn, select} per Generatoren als zero-cost wrapping umsetzt."
  • Ich bin der Meinung, dass die Diskussion „'static bound erhöht die Komplexität“ eher eine Designentscheidung der Tokio-Async-Runtime ist und nicht unbedingt dem Gesamtdesign von Rust zugeschrieben werden sollte. Die Embassy-Async-Runtime funktioniert auch ohne solche Bounds, dafür muss man allerdings Pinning selbst verwalten. Der 'static bound dient eigentlich eher dazu, die Komplexität zu senken
• Als jemand, der sich Ende 2022 in Rust verliebt und es gelernt hat, finde ich die Erfahrungsberichte von Leuten immer spannend, die die Sprache schon in schwierigeren Zeiten wie 2015 gelernt haben. Ich hatte das Glück, Rust in einem reiferen Stadium zu lernen, sodass die ohnehin steile Lernkurve schon etwas abgeflacht war. In gewisser Weise habe ich heute das Gefühl, mit Zig dieselbe Frühphase zu erleben, die Rust damals hatte. Zig scheint an einem ähnlichen Punkt zu sein wie Rust in seinen Anfangsjahren. Trotzdem benutze ich es jetzt schon mit viel Spaß
  • Es gibt eine starke Kultur des „Hinterlasse es in einem besseren Zustand, als du es vorgefunden hast“. Wenn ein Tool oder eine Sprache verwirrend war, gilt das nicht als Fehler des Nutzers. Wenn ich verwirrt war, werden andere es wahrscheinlich auch sein, also bringt jede Verbesserung, die man entdeckt und umsetzt, allen viel. Hier passt das Sprichwort, dass heute der zweitbeste Zeitpunkt ist, einen Baum zu pflanzen. Dank dieser Kultur kann jemand, der Rust früher ausprobiert hat und daran gescheitert ist, ein Jahr später eine deutlich bessere Erfahrung machen. Deshalb war mein bester Rat für Rust-Einsteiger: „Warte einfach sechs Monate“
  • Wenn eine Sprache von Big Tech wie MSFT oder Google oder von großen Open-Source-Projekten wie Linux übernommen wurde, ist das ein Beleg dafür, dass das Ökosystem bereits ausreichend ausgereift ist. Bei Zig habe ich dieses Vertrauen aber noch nicht, weil es gegenüber bestehenden Werkzeugen bislang keine wirklich großen Veränderungen gezeigt hat
• Rust fühlt sich für mich so an, als würde es funktionale Programmierung fördern. Ursprünglich wollte ich einen Parser bauen, der seinen internen Zustand bei jedem advance verändert, aber wegen Mutabilität und Borrowing war das mühsam, also musste ich auf einen zustandslosen Parser umstellen. Statt intern einen Index zu verändern, habe ich die Struktur so geändert, dass sie den Index zurückgibt. Ich frage mich, ob es in Rust oft vorkommt, dass gewohnte Vorgehensweisen nicht gut funktionieren und man neu an das Problem herangehen muss
  • Ich hatte eine ähnliche Erfahrung. In einfachen Fällen funktioniert ein mutabler, imperativer Stil problemlos, aber je komplexer es wird, desto stärker wechsle ich zu einem funktionalen Stil und versuche Änderungen möglichst zu vermeiden. Wegen Borrow Checker und Lifetimes werden traditionelle Muster schwierig, und man landet ganz natürlich bei funktionaleren Ansätzen. Wenn man darin nicht geübt ist, kann das hart sein, aber es ist auch eine Erfahrung, bei der der Compiler zufriedener wirkt
• Async/await ist der einzige Grund, warum ich Rust nicht benutze
  • Tatsächlich ist async/await für mich einer der Hauptgründe, Rust überhaupt zu verwenden. Es macht Nebenläufigkeitsmuster viel einfacher. Am Anfang fühlte es sich an, als müsse sich wie bei einer bösartigen Ansteckung am Ende jeder Code in async verwandeln, aber sobald man weiß, wie man mit async-Code interagiert, wird es bequem. Normalerweise machen spawn, spawn_blocking und futures::stream 90 % der Nutzung aus, und wenn man passende „Grenzen“ setzt, muss sich async auch nicht überall ausbreiten
  • Bis zu einem gewissen Grad kann ich das nachvollziehen. Für mich passt async/await in Rust aber sehr gut, sodass es zu einem der größten Gründe geworden ist, es zu nutzen. Mir gefällt auch die Syntax, und das Function-Coloring-Problem stört mich kaum. Gerade mit Tokio habe ich das Gefühl, dass sich Lösungen gut ergeben, weil es asynchrone Versionen aller benötigten Standardfunktionen gibt. Solche Punkte können zwar Hürden schaffen, aber Nebenläufigkeitsprogramme sind damit viel leichter zu schreiben und die Performance ist auch ordentlich, also bin ich zufrieden. Bei Dingen wie Cancellation irre ich manchmal noch herum, aber das sehe ich eher als mein eigenes Kompetenzproblem
  • Wird das inzwischen nicht ohnehin alles bereitgestellt?