Go est le meilleur langage pour les agents IA

• La simplicité du langage Go et ses caractéristiques de compilation améliorent la fiabilité du code généré par les agents IA ainsi que son efficacité d’exécution
• Grâce au typage statique et à la rapidité de compilation, les agents peuvent valider rapidement les erreurs de code et itérer efficacement
• Les outils standardisés au niveau du langage (gofmt, tests, build) favorisent une génération de code cohérente par les agents
• La compilation de binaires multiplateformes est prise en charge nativement, ce qui permet aux agents en arrière-plan de vérifier et d’exécuter le même code de façon distribuée sur différents OS
• Grâce à ces caractéristiques, Go est considéré comme un langage équilibré entre productivité, simplicité et performance, et s’impose comme un choix de plus en plus pertinent pour le développement fondé sur des agents IA

---

Les avantages de Go en tant que langage compilé

• Les agents génèrent de grandes quantités de code, dont une grande partie se contente d’« avoir l’air plausible » ; la question essentielle est donc de vérifier si ce code fonctionne réellement
• Avec un langage compilé, un système de typage fort et statique permet d’éliminer dès la compilation certaines catégories de bugs, comme les erreurs de type ou les mauvais arguments
• Si la compilation réussit, on obtient la garantie que le code est syntaxiquement correct dans le cadre du standard du langage
• Pourquoi Go est mieux adapté aux agents que Rust :
  • La syntaxe et les concepts de Go sont plus simples que ceux de Rust
  • Le système de types de Go est moins sophistiqué que celui de Rust, ce qui rend le code généré plus proche des usages idiomatiques et plus facile à comprendre pour les humains
  • La compilation de Go est plus rapide que celle de Rust, ce qui raccourcit la boucle de feedback des agents
  • Davantage de code Go est présent dans les données d’entraînement que de code Rust, ce qui permet aux modèles de produire un meilleur code Go

La simplicité de Go

• Quiconque connaît déjà un langage de programmation peut lire du code Go et en comprendre immédiatement le comportement tant le langage lui-même est simple
• Même si les agents génèrent de grandes quantités de code Go, les développeurs n’ont pas trop de mal à suivre
• Quand un agent prend parfois des décisions de conception étranges et continue dans cette direction, la simplicité du langage permet de comprendre facilement où il va
• D’ici 12 mois, il est possible qu’on lise moins souvent le code soi-même, ce qui pourrait réduire l’importance de la lisibilité et de la simplicité ; mais garder la possibilité de vérifier le code directement reste précieux si nécessaire

L’approche standardisée de Go

• Go est un langage opinionated, avec des règles et outils clairs ; il existe des façons standard d’exécuter les tests, de formater le code et de construire des binaires
• La gestion des erreurs peut diviser les avis, mais elle fournit un modèle établi qui encourage l’écriture d’un code idiomatique, pratique pour le travail collaboratif entre plusieurs personnes et agents
• Par contraste avec JavaScript : chaque projet JS utilise des outils différents, et les avis divergent sur le formatage, la publication de packages ou l’import de bibliothèques, ce qui est inefficace pour les agents
• Grâce à la standardisation de Go, les modèles peuvent générer de façon cohérente du code Go idiomatique à partir des données d’entraînement
  • Si on demande à un agent de formater du code JS, il essaiera d’installer et configurer un nouvel outil ; avec Go, il suffit d’exécuter gofmt
  • L’écriture de tests unitaires et la compilation de binaires sont standardisées de la même manière

La compilation de binaires multiplateformes

• Dans Go, le support multiplateforme est un citoyen de première classe, ce qui est particulièrement avantageux pour les logiciels, comme les outils CLI, dont on ne contrôle pas l’environnement d’exécution
• Il est possible d’exécuter les tests unitaires et d’intégration avec la même commande sur plusieurs environnements pour vérifier qu’aucune fonctionnalité existante n’a été cassée
• Cet avantage est encore plus fort avec les agents en arrière-plan :
  • La tendance est de se détacher progressivement du contrôle direct sur les environnements de build et d’exécution du code, qu’il s’agisse de déclencher Cursor depuis un message Slack ou de transférer à distance une session locale
  • Le code Go produit les mêmes binaires sur Linux, Windows et macOS, et l’ensemble du processus de travail est standardisé d’un environnement à l’autre, ce qui évite de se soucier du support des dépendances de développement chez les fournisseurs de sandbox

