Hintergrund und technischer Kontext von Programmiersprachenwahl für CLI- und ETL-Systeme

Ich habe nun seit über 10 Jahren beruflich mit PHP, Go, JavaScript und Python gearbeitet. Den Großteil meiner Karriere habe ich mit dem Aufbau von Webservices verbracht, und in den letzten Jahren habe ich Bruin entwickelt, das primär ein in Go geschriebenes CLI-Tool ist.


Bruin ist ein Open-Source-ETL-Tool, und wie einige von euch vielleicht wissen, liebt (oder liebte?) das Datenökosystem es, Tools in Python zu bauen. Es gibt eine Vielzahl verfügbarer Bibliotheken, Data Engineers sind mit Python vertraut, daher ist es einfacher, Beiträge zu erhalten, und es ist leichter, Python-Entwickler im Vergleich zu Go zu finden. Als wir mit der Entwicklung von Bruin begonnen haben, mussten wir eine Entscheidung treffen: bauen wir das CLI in Go oder in Python?

Wir hatten einige Einschränkungen, die wir berücksichtigen mussten, bevor wir eine Entscheidung trafen:

Bruin ist ein Datenorchestrierungs-Tool, was bedeutet, dass viele Dinge gleichzeitig ausgeführt werden müssen.
Bruin muss mit vielen verschiedenen Systemen interagieren, wie z. B. Sprachlaufzeiten oder externen APIs für Datenplattformen; daher benötigen wir ein solides Ökosystem rund um die Sprache.
Bruin muss schnell sein. Es ist ein CLI-Tool, und wir wollten es mit verschiedenen Systemen verwenden, wie VS-Code-Erweiterungen oder lokalen UIs als Backend, und es musste ausreichend performant sein.
Bruin benötigt vorhersehbare Fehlerbehandlungspfade für all die verschiedenen Systeme, mit denen es integriert wird, und muss den Benutzer explizit informieren.
Bruin wird auf den Maschinen der Benutzer laufen, was bedeutet, dass es einfach sein sollte, verschiedene Betriebssysteme und Architekturen zu unterstützen.

Zusätzlich zu all diesen Einschränkungen gab es auch eine subjektivere Einschränkung: Ich würde für längere Zeit der Hauptentwickler sein, und es musste eine Sprache sein, mit der ich gerne arbeite. Freude und Energie sind einige der seltensten Ressourcen, die ein kleines Team beim Aufbau großer Projekte haben kann, und ich hielt es für entscheidend, dass ich den verwendeten Tech-Stack nicht verabscheue.

Am Ende entschieden wir uns für Go. Es erfüllte viele der Anforderungen, und obwohl es einige Nachteile hatte, wie z. B. einen Mangel an Bibliotheken für bestimmte datenbezogene Aufgaben im Vergleich zu Python, erfüllte es die wichtigste Anforderung: Ich arbeitete wirklich gerne mit Go. Diese Freude ermöglichte es mir, tausende Zeilen Code zu schreiben, bevor Agenten überhaupt ein Thema waren, und hielt uns über lange Zeit hinweg am Laufen. Ein Teil von mir hatte Angst, dass ich eine strategische Fehlentscheidung getroffen habe, indem ich Go gewählt habe, da wir vieles von Grund auf neu entwickeln mussten; jedoch sagte mir meine Intuition, dass die Geschwindigkeits- und DX-Vorteile von Go gegenüber Python uns langfristig weitere Vorteile bringen würden.

Ich hatte absolut keine Ahnung, dass Agenten ein Thema werden würden, aber ich glaube, unsere Intuition hat uns in eine ziemlich glückliche Position gebracht, als es soweit war. Ich möchte einige der Vorteile von Go im Kontext der Zusammenarbeit mit KI-Agenten zur Softwareentwicklung hervorheben und erklären, warum ich glaube, dass Go heute die beste Sprache für Agenten ist.

Go als kompilierte Sprache für zuverlässige KI-generierte Software

Agenten erzeugen Unmengen an Codezeilen. Ob man sie in dieser Hinsicht als intelligent bezeichnet oder nicht, sie produzieren sehr glaubwürdigen Code, Code, der meist korrekt aussieht. Genau hier beginnt die erste Herausforderung: Wie stellen wir sicher, dass der erzeugte Code funktioniert?

