So in fact, I don't like to have circular dependencies in Go either and try to avoid them, so I agree with you on that. But at the same time I like very small and simple packages and sometimes you have to choose:
1. do you build a larger package with everything inside
2. do you build multiple smaller packages with dependencies on each other
As I said, in general, I favor the smaller packages and that can lead to circular dependencies, if you are not using interfaces properly.
But I still think that you have multiple packages and each one is calling all the other ones, then it doesn't make much sense to have multiple packages at all.
I prefer smaller packages too, but currently I'm trying to avoid overmodularizing, specially when a package is too connected to some others and is not going to be used elsewhere.
I am not sure if I agree with
> Defining an interface upfront is usually a code smell for overengineering.
So far I had less problems with overusing interfaces than with not using them enough. So when you write tests for a package, you define the general interface to the package in terms of types and methods. The remaining challenge is to break that general definition into smaller pieces as one big interface for a package is almost certainly a bad idea.
However, in general I follow the authors verdict to not just build 'Java-style' interfaces, as that completely misses the point of interfaces in Go.