I am done with Golang
Das Video „I am done with Golang“ wirft Go vor, mit Generics und Iteratoren sein Gründungsversprechen zu brechen: Komplexität bewusst zu begrenzen. Die Sorge ist berechtigt, die Schlussfolgerung nicht. Einfachheit war nie eine Eigenschaft der Sprache allein, sondern eine Architekturentscheidung des Teams. Wer sie der Sprachspezifikation überlässt, hat sie bereits verloren.
Ausgangslage: Der Vorwurf
Go wurde für große Codebasen und wechselnde Teams entworfen. Seine Attraktivität lag nie allein in Performance oder Nebenläufigkeit, sondern im bewusst begrenzten Sprachumfang: eine Formatierung, eine Toolchain, wenige Konzepte, ein wiedererkennbarer Stil über Projektgrenzen hinweg. Das senkt den Onboarding-Aufwand, verkürzt Code Reviews und erleichtert Betrieb und Übergaben. Im Enterprise-Kontext ist das ein wirtschaftlicher Vorteil, kein ästhetisches Detail.
Genau diesen Vorteil sieht das Video erodieren. Wenn Teams für dieselbe Aufgabe zwischen expliziter Schleife, generischen Hilfstypen und Iterator-Pipelines wählen können, wird Go weniger vorhersehbar. Die Sprache nähere sich den Abstraktionswelten an, von denen sie sich absetzen wollte.
Was an der Kritik zutrifft
Ich halte die Sorge für halb richtig. Sprachfeatures erweitern nicht nur die Möglichkeiten, sondern auch die Zahl der Entscheidungen, die ein Team treffen und durchhalten muss.
Iteratoren zeigen das gut. Seit Go 1.23 können Funktionen als range-Quelle dienen. Die Standardbibliothek liefert mit iter.Seq und iter.Seq2 ein einheitliches Modell (vgl. Go Blog: Range Over Function Types). Das abstrahiert den Umgang mit Containern und Sequenzen. Zugleich kann es Kosten und Kontrollflüsse verbergen, die eine explizite Schleife offenlegt. Die eigentliche Gefahr liegt aber nicht im Feature, sondern in seinem Einsatz als Selbstzweck: generische Frameworks für einmalige Probleme, Hilfsschichten, die niemand im Team zuverlässig erklären kann.
Die Go-Entwicklerbefragung 2025 stützt beide Lesarten. Als größte Herausforderung in Teams gilt die konsistente Einhaltung von Coding Standards. Zugleich bewerten 91 % der Befragten die Arbeit mit Go positiv (vgl. Results from the 2025 Go Developer Survey.
Warum die Schlussfolgerung nicht trägt
Aus berechtigter Sorge folgt kein Abschied. Generics wurden nicht eingeführt, um Go in Rust oder C++ zu verwandeln. Sie adressieren Fälle, in denen Entwickler zuvor Code duplizieren, unsicher konvertieren oder Reflection einsetzen mussten. Die offizielle Leitlinie bleibt dabei zurückhaltend: erst konkreten Code schreiben, Typparameter erst dann, wenn sich gleiche Logik für unterschiedliche Typen tatsächlich wiederholt (vgl. Go Blog: When To Use Generics).
Auch die Iteratoren haben eine nüchterne Begründung. Vor Go 1.23 existierten in Bibliotheken zahlreiche inkompatible Wege, eigene Container zu durchlaufen. Die Standardisierung ersetzt Wildwuchs durch eine Konvention (vgl. Go 1.23 Release Notes). Eine Präzisierung zum Video gehört an diese Stelle: Generische Typen mit Methoden gibt es seit Go 1.18. Go 1.24 ergänzte generische Typ-Aliasse, vorwiegend für schrittweise Refactorings in großen Paketlandschaften (vgl. Go-Spezifikation und Go Blog: Go 1.24).
Wofür wir Go empfehlen und wofür Rust
Wir empfehlen Go dort, wo Zuverlässigkeit, Betriebseffizienz und langfristige Wartbarkeit schwerer wiegen als sprachliche Ausdrucksvielfalt: für APIs und Microservices mit Verfügbarkeits- und Durchsatzanforderungen, für Integrationsschichten zwischen Plattformen und Fachanwendungen, für Cloud-native Workloads, CLI-Werkzeuge und event-getriebene Verarbeitung. Klarer, idiomatischer Go-Code ist schnell geschrieben. Wichtiger noch: Er bleibt über Jahre und Teamwechsel hinweg betreibbar, prüfbar und weiterentwickelbar.
Dass wir im eigenen Produkt RKA² auf Rust setzen (vgl. BTMS/RKA.IO: Warum RKA² auf Rust setzt), widerspricht dem nicht. Rust ist stark bei geschäftskritischen, sicherheits- oder ressourcenintensiven Komponenten, in denen Speichersicherheit, vorhersehbare Laufzeit und maximale Ressourcenkontrolle entscheiden. Go bleibt unsere erste Wahl für schlanke, schnell gelieferte Services. Zwei Sprachen, zwei Problemklassen, kein Glaubenskrieg.
Ob Generics oder Iteratoren vorhanden sind, entscheidet über keine dieser Zuordnungen. Relevant sind Fachlichkeit, kritische Qualitätsattribute, Betriebsmodell, Teamkompetenz und der erwartete Lebenszyklus. Weniger geeignet ist Go, wenn eine hochkomplexe Fachdomäne eine ausdrucksstarke Modellierungssprache verlangt oder spezialisierte KI- und Wissenschaftsökosysteme den Ausschlag geben.
Umsetzung: Leitplanken statt Sprachdogma
Die Architekturaufgabe besteht darin, den Einsatz neuer Sprachmittel dort zu begrenzen, wo sie keinen erkennbaren Nutzen haben. Drei Leitplanken genügen dafür.
Erstens: direkter Code als Standard. Eine explizite Schleife schlägt eine generische Pipeline, wenn sie den fachlichen Ablauf lesbarer macht. Zweitens: Generics gezielt zulassen, etwa in wiederverwendbaren Containern, typunabhängigen Hilfsfunktionen und Infrastrukturcode. Im Fachcode bleiben sie die Ausnahme, sofern sie Duplikation nicht messbar reduzieren. Drittens: neue Sprachmittel schriftlich regeln. Ein kurzer Engineering-Standard zu Iteratoren, generischen Utilities und Fehlerbehandlung schützt die Codebasis wirksamer als ein pauschales Verbot, und er ist in jedem Review durchsetzbar, unabhängig vom Werkzeug.
Fazit
Go muss sich nicht einfrieren, um seine Identität zu behalten. Die Sprache bleibt stark, solange Teams neue Ausdrucksmittel nicht mit einem Freibrief für zusätzliche Abstraktionsebenen verwechseln. Die richtige Konsequenz aus dem Video lautet deshalb nicht „Go verlassen“. Sie lautet: Schreiben Sie den Engineering-Standard, der die Einfachheit Ihrer Codebasis festlegt, bevor das nächste Sprachfeature diese Entscheidung für Sie trifft.