One year after switching from Java to Go

Go modules & package management

  • Some praise Go modules and single-binary deployment as a huge improvement over Java+TS+Node+Python dependency hell.
  • Others argue Go’s “source-as-artifact” model is painful: versions live in VCS tags, not files, making version bumps hard to review and automate.
  • Major-versioning via /v2 import paths is seen as needless churn (touching many imports just to upgrade).
  • Pulling from private Git repos instead of artifact repos (Artifactory, etc.) is another recurring complaint.

Java performance, Spring, and startup

  • Many argue the 2GB+ RAM and multi-second startup in the article are mostly Spring/Spring Boot issues, not inherent Java/JVM problems.
  • Description of Spring’s startup: heavy classpath scanning, bytecode parsing/enhancement, reflection and codegen; often single‑threaded.
  • Others report simple Java frameworks (Jersey, Vert.x, Micronaut, Quarkus) starting in ~0.5–1.5s, with GraalVM or CRaC offering near‑Go cold starts.
  • Some say slow startup matters a lot in k8s/ECS fleets; others claim for most apps it’s irrelevant.

Go vs Java for cloud/k8s tooling

  • Strong consensus that Go “fits” Kubernetes operators and infra tools better: small memory footprint, quick startup, simple deployment.
  • Several note that Go has tighter “mechanical sympathy” (value types, composition) versus Java’s pointer-heavy, frameworked style.
  • Counterpoint: Java (or Kotlin) without Spring, using lighter libraries, can be competitive but is culturally uncommon.

Dependency Injection & context in Go

  • Repeated criticism of using context.Context as a DI container or “bag of globals”; Go docs and some commenters call this an anti-pattern.
  • Preferred Go style: constructor injection via interfaces and structs, no runtime DI container; optional compile-time tools like Wire or Fx.
  • Others defend DI frameworks (in Go, Java, .NET) as saving boilerplate and making lifecycles manageable on large systems.

Error handling philosophies

  • Many Go users like explicit err returns as forcing thought about failure at each call.
  • Others find it verbose, easy to get wrong (if err == nil bugs), and miss exception bubbling or Rust‑style ? sugar.
  • Some argue that explicit errors reveal hidden failure paths that exceptions can obscure; others reply that exceptions with wrapping can give equally rich context with less call-site noise.

Ecosystems, tooling & language culture

  • JVM praised for mature tooling: JMX, flight recorder, heap/thread dumps, mutation testing, strong web frameworks, enormous library set.
  • Go lauded for pprof, batteries‑included stdlib, and a culture of minimal dependencies and simple, readable code.
  • Several stress that many “Java problems” are really Spring/enterprise culture, not the language/VM; likewise, Go codebases can devolve into messes if over‑engineered.
  • Comparisons to C#, Kotlin, TypeScript, Rust, and Python recur: most agree Go is simpler to learn but less expressive; choice often comes down to domain and team norms rather than raw technical merit.