Go ist die beste Sprache für AI-Agenten

 (getbruin.com)
23 Punkte von GN⁺ 2026-03-04 | 3 Kommentare | Auf WhatsApp teilen
  • Die Einfachheit der Sprache Go und ihre Kompilierungseigenschaften erhöhen die Stabilität des von AI-Agenten erzeugten Codes und die Effizienz bei der Ausführung
  • Dank statischer Typisierung und hoher Kompilierungsgeschwindigkeit können Agenten Codefehler schnell prüfen und wiederholte Aufgaben effizient ausführen
  • Standardisierte Werkzeuge auf Sprachebene (gofmt, Tests, Builds) fördern eine konsistente Codegenerierung durch Agenten
  • Cross-Platform-Binary-Builds werden standardmäßig unterstützt, sodass Hintergrund-Agenten denselben Code auf verschiedenen Betriebssystemen verteilt prüfen und ausführen können
  • Aufgrund dieser Eigenschaften gilt Go als Sprache mit ausgewogenem Verhältnis aus Produktivität, Einfachheit und Performance und entwickelt sich zu einer starken Option für AI-agentenbasierte Entwicklung

Vorteile von Go als kompilierte Sprache

  • Agenten erzeugen große Mengen an Code, und dieser Code ist meist nur „plausibel aussehend“, daher ist die Prüfung, ob er tatsächlich funktioniert, die zentrale Herausforderung
  • Mit einer kompilierten Sprache lassen sich durch ein starkes, statisches Typsystem bestimmte Fehlerklassen wie falsche Typen oder fehlerhafte Argumentverwendung bereits beim Kompilieren ausschließen
  • Wenn die Kompilierung erfolgreich ist, hat man zumindest die Garantie, dass es sich innerhalb des Sprachstandards um syntaktisch korrekten Code handelt
  • Warum Go im Vergleich zu Rust besser für Agenten geeignet ist:
    • Die Syntax und Konzepte von Go sind einfacher als die von Rust
    • Das Typsystem von Go ist weniger ausgefeilt als das von Rust, wodurch generierter Code näher an idiomatischen Schreibweisen bleibt und für Menschen leichter verständlich ist
    • Die Kompilierung von Go ist schneller als bei Rust, wodurch sich die Feedback-Schleife für Agenten verkürzt
    • Go-Code ist im Trainingsmaterial häufiger vertreten als Rust-Code, sodass Modelle besseren Go-Code erzeugen

Die Einfachheit von Go

  • Wer mit irgendeiner Programmiersprache vertraut ist, kann Go-Code lesen und sein Verhalten sofort erfassen, so einfach ist die Sprache selbst
  • Selbst wenn Agenten große Mengen an Go-Code erzeugen, haben Entwickler wenig Mühe, dem Code zu folgen
  • Wenn Agenten mitunter seltsame Designentscheidungen treffen und diese Richtung weiterverfolgen, lässt sich dank der Einfachheit der Sprache leicht erkennen, wohin der Agent steuert
  • In 12 Monaten könnte es sein, dass man Code seltener direkt liest und die Bedeutung von Lesbarkeit und Einfachheit sinkt; die Möglichkeit, den Code bei Bedarf selbst zu prüfen, bleibt jedoch weiterhin wertvoll

Der standardisierte Ansatz von Go

  • Go ist eine stark meinungsgeprägte (opinionated) Sprache mit klaren Richtlinien und Werkzeugen; es gibt standardisierte Wege zum Ausführen von Tests, zum Formatieren von Code und zum Erstellen von Binärdateien
  • Auch die Art der Fehlerbehandlung ist umstritten, bietet aber ein etabliertes Muster, das idiomatischen Code fördert und die Zusammenarbeit von Menschen und Agenten erleichtert
  • Im Vergleich zu JavaScript: In JS-Projekten unterscheiden sich die verwendeten Werkzeuge oft, und die Meinungen zu Code-Formatierung, Paketveröffentlichung und Bibliotheksimporten sind zersplittert, was für Agenten ineffizient ist
  • Dank der Standardisierung in Go können Modelle auf Basis ihres Trainingsmaterials konsistent idiomatischen Go-Code erzeugen
    • Wenn man einen Agenten bittet, JS-Code zu formatieren, versucht er oft erst neue Werkzeuge zu installieren und zu konfigurieren; in Go reicht es, einfach gofmt auszuführen
    • Auch das Schreiben von Unit-Tests und das Erstellen von Binärdateien ist in gleicher Weise standardisiert