Qualité de génération du code Go par les agents

• Début 2026, le taux de génération de code Go valide du premier coup est d’environ 95 % (estimation fondée sur une expérience personnelle, pas sur des données officielles)
• L’usage d’agents avec Go semble poser moins de difficultés qu’avec Python
• Les modèles ont suffisamment appris les bibliothèques, patterns et bonnes pratiques de Go pour que, avec une bonne direction, l’implémentation des fonctionnalités devienne presque fluide
• Le volume total de données d’entraînement sur Go est peut-être inférieur à celui de Python, mais Python propose 20 façons différentes d’accomplir une même tâche ; rapporté à une bibliothèque donnée, Go bénéficie donc d’une densité d’apprentissage plus élevée
• Cet avantage pourrait disparaître avec le temps, à mesure que les performances des modèles progressent et que les données d’entraînement augmentent

Pourquoi le projet Bruin a choisi Go

• Bruin est un outil ETL open source, principalement écrit en Go sous la forme d’un outil CLI
• Même si Python domine dans l’écosystème data, les principales contraintes qui ont conduit au choix de Go étaient :
  • En tant qu’outil d’orchestration de données, la gestion de la concurrence est essentielle
  • Il faut un écosystème suffisamment riche pour interagir avec de nombreux systèmes, qu’il s’agisse du runtime du langage, de plateformes de données ou d’API externes
  • En tant qu’outil CLI, il faut des performances suffisantes pour servir aussi de base à une extension VS Code ou à un backend d’interface locale
  • Il faut une gestion des erreurs prévisible pour intégrer de nombreux systèmes différents
  • Comme l’outil s’exécute sur les machines des utilisateurs, il doit être facile de prendre en charge de multiples OS et architectures
• Sur un plan plus subjectif, le langage devait aussi être agréable à utiliser pour les principaux contributeurs ; dans une petite équipe, le plaisir et l’énergie sont les ressources les plus rares
• Malgré l’inconvénient d’un manque de certaines bibliothèques data par rapport à Python, le choix s’est imposé par intuition : les avantages de Go en matière de vitesse et d’expérience développeur (DX) apporteraient davantage de valeur à long terme

Conclusion : Go à l’ère des agents

• Les langages de programmation entrent dans une époque où les humains n’écrivent plus directement le code
• Il faut désormais des systèmes capables d’aider les agents à écrire du code efficacement
• Go offre, grâce à son équilibre entre ergonomie, performance et universalité, un environnement idéal pour que des agents IA écrivent et exécutent du code
• Les agents peuvent générer automatiquement en Go des logiciels performants pouvant être compilés, testés, formatés et déployés sur diverses machines
• Il reste incertain que Go devienne le langage ultime pour les agents, ou qu’un langage plus adapté émerge,
  mais l’équipe obtient déjà des résultats très satisfaisants en matière de productivité et de qualité logicielle

[mammal]

Déjà, j’aime bien le fait que la compilation soit rapide.

[tsboard]

Le langage Go a vraiment un concept très clair, et j’ai l’impression que cela en fait un bon choix pour les personnes à qui cette philosophie correspond bien. Moi aussi, je suis passé d’un backend construit avec un runtime JS à Go, et je pense pouvoir dire avec confiance que je suis satisfait, tant en termes de performances que de productivité de développement.

[GN⁺]

Réactions sur Hacker News

