Go has something of an imposed rigidity that a lot of C programmers I think wouldn't tolerate well (culturally, viscerally),- one example: the whole comment out all unused variables because you commented out a function for debugging purposes during development (couldn't just pass a flag to the compiler, at least last time I used Go).
Aside - I seem to remember a Blog post you wrote on your experience with the Go language and I think it pretty accurately reflected a lot of my own experience with it.
I upvoted this (apparently it's been downvoted again) -- for the record I totally disagree with the premise but I think it's a serious enough point to merit being addressed rather than down-voted[0].
> Commenting out code correctly, in a way that avoids complaints about unused code, should be possible to do in a proper IDE.
First of all, failing to compile, in an of itself should be reserved to a particular class of failures not to linting, I feel pretty strongly about this and I think a lot of other people do.
Further, I would say, that the complexity of an IDE that supports this - e.g. suppose you previously declared `uin64_t a, b, c, d;` and someone commented out the only function which uses c ? The editor should than make a new line with `//uint64_t c;` and than contract the old line correctly. That isn't a simple procedure to be sure and it's perfectly reasonable to use nano/vi to write code (you might say it's not effective) but at least in my opinion programtically correct code shouldn't fail because I'm not using super-advanced-ide-X.
[0] Aside - I tend to dislike this down-vote on disagree trend lately, imho the discussion would benefit from respecting and responding to disagreeable opinions and downvotes should be reserved for where (exclusively, but I guess subjectively - the comment isn't/worth the time effort to disagree or respond to e.g. blatant spam, highly condescending, personal attacks etc.)
Go only errors on a small number of things and, while some of those things would be warnings in other languages, I don't think it's fair to frame them in that light.
The go compiler strives to not print any output at all pretty much, and it does that by not having any warnings at all.
If you want warnings in go, you use tools like "go vet" which tell you "this bit is indicative of an issue".. the go compiler won't give that to you though.
As other replies said, Go also doesn't have many compilers. Really it's only 1 supported one.
They also don't add new "errors" to the compiler over time for this compatibility reason pretty much.
Have you ever used multiple compilers? Try compiling the same thing written in C or C++ with: clang, then gcc, then icc and see how -Werror treats you within any remotely interesting code. It's hard to predict what one compiler feels is perfectly okay (or perhaps ambiguous) and another feels is downright wrong. It's downright infuriating in a cross-architecture environment. -Wall -Wpedantic and -Wextra are usually plenty.
> It's downright infuriating in a cross-architecture environment
The only thing more infuriating than being unable to predict when your code is going to fail the build because of -Werror on some other compiler/arch, is your bugs generating warnings on some compiler/arch es that don't fail the build. Cross-architecture environments are one of the main reasons I want to enable -Werror and kin. I won't notice all the warnings otherwise.
