J’ai regardé une interview très intéressante On ne paie plus les développeurs pour écrire du code avec Quentin Adam de Clever Cloud sur la façon dont ils utilisent des agents IA en interne.
Je suis largement d’accord avec lui, et j’ai publié sur X après avoir regardé la vidéo dans le train. Mais un tweet n’est pas assez long pour expliquer complètement une idée, alors j’écris ça ici !
À un moment dans la vidéo, il explique pourquoi il pense que Rust fonctionne particulièrement bien avec les LLM. Son argument est que plus un langage est contraignant, plus les retours du compilateur sont utiles pour l’agent. Rust est très bon pour cela, donc l’agent peut écrire du code, exécuter le compilateur, lire les messages d’erreur de rustc, corriger et continuer jusqu’à ce que tout soit vert.
La distinction est intéressante car je ne généraliserais pas sur l’usage de Rust et que des compilateurs plus stricts signifient toujours un meilleur langage pour les agents IA. Je n’écris pas en Rust, donc ce qui suit porte sur ce qu’un compilateur réponds à un agent, pas sur l’expérience d’écrire du Rust au quotidien (et les agents s’en moquent, ils écrivent du code de toute façon).
Rust est un oracle incroyable puisque le compilateur voit des choses que le compilateur Go ne peut pas voir. Des erreurs d’ownership, invalid borrowing, des problèmes de concurrence, correspondance exhaustive quand un enum change (ce serait bien d’avoir ça dans Go, en fait ce serait bien d’avoir de vrais enums, lol). Si un agent ajoute une nouvelle entrée à un enum, rustc peut lui donner une liste d’endroits qui doivent maintenant être corrigés et c’est super précieux quand on laisse un agent refactoriser du code de façon autonome.
La qualité des erreurs du compilateur compte aussi. Rust est connu pour avoir un compilateur qui explique pourquoi il est mécontent et souvent avec de très bonnes suggestions, c’est presque fait pour un LLM. Le modèle n’a pas besoin de comprendre profondément les ownership comme le ferait un développeur Rust expérimenté (peut-être que oui). Il peut lire le diagnostic et changer quelque chose, exécuter cargo check à nouveau et progressivement se rapprocher d’un code qui compile.
Dans la vidéo, Quentin dit aussi que Go a un compilateur très détendu, à mettre presque dans le même panier que JavaScript. C’est peut-être un peu trompeur 😋. Go est typé statiquement, le compilateur refusera les conversions implicites débiles, les mauvaises signatures, les incompatibilités d’interface et tout ça.
Le langage en demande moins au programmeur, par ex. la gestion mémoire est le problème du garbage collector. Le langage a beaucoup moins de concepts et d’abstractions, et moins de façons ingénieuses d’exprimer la même chose. Ça peut être frustrant pour les humains venant de langages plus riches, mais je pense que ça devient presque une feature quand le programmeur est un agent. Moins de concepts signifie moins de décisions de conception à se tromper à la première ébauche, et moins d’itérations passées à revisiter une décision.
Pour moi la convergence est au moins aussi intéressante que la rigueur du compilateur quand on parle de développement agentique. La meilleure boucle de rétroaction n’est pas nécessairement celle qui produit le message d’erreur le plus sophistiqué. Cela peut aussi être celle qui permet à l’agent d’atteindre une solution correcte et compréhensible avec peu d’itérations.
Rust prouve des choses que Go ne peut pas prouver comme les data races, les références non nulles et la correspondance exhaustive, mais il ne prouve rien sur les deadlocks et la logique métier (deux mutex acquis dans le mauvais ordre compilent toujours correctement AFAIK), et que ce soit en Rust ou en Go un agent écrivant un test après avoir écrit un bug sera tout content de le faire 😎.
Je serai toujours fan de cette citation de Rich Hickey dans Simple Made Easy:
What’s true of every bug found in the field?
It passed the type checker.
What else did it do?
It passed all the tests.
Comme je l’ai déjà dit dans un précédent post, Go a un écosystème simple et ennuyeux, qui fonctionne, et le langage est super stable. Rust est aussi très stable, mais son écosystème est plus riche et peut exposer les agents à plus d’APIs changeantes, surtout une fois que des crates externes sont utilisées (voir ce benchmark). Pour un LLM entraîné sur des années de code source public, la cohérence est utile (Quentin en parle aussi dans la vidéo), le fait que du code ancien soit toujours valide réduit la confusion.
Les agents ne valident pas le code une seule fois, ils vérifient le projet, exécutent un test ciblé, changent le code, exécutent des tests et enfin construisent le binaire. Rust a cargo check et cargo réutilisera les compilations précédentes mais les tests doivent quand même compiler leurs cibles d’abord. Sur des projets qui grossissent ça s’additionne. Go met en cache agressivement, y compris les résultats de test réussis, par exemple package inchangé est affiché comme (cached) au lieu de s’exécuter à nouveau, tandis que cargo test relance les tests. Dans Go, la boucle édition/construction/test est donc très bon marché.
Cela ne rend pas Go “meilleur que Rust pour l’IA”. Chez Clever Cloud, ils travaillent sur leur propre système de base de données, des composants de niveau noyau, et des logiciels pour des switch réseaux, donc ils aimeront tout ce qui a autant de sécurité mémoire et de correction de concurrence que possible. Mais la plupart des logiciels développés ne sont pas de ce genre, par ex. pour les services HTTP, les CLI et les outils internes, et beaucoup de logiciels backend plus ordinaires, Go donne à un agent un environnement très attractif.
Rust donne à l’agent un oracle plus fort tandis que Go lui donne probablement un problème plus facile à gérer.
Je pense que les deux approches fonctionneront très bien pour la programmation agentique, pour plein de raisons. Quand le programmeur est un agent IA capable de réessayer immédiatement, la capacité de converger rapidement compte aussi beaucoup.
À la prochaine !