Rust im Test: Lohnt es sich, die Programmiersprache zu lernen?

Frag zwei erfahrene Rust-Entwickler, ob sich das Lernen von Rust gelohnt hat, und du bekommst womöglich völlig gegensätzliche Antworten. Der eine sagt dir vielleicht, es habe seiner Karriere nichts gebracht; der andere nennt es vielleicht eine der besten technischen Entscheidungen, die er je getroffen hat. Beide können recht haben.

Genau in diesem Widerspruch steckt die Frage „Lohnt es sich, Rust zu lernen?“, und deshalb hilft dir ein pauschales Ja nicht weiter. Rust ist eine kompilierte Sprache, deren sichere Teilmenge Regeln zur Speichersicherheit schon beim Kompilieren durchsetzt, ohne zur Laufzeit einen Garbage Collector zu benötigen.

Also lege ich mich auf eine Antwort fest, nenne die Bedingung, an der sie hängt, und zeige dir, was diese Bedingung kostet.

Die Kurzfassung

Rust lohnt sich, wenn du etwas Langlebiges baust, bei dem es dir etwas wert ist, dass der Compiler eine ganze Klasse von Fehlern abfängt. Die falsche Wahl ist es, wenn du diesen Monat eine CRUD-App ausliefern musst, gerade programmieren lernst oder Stellenanzeigen zählst. 4 von 5, mit Abzug für das, was es kostet, bevor es sich auszahlt.

• Was du kaufst: In sicherem Rust verwandeln die Regeln für Ownership und Borrowing Use-after-free-, Double-free-, Invalid-Reference- und Data-Race-Fehler in Compile-Fehler statt in Produktionsvorfälle. Das ist das ganze Versprechen, und es ist ein gutes.
• Was du bezahlst: Der Compiler zwingt dich, Speicherentscheidungen aufzuschreiben, die deine bisherige Sprache stillschweigend trifft, und am Anfang fühlt sich das an, als würde dir das Werkzeug Steine in den Weg legen.
• Die Frage der Beständigkeit ist geklärt. Die Kernel-Maintainer haben das Rust-Experiment auf dem Maintainers Summit im Dezember 2025 für beendet erklärt, und mit Linux 7.0 fiel das Etikett „experimentell“ weg.
• Die Frage nach dem Trend ist nicht geklärt, und sie ist eine andere Frage. Rust steht im TIOBE-Index vom September 2026 auf Platz #10, nach #18 ein Jahr zuvor.
• Mein Rust-Testservice brauchte zum Kompilieren weit mehr Speicher als zum Laufen: Beim Bauen lag die Spitze bei knapp 1 GB, im laufenden Leerlauf bei etwa 3,5 MB.
• Richtig für dich, wenn du schon in einer anderen Sprache Software auslieferst und etwas baust, bei dem ein Speicherfehler teuer wäre, oder wenn du nah an Systemsoftware arbeitest. Falsch für dich, wenn du unter Termindruck stehst, bei null anfängst oder nach der Sprache mit den meisten offenen Stellen suchst.

So ist dieser Test entstanden: Die Build- und Laufzeitzahlen hier stammen von mir. Ich habe Rust 1.98.1 installiert, einen kleinen Axum-Webservice geschrieben und gemessen, was das Kompilieren und was der Betrieb gekostet haben. Das lief in einem abgeschotteten Container, nicht auf dedizierter Hardware, und es ist ein einziges Projekt, also betrachte die Zahlen als Datenpunkt und nicht als Naturgesetz. Alles andere stammt aus Primärquellen oder maßgeblichen Quellen: dem Kernel-Patch und der Berichterstattung von LWN darüber, den Android-Sicherheitsbeiträgen von Google, dem TIOBE-Index selbst (mit dem Kommentar aus dem April, wie Slashdot ihn festgehalten hat), Phoronix zum Merge-Window von Linux 7.0, den CVE-Einträgen des Linux-Kernels zur Binder-Schwachstelle, der Stellungnahme von Canonical selbst und der Umfrage 2025 von Stack Overflow. Ich habe den Kernel-Patch gelesen. Den Rust-Code im Kernel habe ich nicht auditiert. Und ich schreibe nicht seit Jahren Rust; wo dieser Test die Sprache selbst beurteilt, stützt er sich auf Praktiker, die das tun, und nennt sie beim Namen.

