[Clex]

Go has also an amazing static-analysis tool, vet, that is not mentioned in the article: https://golang.org/cmd/vet/

It can find printf-format errors, invalid shifts, unreachable code, etc.

Even though go vet is very helpful, it is sometimes scary that the compiler allows to build such incorrect code. For instance: https://play.golang.org/p/2AVHUt5Wcf

[laumars]

That's a weird criticism to read when most of the time people moan about the Go compiler being too strict for failing to compile code with errors that other compilers might only warn or even if ignore.

Go does already have one of the strictest compilers (by default) out there. But it is pretty typical for a great many language frameworks to support optional additional strictness. Eg "use strict" in Perl or the gcc flags of which I cannot recall off hand. I see God's vet as akin to those. ie there when you need it but keeps out of your way when you just need to get some prototyping done.

[_ph_]

What by the language spec makes your code incorrect? The only question is, does the compiler generate a constant call to print "false"? But this would be an optimization, not a correctness question.

[Vendan]

I'm not sure how `fmt.Printf("%s\n", i) // invalid type` is really that "scary". Expecting the compiler to introspect that Printf's `...interface{}` argument's first value is incorrect, even though `i` does fulfill the stated parameter's type, is a FAR more scary thought.

[_ph_]

The important thing here is, that fmt.Printf is just a function which takes a string and a variable amount of interface{} parameters. There is nothing in the language spec which creates a type correlation. the "%s" denotes a string parameter to print is solely some inner working of the Printf function. Yes, you can special case fmt.Printf, as some compilers do, but given the standard go vet tool, I rather think it belongs there than into the compiler, which, following the Go philosophy, exactly understands the Go language and precisely compiles that.

[Vendan]

That's exactly my point. Special casing the compilation of 1 specific set of functions is a scary concept, esp. as the tool that can check the types is already in the go toolchain, AND there are plenty of edge cases that can't be caught anyways, so it can create a false sense of security.

[_ph_]

Ah, had not quite caught your point as you had phrased it (and that by the time I answered your post was difficult to read for me, as for some downvotes it was printed in a very light font). Then we fully agree.