Go: O que acertamos, o que erramos

O nicho pretendido do Go e no que ele se tornou

• Projetado no Google como um substituto mais simples e mais rápido para C++ em servidores e “software de sistemas” (num sentido amplo: servidores, redes, infraestrutura), não para kernels ou drivers.
• Vários comentaristas dizem que o Go acabou se tornando mais uma linguagem de “servidor / backend da internet” e de CLI do que uma linguagem de sistemas de baixo nível.
• Alguns argumentam que ele substituiu com sucesso muito de C++ e parte de Python em trabalho de servidor/infraestrutura; outros dizem que ele compete mais com Java/C# do que com C/C++/Rust.

Computação científica, FFI e HPC

• Diz-se que a equipe inicial do Go descartou casos de uso científicos/HPC, REPLs e integração com linguagens de scripting; isso é visto como uma oportunidade perdida.
• cgo e a sobrecarga de chamadas C do compilador gc são amplamente criticados; o Go é visto como tendo uma história fraca de FFI, especialmente para computação científica, onde a interoperabilidade com C/Fortran é crucial.
• Contraponto: a maior parte do trabalho científico é scripting em Python/R/Julia; o Go, como linguagem de sistemas, não é uma escolha natural de qualquer forma.

Concorrência e goroutines

• Goroutines são descritas como “green threads” em espaço de usuário ou M:N scheduling com fibras com stack em cima de threads do sistema operacional; boas para servidores com alta concorrência.
• Alguns acham que o Go vendeu demais as goroutines como algo novo; outros as veem como um modelo prático e bem-sucedido, apesar de semelhante a sistemas mais antigos de green threads.
• Esse modelo de concorrência complica o FFI em C e influencia o design do runtime (por exemplo, não haver geração de código em tempo de execução).

Tratamento de erros, panics e nil

• Errors as values mais panics é uma das áreas mais contestadas:
  • Críticos: padrões verbosos e repetitivos de if err != nil, facilidade de engolir erros por acidente, dois mecanismos paralelos (erros vs panics) que não se encaixam bem, e tratamento doloroso de nil (incluindo as armadilhas de nil em interface versus concreto).
  • Defensores: erros explícitos são simples e previsíveis, incentivam o tratamento e evitam fluxo de controle oculto.
• Ponteiros nil e a falta de segurança contra null são citados como grandes erros de design; algumas ferramentas (por exemplo, linters, analisadores de nil) tentam mitigar isso.

Generics e sistema de tipos

• O longo atraso para adicionar generics é muito debatido:
  • Pró: esperar evitou designs defeituosos que teriam sido difíceis de corrigir depois.
  • Contra: lançar sem generics repetiu erros antigos (por exemplo, Java antes de generics), deformou APIs e forçou gambiarra (interface{} em todo lugar).
• Os generics atuais são vistos como úteis, mas incompletos (por exemplo, faltam generics no nível de método), e limitados pela semântica existente de interfaces.

Modules, empacotamento e ferramentas

• O comportamento inicial de GOPATH/go get e a importação por URL são criticados como ingênuos e excessivamente ajustados ao monorepo do Google; gerenciadores de pacotes da comunidade surgiram para preencher a lacuna.
• Os modules oficiais e o MVS são, em geral, elogiados como uma grande melhoria, embora SIV (v2+), repositórios privados e configuração de SSH/git ainda sejam pontos problemáticos.
• gofmt, ferramentas unificadas (go build/test/fmt), binários estáticos e compilação relativamente rápida são amplamente vistos como grandes pontos fortes.

Processo da comunidade e evolução

• Alguns veem a liderança do Go como excessivamente dismissiva/lenta em questões como generics, tempo monotônico, atualizações de crypto, REPLs e uso de context.
• Outros elogiam a disposição de dizer “não”, manter a linguagem pequena e priorizar estabilidade e ferramentas em vez de rápida adição de recursos.