Einführung in Rust – Was steckt wirklich hinter dem Hype?

Bei den anderen Sprachen in dieser Reihe musste ich gegen Vorurteile anschreiben: PHP sei tot, Java verstaubt, C# nur Windows.

Bei Rust ist es umgekehrt.

Rust wird seit Jahren in Umfragen zur „most loved language“ gewählt, auf jeder Konferenz gefeiert und in jedem zweiten Kommentarbereich als Antwort auf alles empfohlen. Wer da skeptisch wird, hat gesunde Instinkte.

Also: ehrlicher Blick. Was kann Rust wirklich – und wofür ist der Hype fehl am Platz?

Was ist Rust überhaupt?

Rust ist eine kompilierte Systemsprache, die ein Versprechen macht, das lange als unmöglich galt:

Die Performance und Kontrolle von C – ohne dessen Speicherfehler. Und ohne Garbage Collector.

Der Trick heißt Ownership: Jeder Wert hat genau einen Besitzer, und der Compiler prüft zur Compile-Zeit, wer wann auf was zugreifen darf. Use-after-free, Buffer Overflows, Data Races – die Fehlerklassen, die C und C++ seit Jahrzehnten plagen, werden nicht zur Laufzeit gefangen, sondern kompilieren gar nicht erst.

Klassisches Beispiel:

fn main() {
    println!("Hallo Welt!");
}

Und das Ownership-Prinzip in drei Zeilen:

let name = String::from("Marcel");
let anderer = name;          // Besitz wandert zu `anderer`
// println!("{}", name);     // Compilerfehler: name gehört niemandem mehr

Das fühlt sich am Anfang an wie Schikane. Es ist aber genau der Mechanismus, der die Speicherfehler unmöglich macht.

Die Begriffe hinter dem Versprechen

In jeder Rust-Diskussion fallen dieselben vier Begriffe: Ownership, Borrow-Checker, Lifetimes – und die „Fehlerklassen“, die dadurch verschwinden sollen. Einmal kurz erklärt, dann liest sich der Rest des Artikels von selbst.

Ownership – jeder Wert hat genau einen Besitzer

Ownership ist die Grundregel, auf der alles andere aufbaut:

1. Jeder Wert hat genau einen Besitzer (eine Variable).
2. Weist man den Wert einer anderen Variable zu oder übergibt ihn an eine Funktion, wandert der Besitz – die alte Variable ist danach ungültig (genau das zeigt das Beispiel oben).
3. Verlässt der Besitzer den Gültigkeitsbereich, wird der Speicher automatisch freigegeben.

Das ist der Ersatz für den Garbage Collector: Der Compiler weiß zu jedem Zeitpunkt, wem ein Wert gehört – also weiß er auch, wann er weg kann. Kein free() von Hand wie in C, kein GC, der zur Laufzeit pausiert.

Borrowing und der Borrow-Checker

Würde der Besitz bei jeder Verwendung wandern, könnte man kaum programmieren. Deshalb kann man sich Werte ausleihen (Borrowing), über Referenzen. Dafür gilt eine einzige, eiserne Regel:

Beliebig viele lesende Ausleihen – oder genau eine schreibende. Nie beides gleichzeitig.

Der Borrow-Checker ist der Teil des Compilers, der diese Regel durchsetzt:

let mut liste = vec![1, 2, 3];
let erster = &liste[0];   // lesende Ausleihe
liste.push(4);            // Compilerfehler: Schreibzugriff, solange `erster` lebt
println!("{}", erster);

Das wirkt pedantisch – ist es aber nicht: push kann die Liste intern im Speicher verschieben, und erster würde dann ins Leere zeigen. In C++ kompiliert genau dieser Code und stürzt irgendwann ab. In Rust kompiliert er gar nicht erst. Wenn vom „Kampf gegen den Borrow Checker“ die Rede ist, ist genau diese Regel gemeint – man verliert den Kampf übrigens nie zu Unrecht.

Lifetimes – wie lange eine Referenz gültig sein darf

Jede Referenz hat eine Lebensdauer (Lifetime): den Zeitraum, in dem der Wert existiert, auf den sie zeigt. Der Compiler prüft, dass keine Referenz ihren Wert überlebt:

let referenz;
{
    let wert = String::from("kurzlebig");
    referenz = &wert;
}                          // `wert` wird hier freigegeben
// println!("{}", referenz); // Compilerfehler: Referenz überlebt den Wert

Meistens leitet der Compiler die Lifetimes selbst her. Nur wenn es mehrdeutig wird – etwa wenn eine Funktion eine von zwei übergebenen Referenzen zurückgibt – muss man ihm mit Annotationen wie 'a auf die Sprünge helfen:

fn laengster<'a>(a: &'a str, b: &'a str) -> &'a str {
    if a.len() > b.len() { a } else { b }
}

Übersetzt heißt das nur: „Das Ergebnis lebt höchstens so lange wie die kürzer lebende der beiden Eingaben.“ Die Syntax schreckt ab, das Konzept dahinter ist genau ein Satz.

Welche Fehlerklassen dadurch verschwinden

Eine Fehlerklasse ist nicht ein einzelner Bug, sondern eine ganze Kategorie von Fehlern mit derselben Ursache. Die drei, die C und C++ seit Jahrzehnten plagen:

