I would go one step further: in an effort to maintain binary compatibility, Java ended up trying to do "type erasure with generics", which in my mind is a horrible wart. C# went through the same changes, and built two different libraries for collections to accommodate it.
What I am saying is that it wasn't much prettier in those cases, and golang might not have had the same type of issues yet, but it just hasn't been around for all that long.
Well, Go isn't Java. They are two different languages.
The Java designers wanted jars to be runnable by any virtual machine, ever. This meant preserving some pretty old and nasty hacks (like erasure for generics) to allow old jars to work with new virtual machines.
With Go, you would just recompile and that would be it. Go doesn't even support loadable modules yet (although it's coming soon), so they can do whatever they want with compat. It's unlikely they'll make the same mistakes Java did because they are not blinded by the "write once, run anywhere" ideology.
What I am saying is that it wasn't much prettier in those cases, and golang might not have had the same type of issues yet, but it just hasn't been around for all that long.