The lack of import cycles in Go forces programmers to think more about their dependencies and keep the dependency graph clean and builds fast. Conversely, allowing cycles enables laziness, poor dependency management, and slow builds. Eventually one ends up with a single cyclical blob enclosing the entire dependency graph and forcing it into a single build object. This is very bad for build performance and dependency resolution. These blobs are also take much more work to detangle than the is required to keep the graph a proper DAG in the first place.

This is one area where up-front simplicity is worthwhile.

Import cycles can be convenient but their cost can be catastrophic. They should continue to be disallowed.

@robpike Indeed, import cycle is dangerous, double-edged sword.
It depends on how Go team decide it should be. Go users like the simplicity of Go, but spend time on things they have ever enchanted before, for instance, error handling (well, off topic).

I don't know it is possible to formal prove any projects written in Go can be designed without import cycle, at least Go source is a counter example that requires import cycles in many places.

This proposal is opened for discussion. People who watch this repo have sophisticated experience in Go, their opinion are biased sometimes (not criticize), and definitely understand what are best practices in dependency management. Unfortunately, not everyone can be.

I wish Go team and people who contributes to Go could discuss for the balance of allowability of import cycles, for instance, allow import cycle under few restrict criteria, which allows build fast as well as clean dependency.

Disabling import cycles really causes some conveniences sometimes, but enabling import cycles will cause confusions. When I began using C++, I often encountered compilation errors caused by import cycles. Surely, I learned to always use pointers to avoid the compilation errors caused by import cycles. But, as a C++ beginner, it was really a frustrating experience.

With introducing modules, enabling import cycles may cause a package to depend another version of the package easily. For example, assume foo.com/lib and bar.com/pkg depend on each other, when foo.com/lib is upgraded to a new version, the new version will depend on one of its old version.

A while ago I started a thread on go-nuts about that. My feeling (which is really intuitive I must confess) is that our brain naturally thinks circularly sometimes. Being able to conciliate the way our thoughts build themselves and the way we can build a program using our favorite language is (again, much intuitively) a good thing in my opinion.

However, along this discussion we've had with part of the Go community brought many arguments against allowing import cycles. For me the most decisive argument is that as much as I have about it since then, I haven't been able to formulate a clear, concise, simple case where it is NOT possible to think your types / packages without import cycles. I'll get even further with this, I have not been able to find a single case where it is clearer (in terms of maintenance or understanding) and fundamentally more logical to use import cycles. Therefore I have found my way to thinking that maybe, where one thinks that import cycles are necessary, the real, underlying problem is probably that the way the project has been thought and built is not the right one, from the beginning, and that the project most probably needs rethinking / refactoring.

Rob Pike's argument is also for me a really interesting one. It is easy to right bad code, and making it easier might not be the solution to any of our problems.

I don't know of a real "study" that would have been made to dig deeper into this dividing question, but I personally think that if such a research exists, it clearly does not reach the conclusion that import cycles are a good thing. After that, I still don't know if an optimal, beautiful solution will someday be discovered / invented.

Just to state my opinion now, after having thought about this for quite a long time, and in the light of all the arguments for / against imports cycles, I don't want them in Go anymore.

Sorry, this kind of change simply isn't going to happen.

Note that while the Go standard library uses go:linkname more than is ideal, it is rarely, perhaps never, done to avoid import cycles. It's done to avoid exporting APIs that shouldn't be public.

If you want to discuss this further, I recommend doing so on the golang-nuts mailing list.