3 ms·

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 late

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 12y ago
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 12y ago
  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.

couchand 12y ago

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 12y ago
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.