Rust, Go und Kotlin: welche Sprache wofür

Artikel-Übersicht

Dieser Artikel ist bewusst kein Tutorial. Für Rust gibt es ein vollständiges, kostenloses und übersetztes offizielles Buch, für Go eine hervorragende interaktive Einführung, für Kotlin eine sehr gute Dokumentation — ein deutschsprachiges Duplikat davon hülfe niemandem. Was fehlt, ist etwas anderes: die Einordnung. Welches Problem löst jede dieser Sprachen tatsächlich, lohnt sich der Einstieg für jemanden, der Java kann, und was kostet eine zweite Sprache im Team? Genau das behandelt dieser Text. Mit Java als Bezugspunkt, einer Vergleichstabelle, je einem Abschnitt pro Sprache und einer Entscheidungshilfe nach Ausgangslage. Der wichtigste Abschnitt ist der zu den Teamkosten — er ist der Grund, warum es diesen Artikel gibt.

Die drei im Überblick

	Java	Rust	Go	Kotlin
Kernproblem	portable Unternehmensanwendungen	Sicherheit ohne Laufzeitkosten	Einfachheit und schnelle Übersetzung	Java ohne die Umstände
Speicherverwaltung	Speicherbereinigung	Eigentümerschaft, keine Bereinigung	Speicherbereinigung	Speicherbereinigung (JVM)
Nebenläufigkeit	Threads, virtuelle Threads	Threads, async	Goroutinen und Kanäle	Koroutinen
Einstiegshürde	mittel	hoch	gering	gering für Java-Kundige
Typischer Einsatz	Unternehmen, Android, Daten	systemnah, Werkzeuge, WebAssembly	Infrastruktur, Netzdienste	Android, JVM-Anwendungen
Ökosystem	sehr groß, sehr reif	wachsend, gut kuratiert	groß im Infrastrukturbereich	JVM-Ökosystem vollständig nutzbar
Läuft auf	JVM	nativ	nativ, ein Binärprogramm	JVM, auch nativ und im Browser

Rust: Sicherheit ohne Laufzeitkosten

Rust garantiert Speichersicherheit zur Übersetzungszeit statt über eine Speicherbereinigung — der Preis ist eine steile Lernkurve.

Das Verfahren dahinter heißt Eigentümerschaft: Jeder Wert hat genau einen Eigentümer; wenn dieser den Gültigkeitsbereich verlässt, wird der Speicher freigegeben. Referenzen auf einen Wert werden „geliehen", und der Übersetzer prüft, dass keine Referenz den Wert überlebt und dass nicht gleichzeitig gelesen und geschrieben wird.

Daraus folgt: keine Speicherbereinigung, keine Pausen, keine Nullzeiger — und keine Wettlaufsituationen bei Daten, weil der Übersetzer sie ablehnt.

Und daraus folgt auch die Lernkurve. Wer aus Java kommt, verbringt die ersten Wochen damit, gegen den Übersetzer zu argumentieren. Das ist normal und hört auf; aber es ist ein realer Zeitaufwand, den man einplanen muss.

Wo Rust passt: systemnahe Software, Kommandozeilenwerkzeuge, WebAssembly, Bibliotheken mit strengen Anforderungen an Geschwindigkeit und Speicherverbrauch, und Bereiche, in denen Speicherfehler sicherheitskritisch sind.

Wo es nicht passt: schnell wechselnde Fachanwendungen. Wenn sich die Datenstrukturen laufend ändern, ist die Strenge des Übersetzers eher Reibung als Hilfe.

Ein Beispiel aus dem KI-Umfeld: Ein erheblicher Teil der Werkzeuge für lokale Inferenz ist systemnah geschrieben, weil dort Speicherverwaltung und Rechenkerne die entscheidenden Größen sind. Wer sich fragt, warum lokale Modelle so genügsam sein können, findet einen Teil der Antwort dort — die Rahmenbedingungen stehen in Ollama: lokale Sprachmodelle betreiben.

Go: einfach halten

Go setzt auf wenige Sprachmittel und schnelle Übersetzung — es ist bewusst langweilig.

Die Sprache wurde entworfen, um in großen Teams über lange Zeit lesbar zu bleiben. Sie hat wenige Konzepte, eine verbindliche Formatierung und eine Standardbibliothek, die für Netzdienste erstaunlich weit reicht.

Goroutinen und Kanäle sind der bekannteste Teil: Nebenläufigkeit ist Sprachmittel, nicht Bibliothek. Eine Goroutine zu starten kostet eine Zeile, und Kanäle sind der eingebaute Weg, zwischen ihnen zu kommunizieren.

Das Ergebnis ist ein einzelnes Binärprogramm ohne Laufzeitabhängigkeiten. Genau deshalb ist Go im Infrastrukturbereich so verbreitet — ein Werkzeug, das man als eine Datei ausliefert, ist unschlagbar bequem. Kubernetes, Docker, Terraform und viele weitere sind in Go geschrieben; wie das Ökosystem darum aussieht, streift Kubernetes-Architektur verstehen.