Was dir der Compiler bringt

Gib in Rust zwei Threads eine veränderbare Referenz auf denselben Vektor, und der Code kompiliert nicht. Keine Warnung. Kein Lint, den du unter Zeitdruck abschalten kannst. Er baut schlicht nicht. Diese Weigerung ist es, was du in sicherem Rust kaufst: Use-after-free-, Double-free-, Invalid-Reference- und Data-Race-Fehler werden zu Compile-Fehlern statt zu Produktionsvorfällen. Die Notluke von Rust (unsafe) kann einige dieser Garantien umgehen, es ist also kein absolutes Versprechen für jede Rust-Codebasis.

Ownership bedeutet, dass jeder Wert genau einen Besitzer hat, der für seine Freigabe verantwortlich ist. Borrowing bedeutet, dass du Referenzen verleihen kannst, aber der Compiler verfolgt ihre Lebensdauer und lässt nicht zu, dass eine davon länger lebt als das, worauf sie zeigt, oder dass eine veränderbare Ausleihe neben irgendeiner anderen existiert. In sicherem Rust werden Use-after-free-, Double-free-, Invalid-Reference- und Data-Race-Fehler vom Ownership- und Typsystem abgefangen, bevor das Programm läuft.

Es gibt keinen Garbage Collector, und das ist die andere Hälfte des Deals. Weil Ownership schon festlegt, wer was wann freigibt, muss zur Laufzeit niemand deinen Heap durchsuchen. Du lieferst ein Binary ohne Collector aus und bekommst keine Pausenzeiten, um die herum du tunen musst.

Der Preis zeigt sich an derselben Stelle wie die Garantie. Jede Speicherentscheidung, die deine bisherige Sprache still für dich trifft, verlangt Rust ausdrücklich von dir: wem das hier gehört, wie lange diese Referenz lebt, ob irgendetwas anderes sie sehen kann und ob sie eine Thread-Grenze überschreitet. Der Compiler macht es dir nicht absichtlich schwer. Er weigert sich zu raten.

Also: Das ist der Grund, warum überhaupt jemand den Preis zahlt, den Rust verlangt, und ich finde, er trägt. Wenn die Fehlerklasse, die es beseitigt, keine ist, die dir Sorgen macht, wird der Rest dieses Tests deine Meinung wahrscheinlich nicht ändern.

Ist Rust noch experimentell oder inzwischen Produktionsinfrastruktur?

Experimentell ist es seit Dezember 2025 nicht mehr, und beendet haben das die Kernel-Maintainer selbst. Auf dem Maintainers Summit 2025 kamen sie zu dem Schluss, dass Rust sich im Kernel bewährt hat, technisch wie sozial. Jonathan Corbet von LWN berichtete am 10. Dezember 2025 über den Konsens: Rust im Kernel ist nicht mehr experimentell.

Rust kam 2022 mit v6.1 in den Mainline-Linux-Kernel, genau um dieses Experiment durchzuführen. Der Patch von Miguel Ojeda, der das Etikett entfernte, folgte drei Tage nach dem Summit und landete im Merge-Window von Linux 7.0.

„Aber das Experiment ist beendet, d. h. Rust ist gekommen, um zu bleiben.“

Miguel Ojeda, „rust: conclude the Rust experiment“, LKML, 13. Dezember 2025

