Two modules each reference the other, forming a cycle in the dependency graph. What does a cycle actually cost you, and which languages refuse to build one versus merely letting it hurt later?

## A dependency graph, and what a cycle does to it Draw a node per unit (class, file, package, crate, assembly) and an edge from A to B when A needs B to compile or run. If that graph is acyclic, it has a **topological order**: some unit depends on nothing, some unit depends only on that, and so on. Every useful property follows from that order. You can build bottom-up. You can test a unit with only its dependencies present. You can read a unit and know the set of things it can be affected by. You can release a leaf without releasing its dependents. A cycle destroys all of that at once, for every member of the cycle. The right formal object is the **strongly connected component**: the maximal set of nodes each reachable from the others. Condense each SCC to a single node and the graph becomes a DAG again - which tells you exactly what a cycle costs. The SCC is now the true unit. Three classes in a cycle are, for build, test, comprehension, release and reuse purposes, one class with three names. You cannot extract one for reuse, you cannot understand one without the others, you cannot mock across the boundary because there is no boundary, and a change to any of them rebuilds all of them. That is why cycles are worth arguing about even when the compiler is indifferent - and compilers differ wildly in how indifferent they are. ## Who enforces acyclicity, and at what granularity **Go** enforces it at the package level, absolutely. `import cycle not allowed` is a build failure and there is no flag, annotation or ordering trick that permits it. That single decision shapes Go codebases: because you cannot patch over a cycle, you must break it, and the standard way is to move the interface to the consumer. Go's structural interfaces make that cost-free - the provider does not import the consumer to satisfy its interface - so the cycle usually disappears entirely rather than being routed around. The price is real too: you sometimes create packages that exist only to be depended upon by both sides, and `internal/` packages to keep them private. **Python** allows the cycle and defers the pain to runtime. Importing a module inserts a partially initialised module object into `sys.modules` before its body finishes executing, so a circular import may succeed or fail depending on *which* module was entered first and *how* you imported. `from b import helper` at the top of `a.py` fails with "cannot import name ... from partially initialized module" when `b` is midway through importing `a`; the same dependency written as `import b` and used later inside a function body works, because the attribute is resolved after both bodies have run. The result is a defect class whose reproduction depends on the entry point - a script, a test runner and a web server can each see a different outcome. **Java** compiles mutually referential classes and packages without complaint; javac resolves the cycle within a compilation unit set. Only the module system (JPMS) forbids cyclic `requires` between named modules, so enforcement exists but at a granularity most projects never reach. Tooling fills the gap - ArchUnit rules, jdepend, Spring Modulith's verification - which tells you the constraint is considered valuable even where the language does not impose it. **C#/.NET** is the interesting middle: inside an assembly, cycles among classes and namespaces are free, but a circular *assembly* reference is a hard error. So the enforced unit is the deployment artefact. This measurably changes design habits - .NET solutions tend to split into many projects precisely because that is the only line the compiler will defend, whereas a Java or Kotlin codebase can accumulate package cycles inside one jar indefinitely. **C++** adds a dimension the others do not have: physical versus logical dependency. Headers that include each other need include guards and forward declarations; the pimpl idiom removes a *compile-time* edge while keeping the runtime relationship, purely to stop a header change rebuilding the world. Here a cycle's dominant cost is build time, and the tools to break it are physical. **Rust** enforces at the crate level - cargo rejects a circular crate dependency - while permitting mutually recursive modules within a crate. That draws the same line .NET draws, at the unit of publication. ## Breaking a cycle Three moves cover nearly everything, and they are language-independent even though the pressure to use them is not. **Extract**: pull the shared thing both sides need into a new unit both depend on, turning A-B into A-C and B-C. **Invert**: replace one edge with an edge to an abstraction, so the arrow reverses (which language mechanics make this cheap or expensive is a separate question in this topic). **Merge**: if two units genuinely cannot be separated, admit the SCC and make it one unit with one name, which at least stops pretending there is a boundary. The move to avoid is the local patch - a late import inside a function in Python, a forward declaration in C++, a setter-based wiring step in Java - which silences the symptom and leaves the SCC in place.