Yes, and I usually find when I run into this that I should be doing something differently in our package/interface design. I think it's overall very helpful though also annoying to detangle if you the cycle is deep enough.

indeed it does; i've run into it a few times. just last week i was writing some go code in vscode and it wasn't working because i had a circular dependency. vscode was reporting something in the "problems" window like a "go list" failure due to "no go files". i couldn't make head or tail of it for a few minutes. it took me some time to note that the path listed in the issue was one i had just edited. in fact, i didn't even notice the path at first -- i tried running `go list` from my repo root and didn't see the error, but when i saw the path and changed to that dir and tried again, i saw the `go list` error as reported by vscode, and i think that when i opened the file i had just edited in vscode it displayed a more understandable cyclic import message in the offending import, and it was easy to go from there.

Life is better without circular dependencies

I was just thinking how the ideas behind Turbo/Borland Pascal and Delphi reminded me of Go, I know it should've been Dotnet, but Dotnet got complicated right from the start with it's deployment model (lots of dlls, assemblies, blah, blah blah).