Unabhängig davon und schon früher: Googles Rust-Neufassung des Binder-Treibers von Android, der IPC-Schicht, über die die Prozesse von Android (ständig) miteinander reden, landete in Linux 6.18, das am 30. November 2025 erschien. Halte diesen Meilenstein getrennt vom Konsens des Summits. Hier hat ein Unternehmen ein ausgeliefertes Produkt auf Kernel-Rust gesetzt, statt dass eine Maintainer-Runde die Idee absegnet. Kernel-Rust hat inzwischen seine erste CVE hervorgebracht: CVE-2025-68260, eine Race Condition in genau diesem Binder-Treiber, die Greg Kroah-Hartman am 16. Dezember 2025 bekannt gab, eingeführt in 6.18 und behoben in 6.18.1. Die ersten Berichte konzentrierten sich auf Abstürze, doch die spätere Bewertung des CVE-Teams des Linux-Kernels stuft CVE-2025-68260 mit 7,8 (High) ein und beschreibt einen lokalen Weg zur Rechteausweitung über Speicherkorruption im Kernel. Derselbe Treiber (rust_binder) hat seitdem weitere CVEs angesammelt.

Bei Android wird die Beweislage zahlenmäßig greifbar. Googles Security-Blog erklärte im Dezember 2022, dass im Rust-Code von Android keine einzige Speichersicherheitslücke entdeckt worden war, bei rund 1,5 Millionen Zeilen Rust in AOSP und etwa 21 % des gesamten neuen nativen Codes in Android 13. Das ist eine Aussage von 2022 mit dem Stand von 2022. Die späteren Beiträge von Google zeigen den längerfristigen Trend: Speichersicherheitsprobleme machten 76 % der Android-Sicherheitslücken im Jahr 2019 aus, 2024 nur noch 24 %, wobei die absolute Zahl von über 220 auf voraussichtlich 36 fiel. Diese Zahlen bedeuten nur etwas im Vergleich zur Ausgangslage, die sie abgelöst haben: C und C++, geschrieben von sehr guten Ingenieuren mit sehr gutem Tooling.

Zwei kleinere Signale zeigen in dieselbe Richtung. Der GPU-Treiber für Apple AGX in Asahi Linux ist in Rust geschrieben, und zwar vom Projekt Asahi Linux als Reverse-Engineering-Arbeit, nicht von Apple. Das rust-coreutils-Update von Canonical besagt, dass Ubuntu 26.04 LTS für die meisten Tools rust-coreutils 0.8.0 ausliefert. Drei bleiben bei GNU coreutils (cp, mv, rm), weil am 22. April 2026 noch acht TOCTOU-Probleme offen waren; Canonical peilt für die restlichen Tools 26.10 an.

Das ist die Achse, die ich am höchsten bewerten würde, und der Grund ist die Art der Verpflichtung. Kernel-Maintainer machen beendete Experimente nicht rückgängig, Google dreht eine Neufassung dieser Größenordnung nicht zurück, und Canonical packt keine neu geschriebenen coreutils in ein LTS, nur um mal zu sehen, wie es läuft. Was auch immer mit der Beliebtheit von Rust passiert, irgendwer muss diesen Code jahrelang pflegen.

Ist Rust tot oder flacht es nur ab?

Nein. Rust erreichte im Januar 2026 mit Platz #13 erneut seine bisher beste TIOBE-Platzierung. Drei Monate später war es auf #16 zurückgefallen, und TIOBE-CEO Paul Jansen schrieb im April 2026 in einem Kommentar, den Slashdot damals zitierte, dass das Popularitätswachstum von Rust „sich abzuflachen scheint“ und eine Top-10-Platzierung „jetzt weiter entfernt wirkt als zuvor“.

Er beschrieb, wie Rust seine höchste Platzierung aller Zeiten auf seinem eigenen Index erreichte, einen Platz, den es erstmals im Juli 2024 innehatte, und ihn dann wieder abgab.

Der TIOBE-Index vom September 2026 sieht Rust auf Platz #10, nach #18 ein Jahr zuvor, und damit vor Platz #13, den TIOBE im Januar als höchste Platzierung aller Zeiten bezeichnet hatte.