Eine der einfachsten Möglichkeiten ist die Verwendung einer kompilierten Sprache. Strong Typing, Static Typing – ich bringe die Begriffe immer durcheinander – ermöglicht es KI-Agenten, den generierten Code iterativ zu verbessern, bis er in gewissem Maße korrekt ist. Das bedeutet nicht, dass der Code tut, was er soll, sondern lediglich, dass er frei von einer bestimmten Klasse von Fehlern ist, etwa falschen Typen oder Argumenten. Code, der kompiliert, gibt zumindest die Garantie, dass er syntaktisch korrekt ist.

Während kompilierte Sprachen schon lange existieren, gibt es nicht viele High-Level-Sprachen wie Go. Es gibt natürlich Rust, das jedoch sehr andere Dynamiken und Zielanwendungen hat, und ich glaube, dass Go für KI-Agenten gegenüber Rust gewinnt:

Go’s Syntax und Konzepte sind einfacher als die von Rust.
Go’s Typsystem ist nicht so komplex wie das von Rust, wodurch generierter Code näher an einer gemeinsamen idiomatischen Schreibweise liegt und für Menschen leichter verständlich ist.
Go kompiliert schneller als Rust, was schnellere Feedback-Zyklen für KI-Agenten ermöglicht.
Es gibt deutlich mehr Go-Code als Rust-Code, was es Modellen erleichtert, besseren Go-Code zu generieren.

Dies ist eher eine intuitive Annahme als durch Daten belegt, ich lasse mich hier gerne korrigieren. Während es viele kompilierte Sprachen gibt, ist Go in Bezug auf Benutzerfreundlichkeit, Community, Iterationsgeschwindigkeit und Einfachheit definitiv ein Spitzenkandidat.

Einfachheit von Go als Vorteil für KI-Codegenerierung

Vielleicht hätte dieser Punkt an den Anfang gehört. Wie auch immer. Go ist eine sehr einfache Sprache. Wenn man irgendeine Programmiersprache beherrscht, sollte das Lesen von Go-Code trivial sein. Man versteht sofort, was der Code macht, und kann darüber logisch nachdenken. Das bedeutet, dass man auch bei großen Mengen von generiertem Go-Code den Überblick behält.

Ein weiterer Vorteil ist das Verständnis von Designentscheidungen: Während Agenten sehr guten Code generieren können, treffen sie manchmal seltsame Designentscheidungen und folgen diesen weiter. Die Einfachheit der Sprache hilft dabei, zu erkennen, wohin sich der Agent bewegt.

Dennoch glaube ich fest daran, dass wir in 12 Monaten kaum noch Code lesen werden, und man könnte argumentieren, dass Lesbarkeit oder Einfachheit künftig weniger wichtig sind. Selbst dann würde ich dennoch gerne in den Code springen können, wenn ich es möchte.

Opinionated Design und standardisierte Toolchains in Go

Das ist einer der Aspekte, die ich an Go liebe: Es ist eine meinungsstarke Sprache mit klaren Richtlinien und entsprechender Tooling-Unterstützung. Es gibt standardisierte Wege, Tests auszuführen, Code zu formatieren oder Binärdateien zu erstellen. Go hat auch einen spezifischen Ansatz zur Fehlerbehandlung. Ob man ihn mag oder nicht, er bietet eine klare Struktur, die es erleichtert, idiomatischen Go-Code zu schreiben, an dem viele Menschen und Agenten arbeiten können.

Nehmen wir JavaScript als Beispiel: Es gibt unzählige Wege, Dinge zu tun. Jedes Mal, wenn ich ein JS-Projekt starte, muss ich die verwendeten Tools entdecken, verstehen und mich einarbeiten, bevor ich produktiv sein kann. Jeder hat unterschiedliche Meinungen zu Codeformatierung, Paketdistribution oder sogar Importmechanismen. Meiner Meinung nach ist der Zustand von JavaScript ziemlich chaotisch, aber ich schweife ab.

Dass Go diese Probleme vermeidet, bringt einen entscheidenden Vorteil für KI-generierten Code: Modelle wissen, wie sie mit Go arbeiten müssen, basierend auf den Trainingsdaten. Go-Code ist in der Regel sehr einheitlich, und die standardisierten Tools ermöglichen eine effektive Nutzung durch Agenten.

