Most linters that concern themselves with errors will complain about this and I would not accept any code that does this beyond tests.
Go allows you to do certain things but it's not a fallacy because it's something that's allowed but not necessarily tolerated by what most consider "good Go coding standards"
My consulting experience has shown that beyond startups, or a few Fortune 500 companies like Google and FB, linters and code reviews are seldom done, unless we are speaking about safety critical domains like aeronautics, autos, train control systems,medical devices....
So because a lot of people don't use best practises that means the language in which these are to be used is worse off?
It strikes me a bit like saying "because most people don't wear seatbelts, cars are unsafe because you may get ejected out of the cockpit in a crash". Wear a seatbelt and use linters, I'm not going to excuse the malpractices of the larger industry.
Optional external tools, are exactly that, optional.
Lint was created for C in 1979, a minority used it or its commercial versions like Gimpel, until clang was introduced with static analysis built into the compiler.
Anything that isn't enforced by the language, tends to be ignored, hence why we need good defaults that make workarounds a big pain.
More safe defaults also means I have to think more about escape hatches. Sometimes ignoring an error is the intended way of operation, although rare. Same goes for some other parts of the go coding standards. Sometimes you need to violate them and having to first use some escape hatch like Rust's unsafe is annoying.
Not really. It has changed my coding style so I now only add variables when needed, even in languages like JS. I only get the "unused variable" error about once a month.
Go allows you to do certain things but it's not a fallacy because it's something that's allowed but not necessarily tolerated by what most consider "good Go coding standards"