Meine Einschätzung: Das Plateau war echt. Es war ein Luftloch, keine Obergrenze. Das schlägt die Version beider Lager, denn „Rust stagniert“ ist jetzt falsch, und „Rust geht nur nach oben“ war nie wahr.

Der Vorbehalt gilt in beide Richtungen, und der Bericht von Slashdot hat ihn damals selbst angesprochen: schwanken die Rankings vielleicht einfach nur mit dem monatlichen Rauschen in Suchmaschinenergebnissen, also genau dem, was der Index zählt? Wenn ein Absturz um drei Plätze in einem Quartal ein dünner Beleg dafür war, dass Rust sich verlangsamt, dann ist ein Aufstieg um sechs Plätze ein dünner Beleg dafür, dass es gewinnt. Nimm es als Wetter, nicht als Klima.

Das stärkere Stimmungssignal ist die Umfrage von Stack Overflow, in der Rust erneut die meistbewunderte Programmiersprache des Jahres 2025 ist, mit 72 %: Leute, die sie im vergangenen Jahr genutzt haben und weiter nutzen wollen. Das ist die Absicht, dabeizubleiben, keine Verbreitung, und hier ein nützlicheres Signal als die reine Popularität, wenn du überlegst, ob es dir Spaß machen wird, bei der Sprache zu bleiben.

Die Dynamik ist uneindeutig, und ich gewichte sie niedriger als die Beständigkeit oben, denn du investierst nicht in ein Ranking.

Was es dich kostet, Rust zu lernen

Die Kosten fallen früh und auf einen Schlag an. Code, den Python, Java oder C# problemlos ausführen würden, wird immer wieder abgelehnt, aus Gründen, die willkürlich wirken, bis das Ownership-Modell klickt, und das lässt sich nicht aufschieben. Am Borrow Checker kannst du dich nicht vorbeiliefern, so wie du dich daran vorbeiliefern kannst, dein ORM nicht ganz zu verstehen.

Hier kommt der Teil, der mich überrascht hat, und er läuft umgekehrt zu dem, was man erwarten würde. Im r/rust-Thread „Struggling to learn Rust“ deutet die Antwort mit der meisten Resonanz das Problem als Ungewohntheit statt als Schwierigkeit, und der Thread zeigt auf erfahrene Entwickler, die von Sprachen mit Garbage Collector kommen, als diejenigen, die es schwerer haben. u/Voxelman bringt es auf den Punkt: „Rust ist nicht schwierig. Es ist anders.“ Im selben Thread schildert der Nutzer seinen eigenen Einstieg: C64 Basic, dann eine Reihe imperativer Sprachen und ein erster Kontakt mit Rust, der „alles andere als WOW“ war, weil das Ablegen der alten Gewohnheiten eine Weile dauerte.

So sieht die Rechnung aus. Wenn du seit acht Jahren Python schreibst, lernst du kein Regelwerk, sondern gibst eine Reihe von Annahmen darüber auf, wer hinter dir aufräumt. Wer weniger weiß, muss weniger verlernen.

Ein weiteres Muster taucht in diesem Thread immer wieder auf, und es macht aus einem Fehler in der Reihenfolge ein Problem mit dem Selbstvertrauen: Leute bleiben nicht an Rust hängen, sondern an der Wahl eines Web-Frameworks, weil sie versuchen, die Sprache über Axum oder Actix zu lernen, bevor Ownership sitzt. Wie u/jmartin2683 es formulierte, ist das „als würde man Ruby lernen, indem man Rails lernt.“

Die meisten Warnungen vor den Kosten zielen für mich auf das Falsche. Plane dauerhafte Übung ein, nicht ein Wochenende, und werte frühen Frust nicht als Urteil über deine Fähigkeiten.

Rust braucht zum Bauen eine größere Maschine als zum Laufen