Ehrlich zu den Schwächen: Die Fehlerbehandlung über zurückgegebene Fehlerwerte ist geschwätzig — if err != nil prägt jedes Go-Programm. Die Ausdrucksstärke ist bewusst begrenzt, was manche als Klarheit und andere als Einschränkung erleben. Generizität kam spät dazu und wird sparsamer eingesetzt als in anderen Sprachen.

Wo Go passt: Infrastrukturwerkzeuge, Netzdienste, alles, was ein einzelnes Binärprogramm sein soll, und Teams, die Wert auf einheitlichen Stil legen.

Kotlin: Java ohne die Umstände

Kotlin läuft auf derselben Laufzeitumgebung wie Java und kann im selben Projekt daneben stehen — der Wechsel ist schrittweise möglich.

Das ist der praktisch wichtigste Punkt und unterscheidet Kotlin grundlegend von den anderen beiden: Es ist die einzige der drei, die man einführen kann, ohne etwas neu zu schreiben. Eine neue Klasse in Kotlin, der Rest bleibt Java, beides übersetzt gemeinsam.

Was Kotlin gegenüber Java bietet:

• Nullsicherheit im Typsystem. Ob etwas null sein darf, steht im Typ und wird vom Übersetzer geprüft.
• Datenklassen — was in Java ein Record ist, gibt es in Kotlin seit Anfang an und mit mehr Möglichkeiten.
• Koroutinen für nebenläufige Programmierung, mit strukturierter Nebenläufigkeit.
• Erweiterungsfunktionen, um fremde Typen zu ergänzen, ohne zu erben.
• Deutlich weniger Schreibarbeit bei gleicher Aussage.

Der wichtigste Treiber war Android, wo Kotlin die bevorzugte Sprache ist. Auf dem Server hat es sich langsamer verbreitet, wächst dort aber stetig.

Ehrlich zu den Kosten: Zwei Sprachen im selben Projekt bedeuten zwei Werkzeugketten-Feinheiten, zwei Formatierungskonventionen und Entwickler, die beide lesen können müssen. Die Mischung ist möglich, aber sie ist nicht kostenlos.

Was ein Sprachwechsel im Team kostet

Der Abschnitt, der den Artikel rechtfertigt — und den kein Tutorial hat.

Eine zweite Sprache im Haus kostet dauerhaft, nicht einmalig. Die Posten:

Einarbeitung. Für Kotlin sind es bei Java-Kundigen Tage. Für Go ein bis zwei Wochen bis zur Produktivität. Für Rust realistisch ein bis drei Monate, bis jemand ohne ständige Übersetzerkämpfe arbeitet.

Werkzeugkette. Bauwerkzeug, Abhängigkeitsverwaltung, Formatierung, statische Analyse, Sicherheitsprüfung der Abhängigkeiten, Container-Abbilder, Ausrollverfahren — alles noch einmal, für die zweite Sprache.

Bibliotheken und Hausstandards. Protokollierung, Konfiguration, Fehlerbehandlung, Anbindung an die Beobachtbarkeit: In der ersten Sprache gibt es dafür einen Hausweg. In der zweiten muss er neu gefunden werden.

Einstellung neuer Leute. Der Bewerberkreis ändert sich. Für Java und Go ist er groß, für Kotlin auf dem Server kleiner, für Rust deutlich kleiner — und dort teurer.

Wissensinseln. Der größte und am schlechtesten sichtbare Posten. Wenn drei Leute die zweite Sprache können und fünfzehn nicht, ist jede Änderung an diesen Diensten von drei Personen abhängig. Bei Urlaub, Krankheit und Kündigung wird das spürbar.

Doppelte Pflege. Sicherheitsaktualisierungen, Versionswechsel der Laufzeitumgebung, Anpassungen an neue Betriebsvorgaben — für jede Sprache getrennt.

Die Regel, die sich daraus ergibt: Eine zweite Sprache lohnt, wenn sie ein Problem löst, das die erste nicht lösen kann — nicht, wenn sie es angenehmer löst. Angenehmer ist kein hinreichender Grund für dauerhafte Doppelkosten.

Welche als Nächstes?

Eine Entscheidungshilfe nach Ausgangslage:

Ausgangslage	Empfehlung	Begründung
Java-Team mit Android-Anteil	Kotlin	schrittweise einführbar, auf Android ohnehin Standard
Java-Team, das Infrastrukturwerkzeuge baut	Go	einzelnes Binärprogramm, passendes Ökosystem
Klar abgegrenzter, leistungskritischer Kern	Rust	Speichersicherheit ohne Laufzeitkosten, Grenze bleibt klein
Team will „etwas Modernes"	keine	kein Problem, keine zweite Sprache
Frust über Java-Geschwätzigkeit	erst die Java-Version prüfen	vieles davon ist seit Version 8 entfallen

Die letzte Zeile ernst gemeint: Ein erheblicher Teil der Argumente gegen Java stammt aus der Zeit vor Version 8. Records, var, Musterabgleich, Textblöcke und virtuelle Threads haben die häufigsten Kritikpunkte adressiert. Wer auf einer alten LTS-Version festhängt, sollte zuerst dort ansetzen — der Weg dorthin steht in Welche Java-Version? LTS, Distributionen und Migration, die Sprachmittel in Java-Grundlagen.

