Go isn't a serious language for large systems. The language allows writing shitty code and the community has largely adopted that. Go fanatics will hate this, but you simply can't compare it with the ability to write and maintain in languages like Java.
I'll bite. Why can't you compare it? Is it the class/function on struct thing? Generics? Go-routines not threads? Rob Pike did say once that the GC is deliberately not tunable because a JVM knob-twiddler should not be a job title.
* Poor modeling ability (lack of default interface methods, no records, pattern matching, exhaustiveness checks, etc.).
* Error handling is error prone. * Generics are half baked.
* No short hand syntax for passing functions as lambdas.
* No annotations.
* Implicit interfaces make it hard to navigate large code bases because it is very easy to accidentally implement another interface. There are better solutions for the problem they tried to address with structural interfaces. * No string templates.
* The GC not being tunable does not obviate the use cases where it needs to be. Furthermore, Java's ZGC only has a couple of knobs anyway, while giving you the option to use a more tunable GC when your use case calls for it. golang's GC is only tuned for latency at the expense of throughput.
* goroutines are half baked, see Java's virtual threads + structured concurrency for a more manageable approach.
* Observability way superior on the JVM.
* No proper enums.
* No const/final variable declarations.
* Visibility rule are crude. Only public or package private.
* Probably more things I didn't think of at this time.