I didn't state I don't use linters. I use go fmt, go vet and golint constantly. I don't consider fmt a linter so much as an auto-formatter. I don't consider the output of go vet or golint to be warnings, more like errors -- I don't ignore them.
Even if the try proposal were to result in eventual go vet errors, then surely go fix would be able to rewrite on your behalf, so this would be a non-issue, just as go fmt is a non-issue. But I don't think this will happen any time soon.
> everything that is `return nil, err` will need a special comment to silence recommendations
I don't use linters that can be ignored with special comments. I don't recommend them. This is a problem in other languages/ecosystems, but in my experience it is not a problem in Go, where it's considered an anti-pattern. This feels like FUD to me.
> nagging social pressure to reduce linter warnings will result in skipped error handling.
Yes and no? Social pressure to reduce linter warnings is a good thing, why use a linter if you are going to ignore its output. This problem only exists if you have linter warnings.
> a licensing checker (glice)
I've never encountered this. I don't think a linter that hits the Github API is a good idea.
> a security scanner (gosec)
This looks like a pretty opinionated linter. Some example rules:
> G103: Audit the use of unsafe block
> G104: Audit errors not checked
> G201: SQL query construction using format string
> G105: Audit the use of math/big.Int.Exp
> G501: Import blacklist: crypto/md5
Are these actionable? Probably not. There are perfectly valid reasons to do all of these things. Maybe this is useful to paint a picture of a code base you're evaluating, or to flag new changes as suspect, but I don't know what purpose this would serve in CI.
Don't use linters which just create noise and non-actionable output. They're not valuable, they're a waste of energy. Make them manual, or maybe run them against new changes only with the expectation that they're informative but often ignored.
These are all personal problems. Most Go users don't have these, I suggest you choose to not have them also.
Even if the try proposal were to result in eventual go vet errors, then surely go fix would be able to rewrite on your behalf, so this would be a non-issue, just as go fmt is a non-issue. But I don't think this will happen any time soon.
> everything that is `return nil, err` will need a special comment to silence recommendations
I don't use linters that can be ignored with special comments. I don't recommend them. This is a problem in other languages/ecosystems, but in my experience it is not a problem in Go, where it's considered an anti-pattern. This feels like FUD to me.
> nagging social pressure to reduce linter warnings will result in skipped error handling.
Yes and no? Social pressure to reduce linter warnings is a good thing, why use a linter if you are going to ignore its output. This problem only exists if you have linter warnings.
> a licensing checker (glice)
I've never encountered this. I don't think a linter that hits the Github API is a good idea.
> a security scanner (gosec)
This looks like a pretty opinionated linter. Some example rules:
> G103: Audit the use of unsafe block
> G104: Audit errors not checked
> G201: SQL query construction using format string
> G105: Audit the use of math/big.Int.Exp
> G501: Import blacklist: crypto/md5
Are these actionable? Probably not. There are perfectly valid reasons to do all of these things. Maybe this is useful to paint a picture of a code base you're evaluating, or to flag new changes as suspect, but I don't know what purpose this would serve in CI.
Don't use linters which just create noise and non-actionable output. They're not valuable, they're a waste of energy. Make them manual, or maybe run them against new changes only with the expectation that they're informative but often ignored.
These are all personal problems. Most Go users don't have these, I suggest you choose to not have them also.