Traços de execução do Go mais poderosos

Benefícios percebidos e overhead do tracing de execução do Go

• Muitos comentadores estão entusiasmados com as novas capacidades de tracing e pagariam de bom grado um overhead de 1–2%.
• Um profissional relata usar tracing de execução em escala em produção com workloads reais raramente excedendo ~1% de overhead e recursos integrados dependendo dele, sugerindo que as alegações são realistas fora de casos patológicos.
• Alguns continuam ligeiramente paranoicos quanto a tracing sempre ligado, mas acham que vale a pena se os números de overhead se mantiverem.

Ferramentas do Go vs outros ecossistemas

• As ferramentas integradas do Go (testes, benchmarks, profiling, cross-compilation, docs, linting básico, suporte a módulos, etc.) são amplamente elogiadas pela simplicidade (“um binário, ele simplesmente funciona”).
• Críticos argumentam que ferramentas “padronizadas, mas mínimas” limitam a configurabilidade e o polimento em comparação com ecossistemas especializados.
• Java é repetidamente citado como ainda “best in class” no geral para tooling (especialmente análise de heap/memória, depuração ao vivo, gravação de voo no estilo JFR), embora o Go seja visto como estando a alcançar.
• As ferramentas de JS/TS são frequentemente descritas como fragmentadas e pesadas em configuração; a abordagem do Go é vista como um antídoto para isso, embora alguns valorizem a configurabilidade do TS.

Tamanho, qualidade e filosofia da biblioteca padrão

• A stdlib do Go é elogiada por ser limpa, estável e especialmente forte para HTTP e networking; muitos afirmam que raramente precisam de bibliotecas de terceiros.
• Outros apontam “cracas”: pacotes legados, proliferação de context, log vs log/slog, problemas em math/rand, http.Client pouco prático, e áreas mais fracas como CSV, XML, heap dumps.
• Debate sobre “stdlib grande vs core pequeno + boa gestão de dependências” (estilo Go vs Rust/Node). Alguns chamam a cultura de dependências pesadas de “insana”; outros argumentam que stdlibs amplas não conseguem cobrir toda a profundidade e evoluem lentamente.

Terminologia e granularidade do tracing

• “Execution trace” confundiu alguns, que esperavam traços ao nível de instruções ou funções. Em Go, isso significa principalmente tracing de eventos de goroutines/runtime com stacks nos pontos dos eventos.
• Fica esclarecido que o Go não fornece tracers completos ao nível de instrução/função; a funcionalidade atual é mais próxima de um trace de scheduler/runtime.

Tratamento de erros e stack traces

• Vários comentadores estão frustrados com o facto de os erros não terem stack traces embutidos, levando a procurar strings de erro com grep.
• Outros enfatizam a filosofia do Go: erros como valores normais, wrapping explícito com contexto, e stack traces principalmente para crashes/panics devido ao custo.
• Prática comum mencionada: wrappers personalizados que anexam stack traces apenas onde necessário (por exemplo, para logging ou Sentry), trocando overhead em runtime por melhor diagnóstico.