More powerful Go execution traces

Perceived benefits & overhead of Go execution tracing

• Many commenters are excited about the new tracing capabilities and would happily pay a 1–2% overhead.
• A practitioner reports using execution tracing at scale in production with real workloads rarely exceeding ~1% overhead and built-in features depending on it, suggesting claims are realistic outside pathological cases.
• Some remain mildly paranoid about always-on tracing but see it as worth it if overhead numbers hold.

Go tooling vs other ecosystems

• Go’s integrated tooling (test, benchmark, profiling, cross-compilation, docs, basic linting, module support, etc.) is widely praised for simplicity (“one binary, it just runs”).
• Critics argue “standardized but minimal” tools limit configurability and polish compared to specialized ecosystems.
• Java is repeatedly cited as still “best in class” overall for tooling (especially heap/memory analysis, live debugging, JFR-style flight recording), though Go is seen as catching up.
• JS/TS tooling is often described as fragmented and config-heavy; Go’s approach is seen as an antidote to that, though some value TS’s configurability.

Standard library size, quality, and philosophy

• Go’s stdlib is lauded as clean, stable, and especially strong for HTTP and networking; many claim they rarely need third‑party libraries.
• Others point out “barnacles”: legacy packages, context proliferation, log vs log/slog, math/rand issues, awkward http.Client, and weaker areas like CSV, XML, heap dumps.
• Debate over “large stdlib vs small core + good dependency management” (Go vs Rust/Node style). Some call the heavy dependency culture “insane”; others argue broad stdlibs can’t cover all depth and evolve slowly.

Terminology and tracing granularity

• “Execution trace” confused some who expected instruction- or function-level traces. In Go this mainly means goroutine/runtime event tracing with stacks at event points.
• It is clarified that Go does not provide full instruction/function tracers; the current facility is closer to a scheduler/runtime trace.

Error handling and stack traces

• Several commenters are frustrated that errors lack built-in stack traces, leading to grepping error strings.
• Others emphasize Go’s philosophy: errors as normal values, explicit wrapping with context, and stack traces mainly for crashes/panics due to cost.
• Common practice mentioned: custom wrappers that attach stack traces only where needed (e.g., for logging or Sentry), trading runtime overhead for better diagnostics.