Go will fail to build if you have unused dependencies or variables. (And it's easy to use the convenient `:=` in a way which faces problems exacerbated by this).
If I'm debugging through something, I might be adding packages or intermediate calculations to try and figure out what's going wrong. But because the Go compiler enforces this proper style of "nothing unused", there's that much more friction when tinkering.
This will hopefully reduce some of the friction you are having.
- it's the exact same 4-6 criticisms every single time
- "no generics" is on the chopping block
When criticism is valid, it doesn't matter if it's novel or not.
Ironically, golang codebases tend to be more verbose than Java.
I want to make a pasta comparison but can't think of a good one for Go, since it's often quite straightforward / not-spaghetti. Java is often lasagna code though.
This isn't necessarily an argument that those criticisms are wrong, though.
-error handling is kinda ugly and verbose
-no generics
-interfaces are done through duck typing
-null pointers
-int size is platform dependent
-no built-in immutability