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.
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.
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.
You don't say you're not money oriented in a job posting unless you intend to not pay a competitive salary for the skills you're asking for and the workload you intend.
It's pretty upfront about the fact that if working for Penny Arcade isn't a huge plus point for you, you're not the person for the job. That's supposed to be part of your compensation.
This still says nothing about what they are willing or even expecting to pay. Pretty much all I can infer is that they are not interested in trying to attract people based on seeing a ludicrously high number in a posting.
If they really don't have centralized build farms they're NUTS. Seriously? It isn't just buying you horsepower, either; it's buying you an identical build environment every time, done right at least. It guarantees there isn't some weirdness about a developer's workstation where it builds right there and not anywhere else.