Cross-Platform-Binary-Builds

  • In Go ist Cross-Platform-Support ein First-Class-Citizen und besonders vorteilhaft für Software wie CLI-Tools, bei denen die Ausführungsumgebung nicht kontrolliert werden kann
  • Unit-Tests und Integrationstests lassen sich in mehreren Umgebungen mit demselben Befehl ausführen, um zu prüfen, ob bestehende Funktionen nicht beschädigt wurden
  • Der Nutzen wird bei Hintergrund-Agenten noch größer:
    • Es gibt einen Trend, sich zunehmend von der direkten Kontrolle über Build- und Laufzeitumgebungen zu lösen, etwa indem man Cursor per Slack-Nachricht auslöst oder lokale Sessions remote übergibt
    • Go-Code erzeugt auf Linux, Windows und macOS auf dieselbe Weise Binärdateien, und der gesamte Arbeitsprozess ist zwischen den Umgebungen standardisiert, sodass man sich nicht darum kümmern muss, ob ein Sandbox-Anbieter bestimmte Entwicklungsabhängigkeiten unterstützt

Qualität des von Agenten erzeugten Go-Codes

  • Anfang 2026 liegt die Quote, mit der Agenten auf Anhieb gültigen Go-Code erzeugen, bei etwa 95 % (basierend auf persönlicher Erfahrung, keine offiziellen Daten)
  • Im Vergleich zu Python fühlt sich der Einsatz von Agenten mit Go weniger schwierig an
  • Modelle haben Bibliotheken, Muster und Best Practices von Go gut gelernt, sodass die Implementierung von Funktionen fast mühelos wird, wenn man nur die Richtung vorgibt
  • Die Gesamtmenge an Go-Trainingsdaten mag geringer sein als bei Python, aber in Python gibt es für dieselbe Aufgabe 20 verschiedene Herangehensweisen, weshalb die Trainingsdatendichte pro konkreter Bibliothek in Go effektiv höher sein kann
  • Mit besseren Modellen und mehr Trainingsdaten könnte dieser Vorteil im Laufe der Zeit verschwinden

Warum im Bruin-Projekt Go gewählt wurde

  • Bruin ist ein Open-Source-ETL-Tool und hauptsächlich ein in Go geschriebenes CLI-Tool
  • Obwohl Python im Datenökosystem dominierte, waren die wichtigsten Rahmenbedingungen für die Wahl von Go:
    • Als Datenorchestrierungs-Tool ist Concurrency zentral
    • Wegen der Interaktion mit vielen Systemen wie Sprach-Runtimes oder externen APIs von Datenplattformen wird ein ausreichend großes Ökosystem benötigt
    • Als CLI-Tool ist ausreichende Performance erforderlich, um auch als VS-Code-Erweiterung oder Backend für lokale UIs zu dienen
    • Für die Integration vieler Systeme ist vorhersehbare Fehlerbehandlung notwendig
    • Da es auf den Rechnern der Nutzer läuft, muss die Unterstützung verschiedener Betriebssysteme und Architekturen einfach sein
  • Als subjektiver Faktor musste es außerdem eine Sprache sein, mit der die Hauptbeitragenden gern arbeiten, denn in kleinen Teams sind Freude und Energie die knappsten Ressourcen
  • Trotz des Nachteils, dass im Vergleich zu Python bestimmte Datenbibliotheken fehlen, fiel die Entscheidung aus der Überzeugung, dass die Vorteile von Go bei Geschwindigkeit und Developer Experience (DX) langfristig mehr Wert liefern würden

