IANAL, and I am not the one being quoted... with that said, it seems to me that you're reading way too much into that statement, and in the process, more-or-less ignoting the context. To me, what's being implied here is precedent...
You can't rely on the order of imports initialization anyway. See http://golang.org/ref/spec#Program_execution .. I believe that's also the reason, you shouldn't call `flag.Parse()` in `init()`
(I don't seem to be able to reply to your comment directly)
danieldk 8 minutes ago | link
>> As I've already said to someone else. This is about linking, not compilation. The rest of your comment is irrelevant to this discussion.
> And I am reacting to your grandparent, who was talking about compilation.
I'm fairly certain that that slow compile time is a combination of `compile + link` and the linking is probably a big part of the equation as well, just like it is in C and Go.
> But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation time is IMO overstated by Go proponents.
As I've already said to someone else. This is about linking, not compilation. The rest of your comment is irrelevant to this discussion.
You could potentially also have an interface that defined methods for all the basic types `interface { AsString() (string, error), etc. }` and then each basic type implements this interface and returns an error if it can't/shouldn't be represented as the requested type. A type-switch could give you the same info you get from the tag and you don't pay for type-assertions
> You can put lipstick on a pig...
Was this comment the spoken word in disguise? It sounded a little poetic to me.