• Use-after-free: Speicher wird freigegeben, aber ein Zeiger darauf wird später noch benutzt – man liest oder überschreibt Speicher, der längst jemand anderem gehört. Ownership und Lifetimes machen das unmöglich: Es gibt keinen Zeiger, der seinen Wert überlebt.
• Buffer Overflow: Es wird über das Ende eines Puffers hinaus gelesen oder geschrieben – der Klassiker hinter unzähligen Sicherheitslücken. Rust prüft Array-Zugriffe und kennt keine rohe Zeigerarithmetik im sicheren Teil der Sprache.
• Data Race: Zwei Threads greifen gleichzeitig auf denselben Speicher zu, mindestens einer schreibt, nichts synchronisiert – die Sorte Fehler, die nur jeden hundertsten Lauf auftritt und nicht reproduzierbar ist. Die Borrow-Regel („viele Leser oder ein Schreiber“) gilt auch über Thread-Grenzen, geprüft zur Compile-Zeit.

Das ist der Kern des Rust-Versprechens: Diese Kategorien werden nicht durch Disziplin, Code-Reviews oder Tests vermieden, sondern durch den Compiler ausgeschlossen.

Was am Hype berechtigt ist

Einiges. Und zwar messbar:

• Die Sicherheitsversprechen sind real. Microsoft und Google beziffern seit Jahren ~70 % ihrer schweren Sicherheitslücken auf Speicherfehler – genau die Klasse, die Rust eliminiert. Deshalb ist Rust inzwischen im Linux-Kernel, in Android, in Windows.
• Das Tooling ist erstklassig. Cargo (Build + Paketmanager), rustfmt, clippy – alles eingebaut, alles konsistent. Nach C/C++-Makefile-Archäologie fühlt sich das an wie ein anderes Jahrhundert.
• Die Fehlermeldungen des Compilers sind die besten der Branche. Kein Marketing – der Compiler erklärt, was falsch ist, warum, und schlägt oft die Korrektur vor.
• Kein null. Stattdessen Option<T> – wer „kein Wert“ zurückgeben kann, muss es im Typ zugeben, und der Aufrufer muss damit umgehen.
• Ernsthafte Adoption. AWS, Cloudflare, Discord, Mozilla – das sind keine Spielprojekte.

Was am Hype übertrieben ist

Und jetzt der Teil, der in den Kommentarspalten fehlt.

„Rewrite it in Rust“ ist meistens schlechter Rat. Ein funktionierendes, getestetes System neu zu schreiben, weil die Sprache gerade beliebt ist, hat schon viele Projekte versenkt.

Die Lernkurve ist real und steil. Ownership, Borrowing, Lifetimes – das erste Vierteljahr kämpft man gegen den Borrow Checker. Der Satz „fighting the borrow checker“ existiert nicht ohne Grund. Produktivität sieht anders aus, zumindest anfangs.

Für Web-APIs und Business-Software ist Rust selten die beste Wahl. Die Frameworks (Axum, Actix) sind gut – aber ein CRUD-Backend ist in Laravel, Spring Boot oder ASP.NET in einem Bruchteil der Zeit gebaut, mit größerem Ökosystem und mehr verfügbaren Entwicklern. Der Geschwindigkeitsvorteil von Rust spielt dort schlicht keine Rolle: Der Flaschenhals ist die Datenbank, nicht die Sprache.

Kompilierzeiten. Große Rust-Projekte kompilieren langsam. Das nervt täglich.

Kurz: Rust löst ein spezifisches Problem hervorragend – Systemsoftware ohne Speicherfehler. Es löst nicht das Problem „meine Web-App ist zu langsam“, denn das hat man in der Regel gar nicht.

Wo Rust wirklich glänzt

• Systemprogrammierung: CLIs, Datenbanken, Proxies, Betriebssystem-Komponenten
• Performance-kritische Bibliotheken: Vieles im JS-Tooling (SWC, Turbopack) ist längst Rust
• WebAssembly: Rust ist dort erste Wahl
• Embedded: wachsend, als sichere Alternative zu C
• Alles, was lange läuft und nicht abstürzen darf

Ein Muster fällt auf: Rust glänzt da, wo vorher C oder C++ stand. Genau dafür wurde es gebaut.

Für wen eignet sich Rust heute?

Meiner Meinung nach besonders für:

• Entwickler mit C/C++-Hintergrund, die die Fehlerklassen satt haben
• Tooling-, CLI- und Infrastruktur-Projekte
• Teams mit echten Performance- oder Sicherheitsanforderungen
• Alle, die durch eine anspruchsvolle Sprache besser werden wollen – der Borrow Checker ist ein strenger, aber guter Lehrer

Wer dagegen schnell Business-Anwendungen bauen will, fährt mit den etablierten Web-Stacks besser – und darf das ohne schlechtes Gewissen sagen.

Mein persönlicher Eindruck

Rust ist das seltene Beispiel für Hype mit Substanz – nur zeigt der Hype oft auf das falsche Einsatzgebiet.

Als Ersatz für C/C++ in Systemsoftware: absolut verdient, das ist ein echter Fortschritt für die ganze Branche. Als Universalantwort auf jede Backend-Frage: nein. Eine Sprache, deren Superkraft Speichersicherheit ohne GC ist, spielt diese Superkraft in einer CRUD-API schlicht nicht aus.

Das Schöne ist: Beides kann gleichzeitig wahr sein.