Fazit: Go im Zeitalter der Agenten

  • Programmiersprachen bewegen sich in ein Zeitalter, in dem Menschen Code nicht mehr direkt schreiben
  • Nun werden Systeme benötigt, die Agenten dabei unterstützen, effektiv Code zu schreiben
  • Go bietet dank seines Gleichgewichts aus Benutzerfreundlichkeit, Performance und Allgemeingültigkeit eine ideale Umgebung dafür, dass AI-Agenten Code schreiben und ausführen können
  • Agenten können in Go hochperformante Software, die kompiliert, getestet, formatiert und auf verschiedene Maschinen ausgerollt werden kann, automatisch erzeugen
  • Ob Go zur ultimativen Sprache für Agenten wird oder ob eine noch besser geeignete Sprache auftaucht, ist ungewiss,
    doch das aktuelle Team erzielt bereits spürbare Ergebnisse bei Produktivität und Softwarequalität

Verwandte Beiträge

3 Kommentare

 
mammal 2026-03-05

Vor allem ist es gut, weil der Build schnell ist.
 
tsboard 2026-03-05

Die Go-Sprache hat wirklich ein sehr klares Konzept, und für diejenigen, zu denen dieses klare Konzept gut passt, scheint sie eine gute Wahl zu sein. Ich selbst habe Backends zunächst mit einer JS-Laufzeitumgebung gebaut und bin dann zu Go gewechselt; ich denke, ich kann mit Überzeugung sagen, dass sowohl die Performance als auch die Produktivität bei der Entwicklung damit mehr als zufriedenstellend sind.
 
