4 ms·

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

• couchand 12y ago
  Breaking it randomly and requiring debugging is not the same as telling you you're doing something wrong and where.
  • skj 12y ago
    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 12y ago
      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 12y ago
        Right, that's the idea. Regarding static initializers, I use them for precompiling regexps and templates, but not much more than that.