Go run

Artigo original ↗ Discussão no Hacker News ↗

O comando `go run` do Go é apresentado como um exemplo de como ferramentas simples podem fazer uma linguagem compilada parecer quase script-like, especialmente com convenções como `go run .` e busca automática de dependências. Os comentaristas contrastam isso com os ecossistemas de JavaScript/TypeScript, onde múltiplos runtimes, sistemas de módulos e gerenciadores de pacotes podem tornar tarefas básicas mais complexas, embora ferramentas mais novas como Deno e Bun tentem reduzir essa distância. A conversa destaca trade-offs mais amplos entre simplicidade e flexibilidade no design de linguagens, tratamento de erros, sistemas de build e gerenciamento de dependências.

Uso e convenções de go run

  • Muitos observam que go run main.go deixa de funcionar assim que main é dividido em vários arquivos; go run . executa o pacote atual e funciona com múltiplos arquivos e subdiretórios (go run ./cmd/foo).
  • Vários reclamam que tutoriais enfatizam go run file.go em vez do mais simples e escalável go run ..
  • Alguns gostariam que go run sem argumentos detectasse automaticamente um pacote main como outros subcomandos go, mas outros argumentam que isso seria ambíguo com vários binários cmd/*.
  • Módulos adicionam atrito: muitas vezes é preciso estar na raiz do módulo para fazer go run ., ou usar -C para mudar de diretório.

Simplicidade, convenções e curva de aprendizado

  • Go é elogiado por um layout previsível: diretórios como pacotes, cmd/ para binários; navegar por bases de código desconhecidas tende a ser direto.
  • Outros acham que a fronteira entre “simples” e “complexo” é pouco intuitiva (por exemplo, precisar saber quando usar go run . versus go run path/to/main.go).
  • Há debate sobre o quanto as expectativas de linguagens anteriores devem moldar tutoriais e modelos mentais de Go.

Comparação com JS/TS e outros ecossistemas

  • Alguns contrastam go run com o ecossistema do Node/TypeScript, citando fragmentação (npm, yarn, pnpm; CommonJS vs ESM; transpilaçao de TS, configuração de Jest/Babel).
  • Outros contrapõem que o Node já pode executar ESM (.mjs), TS via ferramentas simples (tsc, loaders), e que ferramentas mais novas (Deno, Bun, tsx, npx) tornam a programação em TS igualmente fácil.
  • Rust com cargo run, ferramentas de Python (Poetry), Nix e Bazel são mencionados como fluxos análogos de “build + run”.

Busca de dependências e segurança

  • Um recurso destacado: go run faz o download automático de dependências a partir de caminhos de módulo.
  • Defensores gostam do fluxo de baixo atrito, argumentando que as versões ficam travadas por go.mod/go.sum e apoiadas pelo proxy do Go.
  • Críticos veem o download automático durante run como um antipadrão de segurança/operação e preferem etapas explícitas de “buscar e depois executar”, especialmente para os primeiros downloads.

Visões mais amplas sobre Go

  • Muitos elogiam a ferramenta do Go (uma única toolchain, binários estáticos, compilação cruzada, implantação simples; às vezes até dispensando Docker).
  • Outros criticam a verbosidade no tratamento de erros do Go e a falta de recursos avançados de tipos em comparação com Rust ou TypeScript, embora alguns apreciem a explicitação.
  • Go é visto como estando entre o Rust de baixo nível e o TS de alto nível, encaixando-se bem para serviços de backend e utilitários pequenos, mas não satisfazendo o gosto linguístico de todos.