Once the linters get involved, everything that is `return nil, err` will need a special comment to silence recommendations to "use try here". That constant, nagging social pressure to reduce linter warnings will result in skipped error handling.

Try doesn't allow skipped error handling, the error still needs to be handled, just one level up.

I disagree that linters should or will recommend it except in cases where there is no annotation and there is therefore no functional difference in using try.

We'll see.

That sounds like a personal problem. Nothing nags me when I write Go. Don't use those linters.

There is a reason Go doesn't have compiler warnings.

What complaint do you currently see from go fmt that is closest to "you should use try here"?

Why are you surprised? lint, vet, and fmt are common parts of the ecosystem tooling. Many projects require they be run as part of the contributor workflow.

These tools are so common and so normal that while they aren't part of the compiler, they're part of the "social" toolchain.

So, it's odd that the author doesn't use a linter when the general tendency is to use a linter, a licensing checker (glice), a security scanner (gosec), a formatter (fmt), a static analysis tool (go vet), etc in your CI/CD pipeline.

It's so odd that it begs the question - does this author avoid common tooling? And by extension, do I care what they think about how Go should be written if they aren't using the standard tools?

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.

This. Fmt or imports or whatever will bug you about stylistic things “don’t use snake case!” “Why are you using caps?!” “Don’t touch me!” But I’ve never seen it recommend using built in functions. Hope it stays that way.