Go, Java oder Kotlin? Wann wir welche Sprache wählen

Wer in unseren Tech-Radar schaut, findet im innersten Ring gleich drei Sprachen, die im Internet gern gegeneinander ausgespielt werden: Java, Kotlin und Go. Bei uns laufen alle drei seit Jahren in Produktion — nebeneinander, in klar getrennten Bahnen. Dieser Artikel beschreibt, wie diese Bahnen verlaufen, warum sich innerhalb der JVM-Bahn etwas verschoben hat und nach welchen Kriterien wir entscheiden. Spoiler: Es geht fast nie um Syntax, und nie um Mode.

Die Bahnen, wie sie heute verlaufen

Die JVM ist das Rückgrat unserer Produkt-Backends. Unsere KI-Plattform, unsere Zeiterfassung, unser Messaging — die Systeme mit der größten Fachlichkeit laufen auf der Java Virtual Machine. Dort, wo über Jahre ein Domänenmodell wächst, wo Geschäftsregeln, Rollen, Workflows und Integrationen zusammenkommen, spielt das JVM-Ökosystem seine Stärke aus: ausgereifte Bibliotheken für praktisch alles, erstklassiges Tooling, und eine Plattform, die große Codebasen über viele Jahre und wechselnde Hände tragbar hält.

Go übernimmt die performance-kritischen Services. Am deutlichsten in unserem Remote Game Server: kleine, fokussierte Dienste, die unter Last vorhersagbar bleiben müssen. Goroutines für natürliche Nebenläufigkeit, schneller Start, eine einzelne statische Binary — und ein Ressourcenprofil, das man ernst nehmen muss: Wir hatten es hier schon 2019 vermessen — ein Go-Docker-Image bleibt typischerweise unter 20 MB und startet mit wenigen MB RAM, wo eine klassische Spring-Boot-Anwendung schon vor dem ersten Request dreistellige MB-Beträge belegt.

Die Verschiebung innerhalb der JVM: Kotlin

Die interessantere Entwicklung der letzten Jahre fand innerhalb der JVM-Bahn statt. Kotlin kam bei uns über die native Android-Entwicklung ins Haus — und hat sich von dort in die Backends bewährt: Neue JVM-Entwicklung entsteht bei uns inzwischen bevorzugt in Kotlin.

Die Gründe sind unspektakulär praktisch:

• Null-Safety im Typsystem. Die häufigste Laufzeitüberraschung der Java-Welt wird zur Compile-Zeit-Frage. In Systemen, die jahrelang weiterentwickelt werden, summiert sich das zu echter Stabilität.
• Weniger Zeremonie, präzisere Modelle. data class für Value Objects, sealed class für geschlossene Fallunterscheidungen, benannte Argumente und Default-Werte — wer wie wir domänengetrieben modelliert, bekommt mit Kotlin ein Vokabular, das Invarianten und Fachlichkeit direkter ausdrückt als Java-Boilerplate.
• Kein Bruch, keine Migration. Kotlin und Java leben im selben Projekt, rufen sich gegenseitig auf und teilen sich das gesamte Ökosystem. Unser Java-Bestand bleibt, wo er ist und gut funktioniert; neue Module entstehen daneben in Kotlin. Es gab keinen Rewrite-Moment — und es wird keinen brauchen.

Wichtig dabei: Das ist keine dritte Bahn, sondern eine Evolution innerhalb der bestehenden. Plattform, Bibliotheken, Tooling und Betriebswissen bleiben dieselben — genau deshalb war dieser Wechsel günstig zu haben, anders als es ein Sprung auf eine fremde Plattform gewesen wäre.

Die Kriterien dahinter

Wenn ein neuer Service ansteht, stellen wir sinngemäß vier Fragen:

1. Wie viel Fachlichkeit wird hier wohnen? Ein reiches, langlebiges Domänenmodell mit vielen Invarianten und Integrationen → JVM, heute bevorzugt in Kotlin. Die Investition in das größere Ökosystem zahlt sich über die Lebensdauer aus. Ein schmaler Dienst mit klarem Auftrag → Go.
2. Wie hart ist das Latenz- und Ressourcenbudget? Wenn Millisekunden Produktqualität sind oder viele Instanzen klein und schnell skalieren müssen, gewinnt Go. Wenn das Budget entspannt ist, entscheidet das Kriterium nicht.
3. Was kann das Team an dieser Stelle am besten warten? Sprachen sind auch Betriebskosten. Ein Service in der „falschen”, aber im Team beherrschten Sprache ist oft die bessere Entscheidung als ein technisch eleganterer Exot, den in zwei Jahren niemand mehr anfassen mag.
4. Welche Bibliothek trägt die Hauptlast? Manchmal entscheidet schlicht, wo die ausgereifteste Anbindung existiert — ein exotisches Protokoll, ein bestimmtes Framework, eine Integration. Dann folgt die Sprache der Bibliothek, nicht umgekehrt. Dank Interop ist das auf der JVM ohnehin keine Entweder-oder-Frage.

Auffällig ist, was in der Liste fehlt: „Welche Sprache ist besser?” Die Frage hat sich bei uns als unbrauchbar erwiesen. Jede der drei ist für ihren Einsatz die jeweils beste Wahl — und am falschen Ort die schlechtere.

Warum nicht einfach eine Sprache?

Der berechtigte Einwand: Jede zusätzliche Sprache kostet — Tooling, Build-Pipelines, Wissen im Team, Kontextwechsel. Deshalb gilt bei uns die Gegenregel: Zwei Bahnen, keine dritte ohne Not. Neue Technologie kommt nicht über Begeisterung ins System, sondern über den Tech-Radar-Prozess: erst Assess, dann Trial in einem überschaubaren Einsatz, und Adopt erst, wenn die Grenzen bekannt sind. Kotlin ist das Lehrbuchbeispiel dafür — über die Android-Apps hereingekommen, im Backend erprobt, und erst nach bestandener Praxis zur bevorzugten JVM-Sprache geworden. Der Weg dauerte Jahre, und genau das war richtig so.

Genauso wichtig: Die Bahnen sind durchlässig für Erkenntnisse, nicht für Beliebigkeit. Was wir in Go über schlanke Services lernen, verbessert auch unsere JVM-Dienste — kleinere Images, schnellere Starts, weniger Magie. Und die Disziplin im Domänenmodell, die unsere Backends prägt, gilt in jedem Go-Service genauso.

Fazit

„Go, Java oder Kotlin?” ist bei uns keine Richtungsfrage, sondern eine Einsatzfrage — beantwortet pro Service, anhand von Fachlichkeitstiefe, Budget, Team und Ökosystem. Innerhalb der JVM hat Kotlin das Schreiben übernommen, ohne dass Java-Bestand weichen musste; Go hält die heißen Pfade. Das Ergebnis nach Jahren mit allen dreien in Produktion: kein Lager, keine Migrationswellen, keine Glaubenskriege. Nur Werkzeuge, die jeweils dort arbeiten, wo sie die stärksten Argumente haben. Langweilig? Vielleicht. Aber Langeweile an dieser Stelle ist genau das, was man im Betrieb haben will.