Hier ist das Ergebnis, mit dem ich nicht gerechnet hatte: Das Bauen dieses Rust-Projekts brauchte um Größenordnungen mehr Speicher als das Ausführen. Ich habe einen kleinen Axum-Service geschrieben (Tokio mit full als Feature-Set, serde, serde_json, tower, eine JSON-Route, rund 60 Crates im Abhängigkeitsbaum), mit rustc und cargo 1.98.1 und strip = true im Release-Profil, und ihn dann zweimal von Grund auf neu gebaut:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

Begrenzt auf einen Compile-Job (--jobs 1), lag der Spitzenspeicher über cargo, rustc und den Linker hinweg zwischen 464 MB und 527 MB, je nachdem, welche meiner beiden Messmethoden du nimmst (ich habe auf zwei Arten gemessen, weil mir die erste Zahl zu glatt vorkam), und es dauerte 113 Sekunden. Mit Standard-Parallelität auf vier vCPUs verdoppelte sich der Spitzenspeicher ungefähr auf etwa 1 GB, und der Build war nach etwa 35 Sekunden fertig. Die Variable ist dabei die Parallelität, nicht das Projekt. Mehr Jobs bedeuten mehr rustc-Prozesse gleichzeitig im Speicher, weshalb Compiler zu den wenigen Workloads gehören, die sich gern jeden Kern nehmen, den du ihnen gibst und das minutenlang am Stück.

Das fertige Programm ist gestrippt 1,3 MB groß und belegt im Leerlauf rund 3,3 bis 3,6 MB Speicher.

Bei Standard-Parallelität ist das zwei- bis dreihundertmal mehr Speicher fürs Kompilieren als fürs Ausführen; auf einen Job begrenzt ist es immer noch deutlich mehr als das Hundertfache. Dimensionierst du einen Server nach dem, was dein Rust-Service in Produktion braucht, hast du am Ende womöglich eine Kiste, die ihn nicht bauen kann, und das Fehlerbild ist kein sauberer Fehler: Es ist der OOM-Killer, der rustc mitten im Build abschießt, oder ein Compiler, der zwanzig Minuten lang im Swap rödelt. Zwei Lösungen funktionieren. Bau irgendwo mit Reserven und liefere das Binary aus, nach demselben Muster wie beim Betrieb einer separaten Build-Maschine für aufwendige Docker-Arbeit. Oder bau auf der Kiste selbst und gib ihr Luft: Für einen Service dieser Art sind ein paar Gigabyte RAM und zwei vCPUs bequem. Wenn nicht, ist die Notluke --jobs 1 (ja, das ist langsamer; das ist der Kompromiss).

Wenn die Maschine, an der du arbeitest, diese Reserven nicht hat, gibt dir unser selbstverwalteter Linux-VPS Root-Zugriff mit stündlicher oder monatlicher Abrechnung und einen Ort, an dem du den Build erledigen und danach wieder abgeben kannst. Es bleibt aber ein Server, den du selbst betreibst, und keiner, der sich selbst betreibt.

Ein Projekt, eine Form, eine Maschine. Die Maschine war ein geteilter, abgeschotteter Container, kein dedizierter Server, mit rund 2 GB verfügbarem Speicher, sodass die unbegrenzte Spitze näher an ihrer Obergrenze lief, als sie es auf einer größeren Kiste täte. Das sind keine universellen Konstanten: Wenn dein Abhängigkeitsbaum viermal so groß ist oder dein Release-Profil Link-Time-Optimization einschaltet, rechne mit anderen Zahlen. Größere Abhängigkeitsbäume, Link-Time-Optimization und Code mit vielen Generics können den Speicherbedarf beim Bauen weiter erhöhen, also betrachte meine Messungen nicht als allgemeine Obergrenze.

Ich verbuche das unter der Frage, wie du arbeitest, nicht ob du die Sprache lernst. Wisse davon, bevor du darauf stößt.

Wer Rust lernen sollte