• Cela fait plus de 9 mois que je fais du conseil, et je constate en continu que Go est particulièrement bien adapté à la génération de code par les LLM
  Go offre un système de build cohérent, un formateur, du typage statique, ainsi qu’une concurrence basée sur CSP sans les aspects dangereux de C++
  Il n’y a pas eu de version cassant la compatibilité depuis plus de 10 ans, et les changements de framework sont quasi inexistants
  Quand je conseille à des équipes chez Sancho Studio d’adopter un workflow de coding agentique, Go produit des résultats très stables avec Claude ou Codex
  À l’inverse, Python ou TypeScript ont trop de variations de frameworks et d’approches de typage pour que les LLM produisent des sorties vraiment cohérentes
  En réalité, ce que je n’aimais pas dans Go — ses limites d’abstraction — devient un avantage pour les LLM
  Le nouveau go fix de Go 1.26 permet un refactoring automatique au niveau de l’AST, ce qui aide à garder la base de code à jour
  J’avais déjà construit une PKI en Go pour le projet Zoom E2E Whitepaper, et maintenant que les LLM prennent en charge le boilerplate répétitif, la simplicité de Go montre toute sa valeur

  • Je pense que la plupart de ces arguments s’appliquent aussi à Java
    Java dispose de davantage de données d’entraînement et d’un système de types plus puissant, ce qui aide aussi à valider les sorties des LLM
  • Totalement d’accord. J’utilise C++ depuis plus de 20 ans, mais Golang me semble être le meilleur langage pour la plupart des workflows hors contrôle temps réel ou embarqué
  • Je suis profondément d’accord avec l’idée que « les limites d’abstraction de Go sont un avantage pour les LLM »
    Je préfère les environnements bas niveau, et j’apprécie la pile d’abstraction peu profonde de Go ainsi que sa structure prévisible
    Au final, simplicité et cohérence conviennent aussi bien aux LLM qu’aux développeurs comme moi
  • Vu la qualité récente du code produit par les LLM, le facteur principal est moins le langage que la complexité de la définition du problème
    Un langage standardisé comme Go rend les résultats faciles à comprendre, mais Ruby ou C++ s’en sortent aussi plutôt bien
    Lisp ou Bash offrent trop de liberté, donc les résultats sont irréguliers
  • Tu es peut-être biaisé en faveur de Go, mais j’ai davantage d’expérience côté TypeScript, donc je vois les choses autrement
    Mettre Python et TypeScript dans la même catégorie n’est pas très exact
    Python perturbe les LLM à cause des ruptures entre versions et de l’introduction lente du typage, alors que TypeScript est bien plus cohérent
    Si l’occasion se présente, j’aimerais bien voir un duel de code en direct Go vs TypeScript

• Pour le développement d’agents, je pense qu’il vaut mieux déplacer un maximum de validations au moment de la compilation
  Go est correct, mais son système de types n’est pas aussi puissant que celui d’autres langages
  Rust est très utile dans la mesure où, une fois les erreurs du compilateur résolues, il reste très peu d’erreurs à l’exécution
  Haskell serait probablement encore meilleur

  • L’un des points forts de Rust, c’est que le code de test se trouve dans le même fichier
    L’agent peut donc mettre à jour les tests en même temps qu’il modifie le code source
    Dans d’autres langages, il est facile d’oublier les tests
  • Haskell est excellent aussi, mais les LLM ont tendance à empiler trop d’abstractions
    Je suis en train de construire au-dessus de Haskell un petit langage à types dépendants, et grâce à sa syntaxe simple, il est facile à manipuler pour les LLM
    En interne, il fonctionne un peu comme Rust safe/unsafe
  • Une voix pour Rust. Je pense que la bonne stratégie consiste à absorber la complexité au départ pour réduire les coûts d’exploitation
    Comme ce n’est pas nous qui l’écrivons directement, un peu d’inconfort n’est pas très grave
  • J’aime aussi beaucoup Rust, notamment pour son excellente interopérabilité entre langages
    On peut le combiner avec TypeScript pour faire une SPA, avec Tauri pour une application multiplateforme, ou lui adjoindre un sidecar Python
    J’expérimente aussi des jeux avec Bevy, et j’aime sa structure ECS
    Cela m’a permis de réunir les avantages de plusieurs langages tout en évitant leurs inconvénients
  • Je me demande si quelqu’un a déjà expérimenté avec des langages de haut niveau comme Haskell ou Prolog en combinaison avec les LLM de 2025

• Pendant quelques jours, j’ai demandé à Gemini, Claude Code et Codex : « concevez le langage que vous voudriez utiliser »
  Le résultat était un langage de style Forth avec système de types fort, contrats, tests natifs, fuzz testing et solveur de contraintes basé sur Z3
  J’ai implémenté l’interpréteur en Elixir et l’ai publié sous la forme du projet Cairn
  Ce langage, créé en environ 150 commits, fonctionnait sans erreur d’exécution
  Cette expérience montre l’importance des analyses à la compilation et des outils de test

  • Projet intéressant, mais je pense que partir du principe qu’un LLM peut concevoir un langage qui lui est favorable repose sur une hypothèse erronée
    Il ne peut pas savoir ce genre de chose si l’information n’existe pas dans ses données d’entraînement
  • J’ai été surpris, car cela correspond presque exactement à mon langage idéal
    Développer l’outillage autour d’un tel langage serait vraiment passionnant
  • Je me demande si tu as essayé de lui faire compiler directement vers du bytecode BEAM
  • Impressionnant. En tant que débutant, je me demande aussi si c’est plus facile à apprendre que d’autres langages de la famille Forth

