23 pontos por GN⁺ 2026-03-04 | 3 comentários | Compartilhar no WhatsApp
  • A simplicidade da linguagem Go e suas características de compilação aumentam a estabilidade do código gerado por agentes de IA e a eficiência de execução
  • Graças à tipagem estática e à alta velocidade de compilação, os agentes conseguem validar erros de código rapidamente e executar iterações com eficiência
  • Ferramentas padronizadas no nível da linguagem (gofmt, testes, build) incentivam os agentes a gerar código consistente
  • O build de binários multiplataforma é suportado nativamente, permitindo que agentes em segundo plano validem e executem o mesmo código de forma distribuída em diferentes sistemas operacionais
  • Por essas características, Go é visto como uma linguagem com equilíbrio entre produtividade, simplicidade e desempenho, surgindo como uma forte opção para desenvolvimento baseado em agentes de IA

Vantagens de Go ser uma linguagem compilada

  • Os agentes geram grandes volumes de código, e a maior parte desse código apenas "parece plausível", então verificar se ele realmente funciona é o desafio central
  • Ao usar uma linguagem compilada, é possível eliminar em tempo de compilação certas categorias de bugs, como tipos incorretos ou uso errado de argumentos, por meio de um sistema de tipagem forte e estática
  • Se a compilação for bem-sucedida, obtém-se a garantia de que o código está sintaticamente correto dentro do padrão da linguagem
  • Em comparação com Rust, por que Go é mais adequado para agentes:
    • A sintaxe e os conceitos de Go são mais simples do que os de Rust
    • O sistema de tipos de Go é menos sofisticado que o de Rust, então o código gerado tende a ficar mais próximo do estilo idiomático e mais fácil de entender por humanos
    • A compilação de Go é mais rápida que a de Rust, encurtando o ciclo de feedback dos agentes
    • mais código Go nos dados de treinamento do que código Rust, então os modelos geram código Go melhor

A simplicidade de Go

  • Se você já tem familiaridade com qualquer linguagem de programação, consegue ler código Go e entender seu funcionamento imediatamente, porque a própria linguagem é simples
  • Mesmo que os agentes gerem grandes quantidades de código Go, os desenvolvedores não têm grande dificuldade para acompanhar esse código
  • Quando os agentes às vezes tomam decisões de design estranhas e continuam naquela direção, a simplicidade da linguagem facilita entender para onde eles estão indo
  • Daqui a 12 meses, talvez a necessidade de ler código diretamente diminua, o que pode reduzir a importância de legibilidade e simplicidade, mas ainda assim é valioso manter a opção de inspecionar o código quando necessário

A padronização de Go

  • Go é uma linguagem opinionated, com diretrizes e ferramentas claras, e existe uma forma padrão de executar testes, formatar código e gerar binários
  • O tratamento de erros também divide opiniões, mas oferece um padrão estabelecido, incentivando a escrita de código idiomático que facilita o trabalho conjunto entre várias pessoas e agentes
  • Em contraste com JavaScript: cada projeto JS usa ferramentas diferentes, e há opiniões dispersas sobre formatação de código, publicação de pacotes e formas de importar bibliotecas, o que é ineficiente para agentes
  • Graças à padronização de Go, os modelos conseguem gerar código Go idiomático de forma consistente com base nos dados de treinamento
    • Se você pedir a um agente para formatar código JavaScript, ele pode tentar instalar e configurar uma nova ferramenta; em Go, basta executar gofmt
    • Escrever testes unitários ou gerar binários também segue o mesmo padrão

Build de binários multiplataforma

  • Em Go, o suporte multiplataforma é um recurso de primeira classe, especialmente vantajoso para softwares como ferramentas de CLI, em que não é possível controlar o ambiente de execução
  • É possível executar testes unitários e de integração em vários ambientes com o mesmo comando, validando se funcionalidades existentes não foram quebradas
  • A vantagem é ainda maior ao usar agentes em segundo plano:
    • Há uma tendência crescente de se afastar do controle direto sobre o ambiente de build e execução do código, como ao acionar o Cursor por mensagem no Slack ou transferir uma sessão local para um ambiente remoto
    • O código Go gera binários da mesma forma em Linux, Windows e macOS, e todo o processo de trabalho é padronizado entre ambientes, sem a necessidade de se preocupar se o provedor de sandbox oferece suporte às dependências de desenvolvimento

