Go isn't generating breathless conference talks anymore. The language has slowed its release cadence, the discourse has moved on to Rust and Zig, and the typical engineer entering the industry hasn't written any. None of this changes the fact that Go remains the right tool for a specific and large class of problems.
What Go is genuinely great at
- Internal CLI tools that need to be built, distributed, and run on engineers' machines without ceremony.
- Sidecars, proxies, and infrastructure-glue services where simple, predictable performance matters more than expressiveness.
- Network services with tens of thousands of concurrent connections, where goroutines actually shine.
- Anything that benefits from a single static binary you can scp to a box and run.
What Go is honestly mediocre at
- Domain modeling for complex business logic. The type system is too thin for problems where invariants matter.
- Anything involving heavy generics-driven abstraction. Go has generics now, but the standard library hasn't really embraced them and conventions are immature.
- Iterating on early product features where you don't know the shape yet. The boilerplate adds up.
The team-level argument
The strongest case for Go isn't technical — it's social. A new engineer can read a six-month-old Go codebase and understand it in an afternoon. They cannot say the same of a six-month-old Scala or Rust or TypeScript codebase from a different team. That readability tax adds up across years and people.
We've shipped Go for internal tools, gRPC services, and a fleet of small daemons for nearly a decade. The total operational headache from those services has been, roughly, zero. That counts for a lot.