Drei Situationen, in denen ich dir raten würde, die Zeit zu investieren: langlebige Software, bei der ein Speicherfehler teuer ist, Arbeit nah am Betriebssystem und der Wunsch nach dem, was der Kampf mit dem Compiler mit deinem Denken über Speicher macht. Für jede gibt es einen Grund, warum sich die Zeit auszahlt.

Du lieferst schon in einer anderen Sprache aus und baust etwas Langlebiges, bei dem ein Speicherfehler teuer wäre. Ein Service, der laufen muss. Eine Bibliothek, von der andere Teams abhängen. Alles, wo ein Use-after-free einen Incident-Review bedeutet und nicht einen Stacktrace in deinem Terminal. Genau für diesen Fall wurde die ganze Garantie gebaut, und was du vorab zahlst, amortisiert sich über die Lebensdauer dessen, was du baust.

Du arbeitest nah an oder mitten in Systemsoftware. Treiber, Gerätearbeit, Basis-System-Tools, Embedded, alles, was unter einem Betriebssystem sitzt statt darauf. Die Branche hat sich hier so festgelegt wie sonst nirgends, und die Belege zur Speichersicherheit sind hier am stärksten.

Du willst den Nebeneffekt. Zwei Kommentatoren in diesem r/rust-Thread sind sich über den Karrierewert von Rust völlig uneinig und landen hier trotzdem am selben Punkt. u/tyler_church, der sagt, es habe null Einfluss auf seine Karriere gehabt, räumt trotzdem „vielleicht subtile Einflüsse darauf, wie ich andere Programme in anderen Sprachen schreibe“ ein. u/SirKastic23, seit zwei Jahren fürs Rust-Schreiben bezahlt, sagt, es habe die eigenen Programmierfähigkeiten auf nie erwartete Weise erweitert. Zwei Menschen, keine Studie, aber es ist der Gewinn, der auch dann bleibt, wenn du nie beruflich Rust schreibst: eine Veränderung in deinem Denken, keine Zeile im Lebenslauf.

Wer Rust nicht lernen sollte

Drei Situationen, in denen die Zeit woanders besser investiert ist: Du hast diesen Monat eine Deadline, du lernst überhaupt erst programmieren, oder du wählst eine Sprache danach aus, wie viele Stellenanzeigen sie erwähnen. Nach der dritten wird am häufigsten gefragt.

Du hast diesen Monat eine Deadline für eine CRUD-App oder einen Prototyp. Rust kommt genau im falschen Takt für Arbeit, die bis Freitag stehen muss. Go ist die naheliegende Alternative, wenn du eine kompilierte Sprache mit schnellen Builds und Speicherverwaltung per Garbage Collector willst und die Ownership-basierten Garantien von Rust nicht brauchst.

Du lernst überhaupt erst programmieren. Diese Frage spaltet tatsächlich Leute, die beruflich Rust schreiben, und die Uneinigkeit in den r/rust-Threads geht in beide Richtungen. Meine Position ist daher: Einem Anfänger einen Münzwurf in die Hand zu drücken, ist ein schlechter Rat, egal auf welche Seite die Münze fällt. Lern zuerst irgendwo, das nachsichtiger ist, wie eine Maschine funktioniert, und komm dann zurück und lass den Compiler die Schrauben anziehen.

Du wählst eine Sprache danach aus, wie viele Stellenanzeigen sie erwähnen. Ich nenne dir hier keine Zahl, weil ich für Rust keine Gehalts- oder Stellenzahl gefunden habe, die sich auf eine Quelle zurückführen lässt, die ich verteidigen würde. Was u/crusoe in diesem r/rust-Thread beschreibt, ist ein Markt mit weniger, dafür spezialisierteren Stellen. Das ist ein Kommentator in einem Thread, keine Arbeitsmarktdaten, also würde ich daraus nicht ableiten, dass Rust-Jobs allgemein knapp sind. Wenn die Zahl der Jobs für dich den Ausschlag gibt, prüf die aktuellen Stellenanzeigen in deinem Zielmarkt, bevor du dich für die Sprache entscheidest.

Häufig gestellte Fragen