Die Entscheidung für eine neue Programmiersprache fällt selten an technischen Kriterien. Sie fällt an der Frage, ob Ihr Team die Lernkurve will und Ihre Organisation sie finanzieren kann. Wir haben RKA² von Java auf Rust umgestellt und dabei beobachtet, dass gerade erfahrene Java-Entwickler am längsten benötigen. Wir zeigen, welche zwei Bedingungen erfüllt sein müssen – und was passiert, wenn nur eine davon zutrifft.
Ausgangslage: Die Migrationsrechnung wird falsch aufgestellt
Wenn ein Modernisierungsvorhaben geschätzt wird, beginnt die Rechnung fast immer beim Code. Wie viele Module, wie viele Codezeilen, wie viele Schnittstellen? Daraus entsteht eine Zahl, die belastbar wirkt und den entscheidenden Posten nicht enthält.
Der teuerste Teil einer Migration ist nicht das Schreiben des neuen Codes. Es ist die Rekonstruktion des fachlichen Wissens, das im alten Code implizit steckt und nirgendwo dokumentiert ist. Warum eine Prüfung genau an dieser Stelle greift, welcher Sonderfall 2011 aus welchem Grund eingebaut wurde, welche Regel eine Betriebsprüfung überstanden hat.
Diese Rekonstruktion bezahlen Sie unabhängig davon, welche Zielsprache Sie wählen. Sie ist der Grund, warum Modernisierungsbudgets reißen – nicht die Syntax.
Die teuerste Position ist nicht der Code
Portierung, Neumodellierung und Sprachwechsel sind drei Vorhaben
In Budgetdiskussionen werden drei unterschiedliche Vorhaben regelmäßig als eines behandelt. Eine Portierung überführt bestehende Strukturen möglichst unverändert in eine neue Umgebung; der Kostentreiber ist Volumen. Eine Neumodellierung schneidet die Fachlogik neu; der Kostentreiber ist Fachwissen. Ein Sprachwechsel tauscht die technische Basis; der Kostentreiber ist Lernzeit.
Wer alle drei gleichzeitig unternimmt, addiert die Kostentreiber nicht. Er multipliziert das Projektrisiko. Wer nur portiert und dabei die Sprache wechselt, zahlt die Lernkurve und behält seine Fehlerklassen. Denn eine schlecht geschnittene Domäne wird in Rust nicht besser, sondern nur schwerer zu kompilieren.
Daraus folgt die erste Bedingung: Ein Sprachwechsel rechnet sich dort, wo die Fachlogik ohnehin neu modelliert werden muss. Dann steht die teuerste Position bereits im Budget, und die Sprachwahl kostet nur noch den Aufschlag für die Einarbeitung.
Die Sprache bestimmt den Erhaltungswert
Wenn die Neumodellierung die Investition ist, dann entscheidet die Sprache darüber, wie lange deren Ergebnis hält. Genau hier liegt das Argument, das für einen Entscheider zählt – und es ist kein Performance-Argument.
Ein ausdrucksstarkes Typsystem verlagert einen Teil der Architekturkontrolle aus dem Review-Prozess in den Compiler. Reviews kosten Personalzeit, sind vergesslich und degradieren mit jeder Fluktuation im Team. Eine maschinell erzwungene Prüfung tut das nicht.
Der Compiler als Governance-Instrument
Welche Fehlerklassen vor das Deployment wandern
In der Reisekostenabrechnung ist ein Betrag keine beliebige Zahl. Eine Währung ist kein Text. Ein freigegebener Vorgang ist etwas anderes als ein Entwurf, und eine fehlende Angabe ist ein eigener Zustand, kein Sonderfall von „irgendetwas“.
In Rust lassen sich diese Unterschiede direkt im Typsystem abbilden. Ein Vorgang im Zustand Entwurf besitzt schlicht keine Methode zur Buchung. Der Versuch, ihn zu buchen, kompiliert nicht – er wird nicht zur Laufzeit abgefangen, sondern existiert als Programmzustand nicht.
Dasselbe gilt für Fehlerbehandlung. Rust behandelt erwartbare Fehler als reguläres Ergebnis einer Operation, und der Compiler besteht darauf, dass beide Fälle behandelt werden. Damit verschwindet die Klasse von Fehlern, die in großen Java-Anwendungen aus ungeprüften Exceptions entsteht: Fehler, die an der Funktionsschnittstelle nicht sichtbar sind und deshalb übersehen werden.
Für Ihre Governance heißt das: Ein Teil dessen, was heute als Architekturregel in einem Confluence-Dokument steht und im Review geprüft werden muss, wird zur Eigenschaft des Build-Prozesses.
Was Reviews weiterhin leisten müssen
Diese Verlagerung hat klare Grenzen. Kein Typsystem prüft, ob eine steuerliche Regel fachlich richtig abgebildet ist. Keines erzwingt ein Zugriffskonzept, eine Datenminimierung nach DSGVO oder eine saubere Mandantentrennung.
Rust verkleinert die Angriffsfläche und schließt ganze Klassen von Speicher- und Nebenläufigkeitsfehlern aus. Es ersetzt weder Architekturarbeit noch fachliche Reviews. Wer den Compiler als Qualitätssicherung missversteht, tauscht ein Risiko gegen ein anderes.
Die zweite Bedingung: Ihr Team muss es wollen
Die erste Bedingung ist eine Rechnung. Die zweite ist eine Personalfrage, und sie entscheidet häufiger über den Projektausgang.
Rust ist keine leicht zu erlernende Sprache. Das ist keine Warnung an Anfänger, sondern eine Beobachtung, die uns überrascht hat: Gerade erfahrene Entwickler aus der Java- und C#-Welt haben sich bei der Migration sich ungewöhnlich schwergetan.
Der Grund liegt in eingeübten Denkmustern. Wer zwanzig Jahre lang Objektreferenzen frei weitergereicht und die Speicherverwaltung einem Garbage Collector überlassen hat, muss beim Ownership-Modell – der Regel, dass jeder Wert genau einen Eigentümer hat – nichts dazulernen, sondern etwas ablegen
Auch Reflexe aus Framework-getriebener Entwicklung laufen zunächst ins Leere: Vererbungshierarchien und Dependency Injection als universelles Strukturmittel führen in Rust in Sackgassen.
Entwickler ohne diese Prägung kommen erfahrungsgemäß schneller voran. Der Aufwand liegt also nicht in der Menge des Neuen, sondern im Widerstand des Alten. Diese Position gehört als Zeitbudget in den Projektplan, nicht in die Freizeit der Mitarbeiter.
Damit steht die zweite Bedingung: Der Wechsel trägt in Organisationen, die technologisch vornstehen wollen und eine Mannschaft haben, die Lust auf Neues hat. Verordnete Sprachwechsel gegen ein zufriedenes Team scheitern nicht am Compiler, sondern an der Fluktuation.
Fallstudie RKA²: von C++ über Java zu Rust
Der Entscheidungskorridor 2022
RKA und RKA² begleiten Unternehmen seit den 1990er-Jahren bei der Reisekostenabrechnung. Die ursprüngliche Anwendung entstand in C++, 2001 folgte die Migration nach Java – damals die konsequente Wahl für Enterprise-Software.
2022 stand die Neubewertung an, weil Cloud-Betrieb, wachsende Sicherheitsanforderungen und eine ohnehin anstehende Neumodellierung der Fachlogik zusammenfielen.
Geprüft haben wir drei Wege. GraalVM Native Image, eine Ahead-of-Time-Kompilierung für Java, war 2022 mit unseren Anwendungen nicht vollständig kompatibel und schied aus praktischen Gründen aus. Go überzeugte durch Pragmatismus und flache Lernkurve, blieb aber im Typsystem hinter unseren Anforderungen zurück. Den Ausschlag gab die Ausdrucksstärke der Typisierung – bei einer Anwendung, die finanzielle Vorgänge, steuerliche Regeln und unternehmensspezifische Richtlinien verarbeitet, ist das kein Komfortmerkmal.
Allen Beteiligten war dabei bewusst, dass Rust die deutlich schwierigere Sprache ist. Die Entscheidung fiel trotzdem, weil beide Bedingungen erfüllt waren.
Spezifikationsgetriebene Migration mit Testfallabgleich
Der methodische Kern des Projekts ist übertragbar. Wir haben die Fachlichkeit nicht aus dem Code abgeleitet, sondern spezifikationsgetrieben neu beschrieben und anschließend Testfälle automatisiert gegen beide Systeme laufen lassen – den Java-Stand und den entstehenden Rust-Stand.
Jede Abweichung war damit entweder ein Fehler im neuen System oder ein bisher undokumentiertes Verhalten des alten. Beides musste fachlich entschieden werden, nicht technisch. Der Rechenkern wanderte zuerst, die Migration verlief in kontrollierbaren Schritten mit temporärem Parallelbetrieb, und bestehende Integrationen in HR-, Finanz- und Buchhaltungssysteme blieben ohne Bruch.
Die unbequeme Vorbedingung: Dieses Verfahren setzt voraus, dass sich eine belastbare Spezifikation überhaupt herstellen lässt. Wo das Altsystem keine ausreichende Testabdeckung hat und niemand mehr die Fachlogik erklären kann, wird genau dieser Schritt zum eigentlichen Projekt.
Was die Umstellung gebracht hat
Der Ressourcenbedarf im Cloud-Betrieb sank deutlich; gegenüber dem abgelösten Java-Stand messen wir Einsparungen von bis zu 70 Prozent.
Diese Zahl benötigt eine methodische Einordnung, sonst führt sie in die Irre. Verglichen wurde ein neu modelliertes Rust-System mit einem gewachsenen Java-System, das nicht auf GraalVM optimiert war. Der Anteil, der auf die Sprache entfällt, und der Anteil, der aus der Neumodellierung stammt, lassen sich daraus nicht trennen.
Genau das ist der Punkt. Der Effekt entsteht aus der Kombination, nicht aus der Sprache allein. Wer nur die Sprache tauscht, sollte diese Größenordnung nicht erwarten.
Der zweite Effekt ist für regulierte Kunden der wichtigere: Ohne schwergewichtige Laufzeitumgebung läuft dieselbe Codebasis ressourcenschonend in der Cloud, auf einer dedizierten Serverinstanz und in vollständig getrennten Umgebungen. Digitale Souveränität wird damit zur Betriebsentscheidung, nicht zur Architekturfrage.
Umsetzung in der Praxis
Prüfen Sie vor der Budgetfreigabe fünf Kriterien.
- Steht die Neumodellierung ohnehin an? Wenn nein, verschieben Sie den Sprachwechsel. Er wird dadurch nicht teurer, aber sein Nutzen fällt weg.
- Lässt sich eine Spezifikation herstellen? Prüfen Sie die Testabdeckung des Altsystems und die Verfügbarkeit von Fachwissen. Ohne beides beginnt Ihr Projekt mit einer Rekonstruktionsphase, die eigenständig geplant werden muss.
- Will das Team es? Nicht: kann es. Führen Sie ein zeitlich begrenztes Pilotmodul durch, bevor Sie die Zielarchitektur festschreiben.
- Trägt die Organisation eine reduzierte Feature-Geschwindigkeit? Bei unserere Migration, sank die Auslieferungsrate deutlich über mehrere Monate hinweg.
- Ist der Betriebsvorteil budgetwirksam? Ohne Autoscaling, Plattformvielfalt oder Souveränitätsanforderung bleibt die Effizienz ein technisches Detail ohne Wirkung auf Ihre Kostenstelle.
Die Verantwortlichkeiten trennen sich klar: Die Architektur liefert Zielbild und Architecture Decision Records, der Betrieb verantwortet Parallelbetrieb und Observability, die Personalentwicklung verantwortet die Lernzeit als eigene Projektposition.
Grenzen und Risiken
Wir empfehlen Rust derzeit nicht als erste Wahl. Für Microservices – fachlich geschnittene, unabhängig deploybare Dienste – empfehlen wir in den meisten Fällen Go. Java bleibt aufgrund der Breite des verfügbaren Know-hows immer im
Auswahlkorridor, und diese Verfügbarkeit ist ein Betriebsrisikoargument, kein Bequemlichkeitsargument.
Der Personalmarkt ist die härteste Grenze. Wenn Ihre Anwendung fünfzehn Jahre laufen soll, brauchen Sie über diesen Zeitraum Menschen, die sie warten. Diese Rechnung geht in einem Team von acht motivierten Entwicklern anders auf als in einem Konzernbereich mit hoher Fluktuation und externen Zulieferungen.
Hinzu kommen Ökosystemlücken. Bei etablierten Enterprise-Integrationen – Batch-Verarbeitung, gewachsene ORM-Schichten, herstellerspezifische Anbindungen – ist die Java-Landschaft nach wie vor reifer.
Die Richtung stimmt allerdings. Der Thoughtworks Technology Radar führte in Volume 31 vom Oktober 2024 ein eigenes Thema unter dem Titel „Anything but rusty“: Die wachsende Zahl Rust-basierter Werkzeuge und Bibliotheken über verschiedene Ökosysteme hinweg, die schnelle Ausführung sowie das starke Ökosystem und die Entwicklergemeinde festigen die Position der Sprache.
Wir beobachten diese Verbreiterung besonders im Werkzeugbau rund um KI und Large Language Models und erwarten daraus mittelfristig eine deutlich breitere Verfügbarkeit von Knowhow.
Fazit
Ein Sprachwechsel ist keine technische Entscheidung mit personellen Nebenwirkungen. Er ist eine personelle Entscheidung mit technischen Nebenwirkungen. Er trägt dort, wo die Fachlogik ohnehin neu modelliert wird und wo ein Team die Lernkurve nicht erduldet, sondern will.
Die Entscheidung, die Sie morgen treffen können: Prüfen Sie Ihr geplantes Modernisierungsvorhaben auf die erste Bedingung. Enthält es bereits eine Neumodellierung der Fachlogik, ist die Diskussion über die Zielsprache sinnvoll. Enthält es sie nicht, führen Sie die Diskussion zu früh – und jede Antwort darauf wird teuer.