Ein Zusatzgedanke für verteilte Systeme: Wenn ohnehin mehrere Dienste existieren, ist die Sprachwahl je Dienst möglich — und genau das ist einer der genannten Vorteile von Microservices. Er wird allerdings regelmäßig überschätzt, weil er dieselben Teamkosten erzeugt wie oben beschrieben. Mehr dazu in Microservices bauen.

Wo Java stark bleibt

Ohne Verteidigungshaltung, aber der Vollständigkeit halber:

• Das Ökosystem. Für nahezu jede Aufgabe gibt es eine reife, gepflegte Bibliothek. Das ist bei jüngeren Sprachen anders.
• Werkzeuge. Profiler, Fehlersuche, statische Analyse, Überwachung — die Werkzeuglandschaft ist ausgereift.
• Verfügbarkeit von Entwicklern. Der größte Bewerberkreis der vier.
• Stabilität über Jahrzehnte. Java-Code von vor fünfzehn Jahren übersetzt meist noch. Für langlebige Unternehmenssysteme ist das ein handfester Wert.
• Die JVM selbst. Speicherbereinigung, Just-in-Time-Übersetzung und Beobachtbarkeit sind auf einem Stand, den man nicht nebenbei erreicht.

Wo man tatsächlich anfängt

Die ehrliche Verweisliste — und der Grund, warum dieser Artikel kein Tutorial ist:

• Rust: Das offizielle Buch ist vollständig, kostenlos und in mehreren Sprachen verfügbar. Ein deutschsprachiges Duplikat wäre schlechter.
• Go: Die interaktive Tour im Browser bringt einen in wenigen Stunden auf ein produktives Niveau.
• Kotlin: Die offizielle Dokumentation enthält einen eigenen Abschnitt für Java-Umsteiger — genau der richtige Einstieg für diese Zielgruppe.

Alle drei sind besser als das, was ich hier schreiben könnte. Was ich beitragen kann, ist die Frage davor: ob sich der Einstieg lohnt.

Häufige Fragen

Wofür wird Rust benutzt? Systemnahe Software, Kommandozeilenwerkzeuge, WebAssembly und leistungskritische Bibliotheken — überall dort, wo Speichersicherheit ohne Laufzeitkosten zählt.

Wofür wird Go benutzt? Infrastrukturwerkzeuge und Netzdienste. Ein erheblicher Teil der heutigen Cloud-Werkzeuge ist in Go geschrieben.

Lohnt sich Kotlin, wenn man Java kann? Wenn Android im Spiel ist, eindeutig. Auf dem Server ist es eine Abwägung — der Einstieg ist leicht und schrittweise möglich, aber zwei Sprachen im Projekt kosten dauerhaft.

Welche Sprache soll ich als Nächstes lernen? Die, die ein Problem löst, das du hast. Ohne konkretes Problem ist die ehrliche Antwort: keine, sondern die eigene Sprache besser lernen.

Was kostet ein Sprachwechsel im Team? Einarbeitung, zweite Werkzeugkette, neue Hausstandards, veränderter Bewerberkreis, Wissensinseln und doppelte Pflege — dauerhaft, nicht einmalig.

Ist Java überholt? Nein. Ökosystem, Werkzeuge, Verfügbarkeit von Entwicklern und Stabilität sind weiterhin Argumente, die schwer wiegen — und die Sprache hat sich seit Version 8 erheblich verändert.

Zusammenfassung und praktische Tipps

Die Sprachfrage ist selten eine technische und fast immer eine Teamfrage. Die wichtigsten Punkte:

• Rust löst Speichersicherheit ohne Laufzeitkosten — zum Preis einer steilen Lernkurve.
• Go ist bewusst langweilig und deshalb im Infrastrukturbereich so verbreitet.
• Kotlin ist die einzige der drei, die sich schrittweise einführen lässt.
• Eine zweite Sprache kostet dauerhaft, nicht einmalig — Wissensinseln sind der teuerste und unsichtbarste Posten.
• „Angenehmer" ist kein hinreichender Grund für eine zweite Sprache. „Löst ein Problem, das die erste nicht lösen kann" schon.
• Prüfe zuerst die eigene Java-Version. Viele Argumente gegen Java stammen aus der Zeit vor Version 8.
• Für die Tutorials nimm die offiziellen Quellen — sie sind besser als jede Nacherzählung.

Mein Rat: Lern die nächste Sprache an einem echten kleinen Werkzeug, nicht an Übungsaufgaben — ein Kommandozeilenprogramm, das du tatsächlich benutzt. Danach weißt du nicht nur, wie die Sprache aussieht, sondern auch, wie sich ihre Werkzeugkette anfühlt. Und genau die entscheidet darüber, ob ein Team damit dauerhaft arbeiten will.

Ressourcen

• The Rust Programming Language – das offizielle Buch, kostenlos und übersetzt
• A Tour of Go – interaktive Einführung im Browser
• Kotlin – Dokumentation – mit eigenem Abschnitt für Java-Umsteiger
• Kotlin für Java-Entwickler – die Unterschiede im direkten Vergleich