GN⁺ 2026-03-04
Hacker-News-Kommentare

  • Seit über 9 Monaten in der Beratung stelle ich immer wieder fest, dass Go sehr gut für die Codegenerierung mit LLMs geeignet ist
    Go bietet ein konsistentes Build-System, einen Formatter, statische Typisierung und CSP-basierte Nebenläufigkeit ohne die gefährlichen Aspekte von C++
    Seit über 10 Jahren gibt es keine kompatibilitätsbrechenden Versionen, und auch Framework-Wechsel sind selten
    Wenn ich Teams bei Sancho Studio dazu berate, agentic coding workflows einzuführen, liefert Go mit Claude oder Codex sehr stabile Ergebnisse
    Dagegen sind Python und TypeScript bei Frameworks und Typansätzen zu vielfältig, sodass LLMs schwer konsistente Ausgaben erzeugen können
    Tatsächlich wirkt das, was ich an Go nicht mochte — die Grenzen der Abstraktion — für LLMs eher als Vorteil
    Das neue go fix in Go 1.26 unterstützt automatische Refaktorierung auf AST-Ebene und hält Codebasen aktuell
    Früher habe ich im Projekt Zoom E2E Whitepaper eine PKI in Go aufgebaut, und jetzt, da LLMs den repetitiven Boilerplate-Code übernehmen, spielt Gos Einfachheit ihre Stärken voll aus

    • Ich denke, die meisten dieser Gründe gelten auch für Java
      Java hat mehr Trainingsdaten und ein stärkeres Typsystem, was auch bei der Validierung von LLM-Ausgaben hilfreich ist
    • Stimme voll zu. Ich arbeite seit über 20 Jahren mit C++, aber Golang ist meiner Meinung nach die beste Sprache für die meisten Workflows, solange es nicht um Echtzeitsteuerung oder Embedded geht
    • Mit der Aussage „Gos Abstraktionsgrenzen sind für LLMs ein Vorteil“ kann ich mich sehr gut identifizieren
      Ich bevorzuge Low-Level-Umgebungen, und mir gefallen Gos flacher Abstraktions-Stack und seine vorhersehbare Struktur
      Am Ende passen Einfachheit und Konsistenz sowohl gut zu LLMs als auch zu Entwicklern wie mir
    • Wenn man sich die Codequalität aktueller LLMs ansieht, ist eher die Komplexität der Problemdefinition der größere Faktor als die Sprache
      Standardisierte Sprachen wie Go machen die Ergebnisse leichter verständlich, aber Ruby und C++ sind ebenfalls ziemlich brauchbar
      Bei Lisp oder Bash ist die Freiheit so groß, dass die Resultate stark schwanken
    • Du bist bei Go vielleicht voreingenommen, aber ich habe viel mehr Erfahrung mit TypeScript und sehe das anders
      Python und TypeScript in dieselbe Kategorie zu stecken, ist ungenau
      Python verwirrt LLMs wegen der Versionsbrüche und der spät eingeführten Typisierung, aber TypeScript ist viel konsistenter
      Wenn sich die Gelegenheit ergibt, würde ich gern ein Live-Coding-Duell Go vs TypeScript sehen

  • Bei der Entwicklung von Agenten sollte man meiner Meinung nach möglichst viel Validierung in die Compile-Time verschieben
    Go ist okay, aber sein Typsystem ist nicht so stark wie das anderer Sprachen
    Rust ist sehr nützlich, weil nach bestandenem Compiler-Check kaum noch Laufzeitfehler auftreten
    Haskell wäre wahrscheinlich noch besser

    • Einer der Gründe, warum Rust gut ist: Testcode liegt in derselben Datei
      Wenn der Agent den Quellcode ändert, aktualisiert er auch die Tests mit
      In anderen Sprachen vergisst man Tests leicht
    • Haskell ist ebenfalls großartig, aber LLMs neigen dazu, zu viele Abstraktionen aufzuschichten
      Ich baue gerade auf Haskell eine Toy-Sprache auf Basis abhängiger Typen, und dank der einfachen Syntax können LLMs gut damit umgehen
      Intern funktioniert sie ähnlich wie sicheres/unsicheres Rust
    • Eine Stimme für Rust. Ich halte die Strategie für richtig, Komplexität früh zu tragen und Betriebskosten zu senken
      Wir schreiben den Code ja nicht selbst, also ist etwas Unbequemlichkeit in Ordnung
    • Ich nutze Rust auch gern, vor allem wegen der starken Interoperabilität zwischen Sprachen
      Man kann es etwa mit TypeScript für SPAs kombinieren, mit Tauri plattformübergreifende Apps bauen oder ein Python-Sidecar anhängen
      Ich experimentiere auch mit Spielen in Bevy, und die ECS-Struktur gefällt mir
      So konnte ich die Vorteile mehrerer Sprachen kombinieren und ihre Nachteile vermeiden
    • Mich würde interessieren, ob jemand Hochsprachen wie Haskell oder Prolog schon zusammen mit LLMs im Jahr 2025 ausprobiert hat

  • Ich habe Gemini, Claude Code und Codex über mehrere Tage hinweg aufgefordert: „Entwerft mal eine Sprache, die ihr selbst gern hättet“
    Herausgekommen ist eine Sprache im Forth-Stil mit starkem Typsystem, Contracts, nativen Tests, Fuzz-Tests und einem Z3-basierten Constraint-Solver
    Den Interpreter habe ich in Elixir implementiert und als Cairn-Projekt veröffentlicht
    Die Sprache wurde in rund 150 Commits gebaut und lief ohne Laufzeitfehler
    Dieses Experiment zeigt, wie wichtig Compile-Time-Analyse und Testwerkzeuge sind

    • Interessantes Projekt, aber ich halte die Annahme für falsch, dass LLMs eine für sie selbst optimale Sprache entwerfen können
      Solche Informationen können sie nicht kennen, wenn sie nicht in den Trainingsdaten enthalten sind
    • Das war erstaunlich nah an meiner idealen Sprache
      Das Tooling für so eine Sprache weiterzuentwickeln, wäre vermutlich ein echtes Vergnügen
    • Hast du versucht, sie direkt auf BEAM-Bytecode kompilieren zu lassen?
    • Beeindruckend. Mich würde aus Anfängersicht interessieren, ob sie leichter zu lernen ist als andere Forth-artige Sprachen

  • Ich halte OCaml nach wie vor für die beste Wahl
    Starkes Typsystem (inklusive GADT), Fokus auf reine Funktionen, schnelle Build-Zeiten, Unterstützung für WASM/JS-Ziele — es hat viele Vorteile
    Dass Code innerhalb einer Datei in Reihenfolge ausgewertet wird und zyklische Abhängigkeiten explizit behandelt werden müssen, sorgt ebenfalls für Stabilität
    Vor allem aber ist es auch für Menschen eine Sprache, mit der das Schreiben Spaß macht

    • Mich würde interessieren, wie es heute bei Multicore und asynchroner Verarbeitung aussieht
      Früher war F# in dem Bereich weiter
    • Der OCaml-Compiler ist außergewöhnlich gut beim Finden von Bugs
      Selbst wenn ein Agent versehentlich Fehler einbaut, werden die meisten erkannt
    • Ich würde statt Go eher OCaml empfehlen. Dank des ausdrucksstarken Typsystems sind dort Abstraktionen möglich, die in Go nicht machbar sind
    • Wenn das so ist, wäre dann nicht eher F# die bessere Wahl?

  • Unter PHP, Go, JavaScript und Python ist Go zwar besser, aber das ist noch kein starkes Argument dafür, dass es die „beste Sprache“ ist

    • Ich bevorzuge Rust. Die Compiler-Feedback-Schleife ist hervorragend, auch wenn die Syntax etwas ausführlich ist
      Gos Einfachheit und sein ausreichend gutes Typsystem sind aber ebenfalls attraktiv
    • Entscheidend ist auch, dass Go die einzige von dir genannte kompilierte Sprache ist

  • Siehe auch die kürzlich diskutierte Frage "Why Elixir is the best language for AI"
    Die Runtime-Introspection von BEAM ist in Agenten-Umgebungen ein interessanter Punkt

  • Für Go gibt es das Tool govulncheck, das Schwachstellen in Code und Binärdateien statisch analysiert
    Wie im offiziellen Tutorial gezeigt, ist es tief in das Go-Ökosystem integriert und stärker eingebunden als in anderen Sprachen

    • Ich weiß nicht genau, worin der Unterschied zu Rusts cargo-audit besteht
      Ich bin mir nicht sicher, ob govulncheck tatsächlich Schwachstellen im eigentlichen Code analysiert
    • govulncheck sucht nicht nach Schwachstellen im Code selbst, sondern analysiert, ob verwundbare Abhängigkeiten tatsächlich verwendet werden
      Dass es sogar Call Paths verfolgt, ist ein Vorteil, aber es ist etwas anderes als echte statische Analysewerkzeuge wie Coverity
      In Go kommen Community-Tool-Sammlungen wie golangci-lint dem eher nahe
    • Trotzdem sind Integrationsgrad und Benutzerfreundlichkeit von govulncheck anderen Sprachen überlegen und bei der Wartung großer Projekte sehr hilfreich

  • Ich habe Projekte in mehreren Sprachen neu geschrieben, und Python passte am besten zu Claude
    Der Code war klein und leicht verständlich, wodurch die Arbeit deutlich schneller voranging
    Ich habe auch Go, Kotlin und JavaScript ausprobiert, bin am Ende aber bei Python geblieben

    • Mich würde interessieren, ob in dem Python-Code Exception Handling oder pass-Anweisungen sauber behandelt wurden

  • Go ist keine schlechte Wahl. Die Trainingsdaten sind reichhaltig, und die APIs sind stabil, was LLMs die Arbeit erleichtert
    Aber ich denke, Rust ist wegen seines Typsystems noch besser
    Allerdings entwickelt sich Rust schnell weiter, sodass LLMs Schwierigkeiten haben können, mit den neuesten APIs Schritt zu halten
    Haskell ist wegen des langsamen Wandels und des sicheren Codes womöglich am vorteilhaftesten für LLMs

    • In Haskell erzeugter Code wäre vermutlich kürzer und lesbarer als in Go
      Python-Skripte sind ähnlich gut lesbar

  • Aus der Perspektive von jemandem, der täglich mit AI-Coding-Agenten arbeitet, hängt die „beste Sprache“ vom Zweck des Agenten ab
    Gos Einfachheit und Vorhersehbarkeit sind gut für allgemeine Aufgaben, aber TypeScript ist bei der Integration in Web-Umgebungen hervorragend
    Python bleibt im Daten-/ML-Bereich weiterhin ohne echte Konkurrenz
    Entscheidend ist nicht die Sprache, mit der LLMs am besten umgehen, sondern die Sprache, die zur Domäne des Agenten passt