Fordert man einen Agenten auf, JavaScript-Code zu formatieren, wird er ein neues Tool einführen und versuchen, es zum Laufen zu bringen. Bei Go reicht ein einfacher gofmt-Aufruf. Dasselbe gilt für Unit-Tests oder das Erstellen von Binärdateien.

Plattformübergreifende Go-Binärdateien als strategischer Vorteil

Das ist besonders relevant, wenn man Software entwickelt, die in unbekannten Umgebungen läuft, wie CLI-Tools. In solchen Fällen ist Go die perfekte Wahl.

Plattformübergreifende Unterstützung ist ein zentraler Bestandteil von Go. Dadurch wird es trivial, Tests – sowohl Unit- als auch Integrationstests – in verschiedenen Umgebungen bei jeder Änderung auszuführen.

Was bedeutet das?

Genau: KI-Agenten können ihre Arbeit schnell validieren und sicherstellen, dass keine bestehende Funktionalität beschädigt wurde. Natürlich bringt das nur Vorteile, wenn man auch Tests schreibt, aber die Möglichkeit, denselben Code auf verschiedenen Betriebssystemen zu validieren, ist enorm wertvoll. 

Background Agents und standardisierte Go-Umgebungen

Wie viele andere experimentieren wir intensiv mit Background-Agenten. Ob es darum geht, über Slack Änderungen anzustoßen oder lokale Sessions an Remote-Umgebungen zu übergeben – wir lösen uns zunehmend von der direkten Kontrolle über die Ausführungsumgebung.

Hier zeigt sich erneut ein Vorteil von Go: Der gleiche Code erzeugt Binärdateien, die auf Linux, Windows und macOS identisch laufen, und der gesamte Entwicklungsprozess ist standardisiert. Das bedeutet, dass es egal ist, wo Agenten laufen oder ob ein Sandbox-Anbieter unsere Abhängigkeiten unterstützt – es funktioniert einfach.

Warum KI-Agenten Go besonders gut beherrschen

Ein Vorteil, der möglicherweise mit der Zeit verschwindet: Anfang 2026 erzeugen Agenten in meiner Erfahrung in 95 % der Fälle beim ersten Versuch gültigen Go-Code. Ich habe keine Daten dazu, aber ich habe deutlich mehr Probleme mit Python als mit Go.

Modelle kennen Bibliotheken, Patterns und Best Practices so gut, dass es fast trivial wird, Features in Go zu entwickeln, sobald die Richtung klar ist.

Ich glaube, das liegt nicht nur an der Datenmenge. Python hat zwar mehr Trainingsdaten, aber in Go gibt es oft genau einen Weg, Dinge zu tun, während es in Python viele verschiedene Ansätze gibt. Praktisch bedeutet das: Für eine spezifische Bibliothek ist die Go-Trainingsbasis oft klarer strukturiert.

Ich gehe davon aus, dass dieser Vorteil mit besseren Modellen und mehr Trainingsdaten für andere Sprachen verschwinden wird. Aktuell basiert diese Einschätzung eher auf Erfahrung als auf harten Daten.

Zukunftsperspektiven: Programmiersprachen im Zeitalter von KI-Agenten

Ich glaube, Programmiersprachen befinden sich in einer seltsamen Phase, in der viele frühere Prioritäten an Bedeutung verlieren. Menschen werden immer weniger Code selbst schreiben, und wir brauchen Systeme, die Agenten optimal unterstützen.

Go scheint – vielleicht zufällig – einen Sweet Spot aus Benutzerfreundlichkeit, Performance und Verbreitung getroffen zu haben, der es ideal für Agenten macht. Sie schreiben sauberen Go-Code, kompilieren, testen, formatieren und liefern performante Software, die auf vielen Systemen läuft.

All diese Vorteile sind heute bereits verfügbar: Man kann einfach ein Tool wie Claude Code bitten, ein CLI in Go zu erstellen, und das Ergebnis genießen.

Go hat uns bei Bruin durch diese Vorteile enorm geholfen, und wir setzen weiterhin stark darauf. Wird Go die Sprache der Agenten sein? Ich weiß es nicht. Wird es bessere Sprachen geben? Vielleicht. Was ich weiß: Ich bin produktiv, mein Team ist produktiv, und wir liefern schnell solide Software. Und vor allem: Ich arbeite immer noch sehr gerne mit Go – auch im Zeitalter von KI-Agenten.