Qualidade do código Go gerado por agentes

  • No início de 2026, a taxa de geração de código Go válido de primeira é de cerca de 95% (número baseado em experiência pessoal, não em dados oficiais)
  • A sensação prática é de que usar agentes com Go traz menos dificuldades do que com Python
  • Os modelos aprenderam suficientemente bem as bibliotecas, padrões e boas práticas de Go, de modo que, quando recebem uma direção, a implementação funcional fica quase trivial
  • O volume total de dados de treinamento de Go pode ser menor que o de Python, mas em Python há 20 formas diferentes de fazer a mesma tarefa; olhando por biblioteca específica, isso faz com que a densidade de dados de treinamento de Go seja efetivamente maior
  • Com a melhora do desempenho dos modelos e a expansão dos dados de treinamento, essa vantagem pode desaparecer com o tempo

Por que o projeto Bruin escolheu Go

  • Bruin é uma ferramenta de ETL open source, principalmente um utilitário de CLI escrito em Go
  • Embora Python fosse dominante no ecossistema de dados, as principais restrições que levaram à escolha de Go foram:
    • Como ferramenta de orquestração de dados, o processamento concorrente é essencial
    • Como precisa interagir com vários sistemas, como runtimes de linguagem e APIs externas de plataformas de dados, é necessário um ecossistema suficientemente maduro
    • Como ferramenta de CLI, era indispensável desempenho suficiente para uso em extensões do VS Code ou como backend de UI local
    • Era necessário um tratamento de erros previsível para integração com diferentes sistemas
    • Como roda nas máquinas dos usuários, era importante facilidade de suporte a diferentes sistemas operacionais e arquiteturas
  • Em termos subjetivos, também era necessário que fosse uma linguagem prazerosa para os principais contribuidores trabalharem, e em uma equipe pequena prazer e energia são os recursos mais escassos
  • Apesar da desvantagem de ter menos bibliotecas de dados específicas que Python, a decisão foi guiada pela intuição de que as vantagens de Go em velocidade e experiência do desenvolvedor (DX) trariam mais valor no longo prazo

Conclusão: Go na era dos agentes

  • As linguagens de programação estão avançando para uma era em que humanos não escrevem código diretamente
  • Agora é necessário um sistema que permita aos agentes escrever código com eficiência
  • Go oferece um ambiente ideal para agentes de IA escreverem e executarem código graças ao seu equilíbrio entre usabilidade, desempenho e universalidade
  • Com Go, os agentes podem gerar automaticamente software de alto desempenho que pode ser compilado, testado, formatado e implantado em diferentes máquinas
  • Ainda é incerto se Go será a linguagem definitiva para agentes ou se surgirá uma alternativa mais adequada, mas,
    no momento, a equipe está obtendo resultados sólidos em produtividade e qualidade de software

3 comentários

 
mammal 2026-03-05

Antes de tudo, gosto porque a compilação é rápida.

 
tsboard 2026-03-05

