3 ms·

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.