• Je continue à penser que OCaml est le meilleur choix
  Il a de nombreux atouts : système de types puissant, y compris les GADT, orientation vers les fonctions pures, vitesse de build élevée, prise en charge de cibles WASM/JS, etc.
  Le fait que le code soit évalué dans l’ordre du fichier et qu’il faille gérer explicitement les dépendances circulaires le rend aussi plus robuste
  Surtout, c’est un langage agréable à utiliser pour les humains

  • Je me demande comment ça se passe aujourd’hui pour le multicœur et l’asynchrone
    À une époque, F# était en avance sur ce point
  • Le compilateur OCaml est remarquable pour sa capacité à détecter les bugs
    Même si un agent introduit accidentellement un bug, il en attrape la plupart
  • Je recommanderais OCaml plutôt que Go. Grâce à son système de types expressif, on peut construire des abstractions impossibles à faire en Go
  • Dans ce cas, autant utiliser plutôt F#, non ?

• Entre PHP, Go, JavaScript et Python, Go est préférable, mais cela ne suffit pas à démontrer que c’est « le meilleur langage »

  • Je préfère Rust. La boucle de feedback du compilateur est excellente, même si la syntaxe est verbeuse
    La simplicité de Go et son système de types suffisant ont aussi leur attrait
  • Le point important, c’est que Go est le seul langage compilé parmi ceux que tu as cités

• La discussion récente sur "Why Elixir is the best language for AI" peut aussi servir de référence
  Les capacités d’introspection à l’exécution de BEAM sont un point intéressant dans un environnement d’agents

  • Dans la même veine, il y a aussi "Why Clojure is the best language for AI"
    Cet article critique en particulier Go
  • À noter aussi que, selon l’étude "AutoCodeBench", Go est en retrait par rapport à d’autres langages en performance de génération de code par LLM

• Go dispose aussi de l’outil govulncheck pour analyser statiquement les vulnérabilités dans le code et les binaires
  Comme le montre le tutoriel officiel, il est profondément intégré à l’écosystème Go, davantage que dans beaucoup d’autres langages

  • Je ne vois pas très bien la différence avec cargo-audit pour Rust
    Je me demande si govulncheck analyse réellement les vulnérabilités du code lui-même
  • govulncheck ne cherche pas les vulnérabilités dans le code en lui-même, mais analyse si des bibliothèques dépendantes sont utilisées de manière vulnérable
    Le fait qu’il remonte jusqu’aux chemins d’appel est un avantage, mais cela reste différent d’un véritable outil d’analyse statique comme Coverity
    Dans l’écosystème Go, des bundles d’outils communautaires comme golangci-lint s’en rapprochent davantage
  • Malgré tout, le niveau d’intégration et l’ergonomie de govulncheck sont supérieurs à ceux d’autres langages, ce qui aide beaucoup à maintenir de gros projets

• J’ai réécrit des projets dans plusieurs langages, et Python était celui qui convenait le mieux à Claude
  Le code était plus compact et plus facile à comprendre, donc le rythme de travail était bien plus rapide
  J’ai aussi essayé Go, Kotlin et JavaScript, mais j’ai finalement choisi Python

  • Je me demande si, dans le code Python, il gère correctement les exceptions ou les instructions pass

• Go n’est pas un mauvais choix. Les données d’entraînement sont abondantes et les API sont stables, donc c’est facile à manipuler pour un LLM
  Mais je pense que Rust est meilleur grâce à son système de types
  En revanche, Rust évolue vite, donc il est difficile pour un LLM de suivre les API les plus récentes
  Haskell, avec son évolution lente et son code sûr, est probablement le plus favorable aux LLM

  • Le code généré en Haskell serait sans doute plus court et plus lisible qu’en Go
    Les scripts Python sont eux aussi assez faciles à lire

• En travaillant tous les jours avec des agents de coding IA, je dirais que le « meilleur langage » dépend en fait de l’objectif de l’agent
  La simplicité et la prévisibilité de Go sont très utiles pour les tâches générales, mais TypeScript excelle dans l’intégration avec l’environnement web
  Python reste sans équivalent sur le terrain de la data et du ML
  L’essentiel n’est pas de choisir le langage que le LLM manipule le mieux, mais celui qui correspond au domaine de l’agent