A linguagem Go realmente tem um conceito muito bem definido, e acho que acaba sendo uma boa escolha para quem se encaixa bem nesse conceito claro. Eu também fazia back-end com runtime de JS e depois migrei para Go, e acho que posso dizer com confiança que, em termos de desempenho e produtividade no desenvolvimento, estou bem satisfeito com ela.

 
GN⁺ 2026-03-04
Comentários do Hacker News
  • Há mais de 9 meses trabalho com consultoria e continuo confirmando que Go é muito adequado para geração de código com LLM
    Go oferece um sistema de build consistente, formatter, tipagem estática e concorrência baseada em CSP sem as partes perigosas de C++
    Há mais de 10 anos não houve versões que quebrassem compatibilidade, e quase não há mudanças de framework
    Quando aconselho equipes na Sancho Studio a adotar agentic coding workflow, Go produz resultados muito estáveis no Claude e no Codex
    Em contrapartida, Python e TypeScript têm frameworks e abordagens de tipos tão variados que fica difícil para um LLM gerar saídas consistentes
    Na verdade, o motivo de eu não gostar de Go antes — suas limitações de abstração — acaba sendo uma vantagem para LLMs
    O novo go fix do Go 1.26 oferece refatoração automática no nível de AST e mantém a base de código atualizada
    No passado construí uma PKI em Go no projeto Zoom E2E Whitepaper, e agora, com o LLM cuidando do boilerplate repetitivo, a simplicidade de Go realmente mostra seu valor

    • Acho que a maior parte desses argumentos também se aplica a Java
      Java tem mais dados de treinamento e um sistema de tipos mais forte, o que também ajuda na validação da saída do LLM
    • Concordo totalmente. Usei C++ por mais de 20 anos, mas acho que Golang é a melhor linguagem para a maioria dos fluxos de trabalho que não envolvem controle em tempo real ou embarcados
    • Concordo profundamente com a frase “as limitações de abstração de Go são uma vantagem para LLMs”
      Eu prefiro ambientes low-level, e gosto da pilha rasa de abstrações e da estrutura previsível de Go
      No fim, simplicidade e consistência funcionam bem tanto para LLMs quanto para desenvolvedores como eu
    • Vendo a qualidade recente do código gerado por LLMs, a variável maior é a complexidade da definição do problema, mais do que a linguagem
      Linguagens padronizadas como Go facilitam entender o resultado, mas Ruby e C++ também saem bastante bem
      Lisp e Bash têm tanta liberdade que os resultados ficam irregulares
    • Você pode estar enviesado por Go, mas eu tenho mais experiência com TypeScript, então vejo de outro jeito
      Colocar Python e TypeScript na mesma categoria não é preciso
      Python confunde LLMs por causa de quebras entre versões e da adoção lenta de tipos, mas TypeScript é muito mais consistente
      Se surgir a oportunidade, eu adoraria fazer um duelo de código ao vivo Go vs TypeScript
  • No desenvolvimento de agentes, acho bom mover o máximo possível de validação para o tempo de compilação
    Go é aceitável, mas seu sistema de tipos não é tão poderoso quanto o de outras linguagens
    Rust é muito útil no sentido de que, se você passou pelos erros do compilador, quase não há erros em runtime
    Haskell provavelmente seria ainda melhor

    • Um dos motivos de Rust ser bom é que o código de teste fica no mesmo arquivo
      Quando o agente altera o código-fonte, ele atualiza os testes junto
      Em outras linguagens é fácil esquecer os testes
    • Haskell também é excelente, mas LLMs tendem a empilhar abstrações demais
      Estou criando uma linguagem de brinquedo baseada em tipos dependentes sobre Haskell, e a sintaxe simples faz com que LLMs lidem melhor com ela
      Internamente ela funciona como Rust seguro/inseguro
    • Meu voto vai para Rust. Acho certa a estratégia de assumir a complexidade no começo e reduzir o custo operacional
      Como não somos nós que vamos escrever diretamente, tudo bem se for um pouco incômodo
    • Eu também gosto de usar Rust, e a interoperabilidade entre linguagens é excelente
      Dá para combiná-lo com TypeScript para fazer uma SPA, criar um app multiplataforma com Tauri ou acoplar um sidecar em Python
      Também estou experimentando jogos com Bevy, e gosto da estrutura ECS
      Consegui reunir as vantagens de várias linguagens evitando seus pontos fracos
    • Fico curioso se alguém já experimentou linguagens de alto nível como Haskell ou Prolog com LLMs em 2025
  • Durante alguns dias, pedi ao Gemini, Claude Code e Codex: “projetem a linguagem que vocês querem”
    O resultado foi uma linguagem estilo Forth, com sistema de tipos forte, contratos, testes nativos, fuzz testing e um solucionador de restrições baseado em Z3
    Implementei o interpretador em Elixir e publiquei como o projeto Cairn
    A linguagem, feita em cerca de 150 commits, funcionou sem erros de runtime
    Esse experimento mostra a importância da análise em tempo de compilação e das ferramentas de teste

    • É um projeto interessante, mas acho um pressuposto equivocado assumir que LLMs podem projetar uma linguagem vantajosa para si mesmas
      Se essa informação não estiver nos dados de treinamento, elas não têm como saber
    • Fiquei surpreso porque isso quase coincide com a minha linguagem ideal
      Desenvolver o tooling de uma linguagem assim realmente parece algo muito divertido
    • Fico curioso se você tentou fazer com que ela compilasse diretamente para bytecode da BEAM
    • Impressionante. Do ponto de vista de um iniciante, também fico curioso se ela é mais fácil de aprender do que outras linguagens da família Forth
  • Ainda acho que OCaml é a melhor escolha
    Há muitas vantagens: sistema de tipos forte (incluindo GADT), foco em funções puras, builds rápidos e suporte a WASM/JS como alvo
    O fato de o código ser avaliado na ordem em que aparece no arquivo, exigindo tratamento explícito de dependências cíclicas, também traz estabilidade
    Acima de tudo, é uma linguagem agradável para humanos escreverem

    • Fico curioso sobre como estão hoje multicore e processamento assíncrono
      Antigamente F# estava à frente nisso
    • O compilador de OCaml é excelente em detectar bugs
      Mesmo que o agente introduza um bug por engano, ele pega a maioria deles
    • Recomendo OCaml no lugar de Go. Graças ao sistema de tipos expressivo, é possível criar abstrações que Go não permite
    • Nesse caso, talvez não fosse melhor usar F#?
  • Entre PHP, Go, JavaScript e Python, Go é melhor, mas isso não sustenta muito bem a afirmação de que seja “a melhor linguagem”

    • Eu prefiro Rust. O loop de feedback do compilador é excelente, mas a sintaxe é verbosa
      A simplicidade de Go e seu sistema de tipos suficientemente bom também são atraentes
    • É importante que Go seja a única linguagem compilada entre as que você mencionou
  • Vale consultar a discussão recente "Why Elixir is the best language for AI"
    O recurso de introspecção em runtime da BEAM é um ponto interessante em ambientes de agentes

  • Go tem a ferramenta govulncheck para analisar estaticamente vulnerabilidades no código e nos binários
    Como no tutorial oficial, ela é profundamente integrada ao ecossistema Go e tem um nível de integração maior do que em outras linguagens

    • Não entendo bem qual é a diferença em relação ao cargo-audit do Rust
      Fico em dúvida se o govulncheck realmente analisa vulnerabilidades no código em si
    • O govulncheck não procura vulnerabilidades no código em si, e sim uso vulnerável de bibliotecas de dependência
      Rastrear até o caminho de chamada é uma vantagem, mas ele não é como ferramentas de análise estática de verdade, como o Coverity
      Em Go, algo mais próximo seria um pacote de ferramentas da comunidade como golangci-lint
    • Ainda assim, o nível de integração e usabilidade do govulncheck é superior ao de outras linguagens, o que ajuda muito na manutenção de projetos grandes
  • Reescrevi projetos em várias linguagens e Python foi o que melhor funcionou com o Claude
    Como o código era pequeno e fácil de entender, a velocidade de trabalho foi muito maior
    Tentei Go, Kotlin e JavaScript também, mas no fim fiquei com Python

    • Fico curioso se ele lidou corretamente com tratamento de exceções ou instruções pass no código Python
  • Go não é uma escolha ruim. Há muitos dados de treinamento e as APIs são estáveis, então LLMs lidam bem com ele
    Mas acho que Rust é melhor por causa do sistema de tipos
    Só que Rust muda rápido, então fica difícil para LLMs acompanhar as APIs mais recentes
    Haskell é o mais favorável para LLMs graças ao ritmo lento de mudanças e ao código seguro

    • Acho que o código gerado em Haskell seria mais curto e com maior legibilidade do que em Go
      Scripts em Python também tendem a ser fáceis de ler
  • Como alguém que trabalha todos os dias com agentes de programação de IA, a “melhor linguagem” depende do objetivo do agente
    A simplicidade e a previsibilidade de Go são boas para tarefas gerais, mas TypeScript é excelente na integração com ambientes web
    Python continua incomparável na área de dados/ML
    O ponto principal não é escolher a linguagem que o LLM domina melhor, e sim a linguagem adequada ao domínio do agente