Go é uma linguagem ideal para engenharia de software assistida por IA
O Go está sendo promovido como uma linguagem “ideal” para engenharia de software assistida por IA por causa de sua sintaxe simples, biblioteca padrão forte, tempos de compilação rápidos e ferramentas altamente opinativas que facilitam a geração e formatação de código consistente por modelos grandes. Muitos programadores concordam que essas características funcionam bem com agentes de codificação, mas outros argumentam que linguagens mais rígidas e expressivas, como Rust, TypeScript ou Elixir, são mais adequadas porque oferecem garantias estáticas mais fortes e concorrência mais segura — algo crítico quando humanos revisam menos e a IA escreve mais. Entre as linguagens, as pessoas destacam compensações entre rigor e velocidade do compilador, verbosidade e limites de janela de contexto, e maturidade do ecossistema e cobertura de dados de treinamento ao escolher o que combinar com LLMs.
Pontos fortes percebidos do Go para desenvolvimento assistido por IA
- Linguagem simples, pequena, estável, com poucos recursos e convenções fortes. A maior parte do código Go se parece, o que ajuda LLMs a gerá-lo e refatorá-lo de forma previsível.
- Excelente biblioteca padrão e ferramentas:
gofmt,go test/coverage, linters,go fix, manipulação fácil de módulos e ferramentas especializadas (por exemplo, proibir acesso a arquivos, impor verificações de erros). - Compilação incremental rápida fornece ciclos de feedback curtos quando agentes compilam, executam e testam repetidamente.
- Tipagem estática e GC oferecem segurança e desempenho “bons o suficiente” para o uso típico em web/backend sem gerenciamento complexo de tempo de vida.
- Grande base de código existente e APIs estáveis significam que os modelos já viram muito Go idiomático.
- Implantação fácil (binário estático único) e adequação para CLIs e serviços de backend tornam-no uma opção padrão atraente quando os humanos estão principalmente orquestrando agentes.
Críticas e ceticismo sobre o Go como “ideal”
- Muitos veem o artigo como marketing ou “generative engine optimization” em vez de pesquisa baseada em dados; anedotas internas não são evidência sistemática.
- O Go é descrito como verboso e cheio de boilerplate (
if err != nilem todos os lugares, sem tipos de dados algébricos), o que torna a revisão humana de grandes diffs gerados por IA mais difícil. - O sistema de tipos é considerado básico: suporte fraco a invariantes, armadilhas de
nil, interfaces estruturais que são mais difíceis para ferramentas/LLMs rastrearem. - O modelo de concorrência é poderoso, mas fácil de usar de forma incorreta; referências ao estudo da Uber e a implementações bugadas de Raft sugerem que código Go pode ter mais bugs de concorrência, e supostamente LLMs têm dificuldade com Go concorrente não trivial.
- Ferramentas de linting e análise estática podem ser lentas em bases de código grandes; algumas proteções (por exemplo, disciplina com erros, segurança contra
nil) exigem ferramentas e convenções extras.
Rust, TypeScript e outros concorrentes
- Defensores de Rust argumentam que seu compilador rigoroso e rico sistema de tipos são proteções ideais para LLMs: mais erros são capturados em tempo de compilação, concorrência mais segura, código mais denso e expressivo.
- Contraponto: compilação lenta e atrito do borrow checker podem custar tokens e tempo quando agentes iteram; alguns LLMs “escapam” via
unsafeou clonagem excessiva. - TypeScript e C# são citados como boas opções para apps voltados ao usuário ou estilo CRUD, com tooling rico e sistemas de tipos fortes, embora a complexidade do ecossistema JS/TS seja uma desvantagem.
- Elixir/Gleam são mencionados como surpreendentemente fortes em alguns benchmarks de LLM; Python é amplamente usado, mas frequentemente resulta em código gerado por IA bagunçado.
- Vários comentaristas insistem que não existe uma única linguagem “ideal”: a escolha deve depender do domínio, do ecossistema e de quanto você depende de verificações em tempo de compilação versus em tempo de execução e baseadas em testes.