More powerful Go execution traces
Go’s new low-overhead execution tracing features are being welcomed as a major improvement for profiling and debugging concurrent services, with early reports from large production fleets suggesting the promised ~1% runtime cost is realistic. Commenters use this to springboard into a broader comparison of Go’s tooling and standard library—often praised as cohesive and “batteries included”—against ecosystems like Java, Rust, and TypeScript, which rely more on external tools and configuration. The thread also surfaces ongoing pain points, such as limited heap and error stack analysis, and debates how much configurability and runtime “knobs” a language should expose versus prioritizing simplicity.
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,
logvslog/slog,math/randissues, awkwardhttp.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.