Lohnt sich Rust für euer Team?
Die Frage lässt sich beantworten, wenn beide Seiten auf dem Tisch liegen: der messbare Nutzen im Betrieb und die Kosten für Einarbeitung, Bauzeit und Nachbesetzung.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Debatte wird meist ohne die Kostenseite geführt
Der Vorschlag kommt aus dem Team und wird technisch begründet: keine Speicherfehler, keine Datenrennen, ein Werkzeugkasten, der ohne Zusammenbau funktioniert. Alles davon stimmt. Die Runde, die darüber entscheidet, hört aber eine andere Frage, nämlich was es kostet und was passiert, wenn es nicht funktioniert. Solange die Antwort darauf fehlt, wird die Diskussion zu einer Auseinandersetzung über Geschmack, und die endet regelmäßig damit, dass alles bleibt, wie es ist.
Die Gegenseite argumentiert genauso einseitig. Die steile Lernkurve wird als Ausschlussgrund genannt, ohne dass jemand nachsieht, was darüber tatsächlich erhoben wurde. Die Bewerberlage wird als dünn beschrieben, ohne die Kehrseite zu betrachten. Und die langen Übersetzungszeiten stehen im Raum, ohne dass jemand prüft, ob sie mit einer halben Stunde Konfiguration auf ein erträgliches Maß fallen.
Am teuersten ist die Entscheidung, die nie ausdrücklich getroffen wird. Ein Team fängt nebenbei mit einem kleinen Dienst an, das Ding läuft, wächst über zwei Jahre, und irgendwann hängt ein Produktionssystem an einer Sprache, die nur eine Person im Haus beherrscht. Das ist nicht die Schuld der Sprache. Es ist die Folge davon, dass Zuständigkeit, Qualifizierung und Nachbesetzung nie jemand entschieden hat.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet, wer setzt um
Eine Sprachentscheidung fällt selten an einer Stelle. Diese fünf Zeilen benennen die Punkte, an denen in der Praxis Zuständigkeiten auseinanderlaufen, und die Falle, die dann jeweils entsteht.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Sprachwahl für eine neue Komponente | Die Architektur zusammen mit der Person, die den Betrieb der Komponente verantwortet | Das Team, das die Komponente danach pflegt, und nicht ein Sonderteam für die Einführung | Entschieden wird von Leuten, die den Code nicht warten, und die Wartung landet bei einem Team, das nicht gefragt wurde. |
| Pilotprojekt und seine Bewertung | Die Bereichsleitung, weil sie die Zeit für einen möglichen Abbruch mitfreigeben muss | Eine kleine Gruppe von zwei bis drei Personen mit ausgewiesener Zeit im Plan | Der Pilot läuft nebenher ohne feste Zeit, zieht sich über Monate und wird am Ende nicht bewertet, sondern nur vergessen. |
| Qualifizierung und Nachbesetzung | Teamleitung und Personalabteilung gemeinsam, weil beide Seiten der Rechnung dort liegen | Das Team, mit Lernzeit im Plan statt am Abend, und mit mindestens zwei Personen je Bereich | Gerechnet wird mit der Einarbeitung, nicht damit, dass eine Nachbesetzung in zwei Jahren eine andere Bewerberlage vorfindet. |
| Bau- und Auslieferungsinfrastruktur | Der Bereich, der die Pipeline betreibt, gemeinsam mit dem Team | Plattform- oder Betriebsteam, mit Zwischenspeicher für Abhängigkeiten und Zielverzeichnis und einem schnellen Linker | Die Übersetzungszeiten fallen erst auf, wenn jeder Pull Request minutenlang wartet, und gelten dann rückwirkend als Argument gegen die Sprache. |
| Anforderungen aus Sicherheit und Zulassung | Die Sicherheits- oder Qualitätsabteilung, nicht das Entwicklungsteam | Das Team, mit einer qualifizierten Werkzeugkette und den zugehörigen Nachweisen | Eine qualifizierte Werkzeugkette wird mit einer Zulassung des Produkts verwechselt, und die Lücke fällt erst im Audit auf. |
Sprachwahl für eine neue Komponente
- Wer entscheidet
- Die Architektur zusammen mit der Person, die den Betrieb der Komponente verantwortet
- Wer setzt um
- Das Team, das die Komponente danach pflegt, und nicht ein Sonderteam für die Einführung
- Stolperfalle
- Entschieden wird von Leuten, die den Code nicht warten, und die Wartung landet bei einem Team, das nicht gefragt wurde.
Pilotprojekt und seine Bewertung
- Wer entscheidet
- Die Bereichsleitung, weil sie die Zeit für einen möglichen Abbruch mitfreigeben muss
- Wer setzt um
- Eine kleine Gruppe von zwei bis drei Personen mit ausgewiesener Zeit im Plan
- Stolperfalle
- Der Pilot läuft nebenher ohne feste Zeit, zieht sich über Monate und wird am Ende nicht bewertet, sondern nur vergessen.
Qualifizierung und Nachbesetzung
- Wer entscheidet
- Teamleitung und Personalabteilung gemeinsam, weil beide Seiten der Rechnung dort liegen
- Wer setzt um
- Das Team, mit Lernzeit im Plan statt am Abend, und mit mindestens zwei Personen je Bereich
- Stolperfalle
- Gerechnet wird mit der Einarbeitung, nicht damit, dass eine Nachbesetzung in zwei Jahren eine andere Bewerberlage vorfindet.
Bau- und Auslieferungsinfrastruktur
- Wer entscheidet
- Der Bereich, der die Pipeline betreibt, gemeinsam mit dem Team
- Wer setzt um
- Plattform- oder Betriebsteam, mit Zwischenspeicher für Abhängigkeiten und Zielverzeichnis und einem schnellen Linker
- Stolperfalle
- Die Übersetzungszeiten fallen erst auf, wenn jeder Pull Request minutenlang wartet, und gelten dann rückwirkend als Argument gegen die Sprache.
Anforderungen aus Sicherheit und Zulassung
- Wer entscheidet
- Die Sicherheits- oder Qualitätsabteilung, nicht das Entwicklungsteam
- Wer setzt um
- Das Team, mit einer qualifizierten Werkzeugkette und den zugehörigen Nachweisen
- Stolperfalle
- Eine qualifizierte Werkzeugkette wird mit einer Zulassung des Produkts verwechselt, und die Lücke fällt erst im Audit auf.
Sechs Merkmale von Vorhaben, bei denen sich Rust trägt
- 01 Die Software läuft über Jahre und wird in dieser Zeit gepflegt.
- 02 Ausgeliefert wird in hoher Stückzahl, oder es laufen viele Instanzen davon.
- 03 Speicherfehler hätten sicherheitsrelevante oder haftungsrelevante Folgen.
- 04 Die Rechenzeit im Betrieb ist ein Kostenposten, den jemand bezahlt.
- 05 Das Speicherbudget je Instanz ist eng und soll gleichmäßig bleiben.
- 06 Es gibt mehr als eine Person, die den Code danach pflegen kann.
Danach steht die Entscheidung auf Kriterien, die auch andere nachvollziehen
Es geht nicht darum, Rust zu befürworten oder abzulehnen, sondern darum, die Frage auf den Projekttyp herunterzubrechen, die Kosten offen zu benennen und einen Piloten so zuzuschneiden, dass sein Ergebnis etwas bedeutet. Das lässt sich in einer Runde von zwei Stunden vorbereiten.
Den Projekttyp einordnen
Du erkennst an Laufzeit, Stückzahl, Sicherheitsanforderung und Betriebskosten, ob euer Vorhaben zu den Fällen gehört, bei denen sich die Investition trägt.
Die Kostenseite belegen statt schätzen
Du kennst die erhobenen Zahlen zur Einarbeitungszeit und kannst sie ins Verhältnis zu eurer eigenen Lage setzen, statt über Eindrücke zu diskutieren.
Übersetzungszeiten einordnen
Du weißt, welcher Teil davon Konfiguration ist und welcher bleibt, und kannst sagen, was ein schneller Linker, eine Aufteilung in Crates und ein Zwischenspeicher in der Pipeline bringen.
Die Bibliothekslage ehrlich prüfen
Du prüfst vor der Entscheidung, ob es für eure konkreten Schnittstellen und Herstellerpakete etwas gibt, statt vom allgemeinen Zustand des Ökosystems auszugehen.
Zuständigkeiten benennen
Du klärst vorher, wer die Sprachwahl trägt, wer den Code pflegt und wer nachbesetzt, damit daraus kein Projekt wird, das an einer einzigen Person hängt.
Einen Piloten mit Ausstieg zuschneiden
Du legst Umfang, Dauer, Zielgröße und Abbruchkriterien vorher fest, sodass am Ende eine Auswertung steht und nicht eine Meinung.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wo sich die Investition trägt
Sechs Merkmale kommen bei den Vorhaben zusammen, bei denen sich der Aufwand rechnet. Die Software läuft lange, wird also über Jahre gepflegt und nicht nach einem Quartal ersetzt. Sie geht in hoher Stückzahl hinaus oder läuft in vielen Instanzen, sodass Speicherbedarf und Rechenzeit je Einheit multipliziert werden. Das Speicherbudget je Instanz ist eng und soll gleichmäßig bleiben. Ein Speicherfehler hätte spürbare Folgen, weil das Gerät im Feld steht, weil Daten Dritter betroffen wären oder weil eine Zulassung daran hängt. Die Rechenzeit im Betrieb ist ein Posten, den jemand bezahlt. Und es gibt mehr als eine Person, die den Code danach pflegen kann.
Für den Sicherheitsteil dieser Rechnung gibt es inzwischen belastbare Zahlen aus einem großen Bestand. Google berichtet für Android, dass der Anteil der Schwachstellen mit Speicherbezug von 76 Prozent im Jahr 2019 auf 24 Prozent im Jahr 2024 gefallen ist, und führt das darauf zurück, dass neuer Code in speichersicheren Sprachen entsteht, während der alte C- und C++-Bestand größtenteils unangetastet liegen bleibt. Das ist die Aussage, die für eine Entscheidungsrunde zählt: Der Gewinn stellt sich beim neuen Code ein, ohne dass der Bestand angefasst werden muss.
Aus derselben Richtung kommt eine zweite Beobachtung, die weniger mit Sicherheit und mehr mit Qualität zu tun hat: Das Android-Team berichtet, dass Änderungen in Rust seltener wieder zurückgenommen werden mussten als Änderungen in C++. Rücknahmen sind ein guter Näherungswert für Fehler, die durch alle Prüfungen gekommen sind, und das spricht in einer Budgetrunde deutlicher als jede Aussage über das Typsystem. In regulierten Feldern kommt ein Punkt dazu, der Diskussionen abkürzt: Es gibt mit Ferrocene eine von TÜV SÜD qualifizierte Rust-Werkzeugkette mit Nachweisen für ISO 26262 bis ASIL D, IEC 61508 bis SIL 3 und IEC 62304 bis Klasse C. Damit ist die Frage, ob der Compiler für einen solchen Einsatz überhaupt in Betracht kommt, nicht mehr offen. Was sie ausdrücklich nicht ist: eine Zulassung eures Produkts.
Wo sie sich nicht trägt
Kurzlebige Prototypen gehören nicht dazu. Wenn der Zweck darin besteht, in zwei Wochen eine Frage zu beantworten und den Code danach wegzuwerfen, zahlt ihr die Einarbeitung ohne die Laufzeit, über die sie sich amortisiert. Dasselbe gilt für kleine Hilfsskripte und für Verbindungslogik, die im Wesentlichen fremde Dienste aneinanderreiht: Dort entsteht der Aufwand an den Schnittstellen, und die Sprache trägt fast nichts bei.
Der zweite Fall sind stark wandernde Anforderungen. Rust belohnt es, wenn die Datenstrukturen einer Anwendung durchdacht sind, und bestraft es, wenn sie sich wöchentlich ändern, weil jede Änderung an der Eigentumsstruktur durch den Code wandert. In einer frühen Produktphase mit offenem Zuschnitt ist eine Sprache, die schnelle Umbauten verzeiht, die vernünftigere Wahl, und ein Wechsel bleibt möglich, sobald der Zuschnitt steht.
Der dritte Fall ist die Bibliothekslage, und die prüft ihr konkret statt allgemein. Für Netzdienste, Datenverarbeitung, Kryptografie und hardwarenahe Entwicklung ist reichlich vorhanden. Dünn wird es bei Oberflächen, wo es keine gesetzte Lösung gibt, und bei Herstellerpaketen für spezielle Geräte oder Fachanwendungen, die häufig nur für C, C++, Java oder .NET ausgeliefert werden. Die Frage lautet also nicht, wie das Ökosystem dasteht, sondern ob es für eure drei konkreten Schnittstellen etwas Gepflegtes gibt. Diese Prüfung dauert einen halben Tag und ersetzt eine Grundsatzdebatte.
Die Kostenseite, offen gerechnet
Zur Einarbeitung gibt es eine Erhebung, die groß genug ist, um etwas zu bedeuten. Google hat über tausend eigene Entwicklerinnen und Entwickler befragt, die Rust-Code beigesteuert haben. Mehr als zwei Drittel gaben an, sich innerhalb von zwei Monaten oder weniger sicher genug zu fühlen, um zu einer Rust-Codebasis beizutragen. Ein Drittel erreichte in derselben Zeit dieselbe Geschwindigkeit wie in den Sprachen, die sie vorher genutzt hatten, nach vier Monaten war es über die Hälfte. 85 Prozent gaben an, ihrem Rust-Code eher zu vertrauen als Code in anderen Sprachen. Zwei Einschränkungen gehören in dieselbe Folie: Die Zahlen stammen von einem Unternehmen, das Rust selbst vorantreibt, und sie beschreiben Leute, die den Wechsel bereits vollzogen haben, nicht die, die aufgegeben haben. Als Größenordnung taugen sie trotzdem: Kalkuliert ein Quartal, in dem das Team langsamer ist, nicht ein Jahr.
Die Übersetzungszeiten sind real und werden gleichzeitig überschätzt. Beim Schreiben zählt nicht der vollständige Build, sondern die Prüfung ohne Codeerzeugung, und die ist schnell genug für den Rhythmus in der Entwicklungsumgebung. Was tatsächlich dauert, ist der optimierte Build mit Linkzeit-Optimierung, und der gehört in die Pipeline. Vier Maßnahmen holen den größten Teil zurück: ein schneller Linker, die Aufteilung großer Crates in kleinere, damit nicht alles gemeinsam neu übersetzt wird, ein Zwischenspeicher für Abhängigkeiten und Zielverzeichnis in der Pipeline, und ein Testläufer, der die Tests parallel ausführt. Wer diese halbe Stunde nicht investiert, bekommt genau das Argument zurück, das später gegen die Sprache verwendet wird.
Der dritte Kostenpunkt wird selten genannt und ist der sicherste. Der Code der ersten Monate wird zum Teil noch einmal geschrieben. Ein Team, das die Eigentumsregeln noch nicht verinnerlicht hat, umgeht sie mit Kopien, Referenzzählern und geteilten Sperren, und das Ergebnis ist unnötig kompliziert. Das ist kein Fehler, sondern der übliche Verlauf, und es hilft, ihn vorher als Posten zu benennen: Rechnet damit, dass der erste größere Baustein nach einem halben Jahr überarbeitet wird, und plant die Zeit dafür ein, statt sie später als Rückschlag zu verbuchen.
Die Personalfrage in beide Richtungen
Der offensichtliche Teil stimmt: Es gibt weniger Leute mit mehrjähriger Rust-Erfahrung als mit Java- oder C-Erfahrung, und in einer Ausschreibung merkt ihr das. Ebenso stimmt, dass eine Nachbesetzung länger dauern kann, und das ist bei einem System mit zehn Jahren Laufzeit ein Punkt, der auf den Tisch gehört.
Die andere Richtung wird dabei fast immer übersehen. Der schnellere Weg zu Rust-Leuten führt in den meisten Häusern nicht über den Arbeitsmarkt, sondern über die eigenen C- und C++-Entwicklerinnen und -Entwickler. Die bringen genau das mit, was den Einstieg leicht macht: ein Bild davon, was im Speicher passiert. Sie stolpern über andere Dinge als Leute aus der Java- oder Python-Welt, aber sie stolpern kürzer. Wer den Wechsel plant, plant deshalb zuerst Qualifizierung und danach Einstellungen.
Der Punkt, der die Entscheidung wirklich trägt, ist unabhängig von der Sprache: Es darf nie eine einzelne Person sein. Ein Dienst, den eine Person geschrieben hat und den sonst niemand anfasst, ist ein Risiko in jeder Sprache, in einer neu eingeführten aber ein doppeltes, weil im Zweifel niemand einspringen kann. Zwei Personen je Bereich sind die Untergrenze, und diese Zahl gehört in die Freigabe des Piloten und nicht in eine spätere Nachbetrachtung.
Der Pilot: Zuschnitt und Abbruchkriterien
Ein Pilot, der etwas beweisen soll, hat vier feste Größen. Umfang: genau eine Komponente mit klarer Schnittstelle, keine Neuschreibung. Dauer: sechs bis zehn Wochen, danach wird ausgewertet, egal wie weit es ist. Besetzung: zwei bis drei Personen mit ausgewiesener Zeit, nicht nebenher. Zielgröße: eine Zahl, die vorher gemessen wurde und hinterher wieder gemessen wird, also Laufzeit, Speicherbedarf, Fehlerrate oder Zahl der Vorfälle in diesem Bereich.
Die Abbruchkriterien schreibt ihr vor dem Start auf, weil sie danach niemand mehr formuliert. Sinnvolle Formulierungen sind konkret: Wenn die Zielgröße nach der vereinbarten Zeit nicht um den vereinbarten Betrag besser ist, wird zurückgebaut. Wenn die Bauzeit in der Pipeline eine bestimmte Grenze überschreitet und sich nicht mit vertretbarem Aufwand drücken lässt, wird zurückgebaut. Wenn sich für eine notwendige Schnittstelle nichts Gepflegtes findet und der Eigenbau mehr als eine bestimmte Zeit kosten würde, wird zurückgebaut. Ein Abbruch nach diesen Regeln ist kein Scheitern, sondern die Auszahlung der Versicherung, für die ihr den Piloten klein gehalten habt.
Und dann die Auswertung, bei der die meisten die falsche Frage stellen. Ob es funktioniert hat, ist selten strittig, denn es funktioniert fast immer. Die nützlichen Fragen sind andere: Wie lange hat es gedauert, bis die Code-Durchsichten im Team nicht mehr mühsam waren? Wie hat sich die Bauzeit über den Zeitraum entwickelt? Wie oft musste jemand von außen helfen? Und würde dieselbe Gruppe es beim nächsten Mal wieder so machen? Diese vier Antworten sagen mehr über die nächsten fünf Jahre als jede Messung des Piloten selbst.
Dazu passende Kurse
Weil sich die Einarbeitungszeit deutlich verkürzt, wenn alle dieselbe Grundlage haben, lohnt es sich, vor dem Piloten einen gemeinsamen Rust-Kurs für euer Team einzuplanen.
Der vorhandene C-Code verschwindet durch die Entscheidung nicht, und wer ihn weiter pflegen muss, findet dafür C-Kurse für den Bestand, der bleiben soll .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr angenehmes, gut vorbereitetes Seminar, kann ich nur empfehlen.
Häufige Fragen
Wie lange braucht ein erfahrenes Team, bis es in Rust produktiv ist?
Sind die langen Übersetzungszeiten ein Ausschlussgrund?
Müssen wir bestehenden C- oder C++-Code ablösen, damit es sich rechnet?
Was tun wir, wenn es für eine wichtige Schnittstelle keine Rust-Bibliothek gibt?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Rust-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Entscheidung fällt leichter, wenn das Team die Sprache schon einmal benutzt hat
Ein gemeinsamer Einstieg vor dem Piloten spart die ersten Wochen, in denen sonst jede Person dieselben Umwege noch einmal geht, und cmt richtet ihn auf euren Bestand aus.