Comme chaque année l'équipe Go lance un sondage à destination des développeur Go :
https://go.dev/blog/survey2026-announce
Attention c'est jusqu'au 3 novembre.
Évidement il y a pas mal de questions sur l'utilisation de l'IA, et donc quelqu'un craint son usage pour développer le langage lui-même.
Cameron Balahan, le "product lead" de l'équipe Go lui répond :
(je recopie le commentaire qui est devenu inaccessible sur Reddit sans compte, c'est nouveau).
My real fear is the developers using LLMs to generate code for the Go language itself.
I'm the product lead for the Go team at Google. I just wanted to drop in to say that this will never happen. Contributors are free to use AI but whatever they submit must be 100% verified by the (human) contributor. And then we, the humans on the Go team, review everything line-by-line. If we suspect an unverified AI submission, we discard it.
We think of Go and the Go toolchain as mission-critical software that requires the highest standards of correctness and verification. We also think of its code as instructional material that shows the rest of the world--humans and AI alike--what "good" code looks like. We can't and won't delegate that work to AI.
En résumé les développeurs font bien ce qu'ils veulent avec l'IA tant qu'ils vérifient eux-même 100% du résultat manuellement. Ensuite l'équipe Go va à nouveau vérifier toutes les lignes et éliminer toute suspicion de code non vérifié préalablement.
Ils pensent que Go est utilisé sur des missions critiques et requiert le plus haut niveau d'exactitude et de vérification. Ils pensent également que le code du langage lui-même doit servir d'exemple. Ceci ne sera jamais délégué à une IA.
On a également un passage dans une interview de
- Jonathan Amsterdam, équipe Go, Google
- Roland Shoemaker, responsable de l'équipe Sécurité Go, Google
https://www.youtube.com/watch?v=IUpMUXmF1ug&t=188s (attention y a une traduction automatique qui fait peur).
On dirait qu'ils se sentent un peu obligé de dire qu'ils utilisent les outils IA de Google, mais que finalement pas trop. Ils indiquent qu'il est finalement plus simple d'écrire le code directement plutôt que de relire un code généré à part pour du code jetable. Ils ne l'utilise pas pour la conception, ils pourraient, peut-être, un jour, plus tard (on va pas dire le contraire, on bosse chez Google hein).
# Mon point de vue
Posté par wilk (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Mon point de vue (10 ans que j'utilise ce langage pour des apps métiers sur mesure et du devops) :
Je pense que comme le langage n'évolue pas beaucoup et reste simple et concis ça me semble crédible qu'ils restent très vigilants.
Personnellement j'apprécie énormément la lisibilité du langage, la plupart du temps je lis le code plutôt que la documentation, en particulier le code de la lib standard et le mien. Et de même j'écris plus facilement du code Go que des spécifications à l'intention d'un LLM.
Mes essais n'ont jamais été concluants, code inutilement lourd, libs pas à la bonne version, optimisations décevantes, failles de sécurité sans objet et globalement relecture plus longue que l'écriture.
Ceci dit l'ajout des itérateurs et du code "générique" (y compris dans les méthodes depuis la dernière version) était censé être suffisamment dissuasif à écrire pour n'être utilisé que dans des cas bien spécifiques de librairies. C'est le cas jusqu'à présent. Mais je crains un peu que les IAs ne voient pas la différence en terme de lisibilité et se mettent d'un coup à les utiliser là où ça n'est pas nécessaire et entraîne du code pollué un peu partout, ça se verra en tout cas si c'est le cas.
Les vibecodeurs ont l'air de sauter directement des langages de haut niveaux à Rust sans passer par la case Go. Et bien je souhaite bon courage à la communauté Rust !
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.