In what order does Go initialize package-level variables when one depends on another?

### The rule Package-level variable initialization in Go is **dependency-driven, not textual**. The specification describes it as a stepwise process: at each step, pick the variable that appears earliest in declaration order among those whose initializer depends on no uninitialized variable, initialize it, and repeat. Source order is the tiebreaker, never the driver. So this package prints 3: ```go var a = b + 1 var b = f() func f() int { return 2 } ``` `a` is declared first but depends on `b`, so `b` is assigned first (2), then `a` (3). Reading the file top to bottom and expecting `a` to be 1 -- `b` being its zero value at the time -- is the classic wrong answer. ### Dependencies go through functions The analysis is not limited to variables named directly in the initializer expression. If an initializer calls a function, everything that function references transitively counts. In the example above, `f` references nothing, but had it read another package-level variable, that variable would have become a dependency of `a` as well. Methods count too: referring to a value implies referring to the methods it may reach. This is a static, syntactic analysis, so it is conservative -- it does not try to prove which branch will actually execute. ### It spans the whole package, not one file A Go package's files are compiled together, and the declaration order that breaks ties is defined over the files as they are presented to the compiler. The `go` command presents them sorted by filename. So two independent variables in `a_collector.go` and `z_collector.go` are assigned in that filename order -- and renaming a file silently changes it. Code whose correctness depends on that ordering is a defect waiting for a rename. ### Cycles are a compile error If two package-level variables reference each other, directly or through functions, the compiler reports an **initialization cycle** and refuses to build: ```go var x = y + 1 var y = x + 1 // initialization cycle ``` Go does not silently fall back to zero values as some languages do with static initializers. This is a deliberate design choice: a cycle has no defensible order, so the program does not compile. ### The blank identifier still participates `var _ = mustRegister("cpu")` is initialized like any other package-level variable -- the call runs during the variable phase, before any init() function in the package. It is the one way to run code at initialization time in the middle of a declaration block, and it obeys the same dependency rules as a named variable. ### Where variables sit relative to init() All package-level variables of a package are assigned before **any** of that package's init() functions run. That is what makes init() a reasonable place to do work that reads those variables, and what makes it wrong to expect a variable's initializer to see something an init() function set. Across packages, the ordering nests: every imported package is fully initialized -- its variables and its init() functions -- before the importing package assigns its first variable. So a package-level variable whose initializer calls into an imported package is safe: that package is already done. ### Why it matters in real code In a metrics-reporting daemon whose collectors add themselves to a package-level registry during initialization, the registry map itself is a package-level variable. If a collector's registration is also a package-level variable in the same package, the dependency analysis puts the map first -- because the registration references it -- and it works. The moment the registration moves into a different package, the guarantee that saves you is the cross-package one: imports finish before importers. The failure mode to remember: a package-level variable that is assigned but whose value depends on state set later by another package's init() will read as its zero value, and nothing warns you. That is why the safest package-level variables are the ones with no ordering requirement at all -- constants, literal maps, precompiled templates -- and why anything with a real ordering requirement belongs in explicit setup code that main() calls in the order it chooses. ### What to say in an interview State the rule (dependency order, declaration order as tiebreak, package-wide, cycles rejected at compile time), give the two-line `a`/`b` example, and add that all variables precede all init() functions in the same package.