In the abstract, I think I agree with you. But in reality, what I see is that go projects use far fewer packages than, say, programs in Java. Many go projects use one or two omnibus packages--principally, I expect, to avoid having to worry about circularity issues.
By forcing this design pattern on developers (something no other language does), I think the result has been overall worse code rather than better.
Perhaps a warning, rather than stop-the-compiler error would have been a better choice. Not sure.
Either way though, I wholly agree that the compiler gives too little information, which is curious because it knows the needed data and should easily be able to present it in a useful way.
I see the opposite in most Java programs: poor organization with packages based on a type of thing (eg models, controllers) rather than related behaviors.
Go doesn’t have warnings, which is great - if something is worth warning about, it is also worth erroring about. It never ceases to amaze me when a brand new JavaScript project spits out dozens of errors after pulling in a common library, and everyone thinks that is ok.
It has go vet, which is not a linter, and according to the authors doesn't need comments to ignore checks, because the checks are always correct about you having written shitty code. Except where it might warn you about something completely outside your control.
By forcing this design pattern on developers (something no other language does), I think the result has been overall worse code rather than better.
Perhaps a warning, rather than stop-the-compiler error would have been a better choice. Not sure.
Either way though, I wholly agree that the compiler gives too little information, which is curious because it knows the needed data and should easily be able to present it in a useful way.