[MatthewJBrown]

In fact, you should be glad that "go fmt" exposed the fact you were relying on something that you should not have. Better to find a bug sooner rather than later, and relying on implementation details of your particular language implementation is a bug.

[couchand]

It seems to me like it would be very much in line with the Go philosophy to automatically uncover this in some way other than just an impossible-to-debug pre-compile sort, like disallowing it on a language level. Perhaps that's a Hard Problem, though, so not a reasonable request.

[skj]

Well, they could do what they did with map iteration: make it happen arbitrarily different each program execution.

[couchand]

Breaking it randomly and requiring debugging is not the same as telling you you're doing something wrong and where.

[skj]

Worked for maps :)

The same exact argument applies. The code was broken to begin with, the implementation behavior did not break anything.

And, just like with map iteration ordering, it's very difficult/impossible for the compiler to say "hey don't depend on this!".

The only way that I can think of to get this concept (that import order in code and init() order in runtime are unrelated) is to have things break.

[couchand]

I guess I've personally never seen the value of static initializers (in other languages at least), they always seem like the source of hard-to-find bugs. So perhaps that's really where my complaint is. Is there a compelling use for them in Go over explicit initialization?

I suppose if the runtime randomizes things, at least you would never experience it consistently working in the first place, so maybe the issue wouldn't ever come up.

[skj]

Right, that's the idea.

Regarding static initializers, I use them for precompiling regexps and templates, but not much more than that.