golint: golint is deprecated and frozen

[andrerfcsantos]

Since golint is unmaintained, deprecated and frozen, maybe we should stop suggesting it and start suggesting alternatives like staticcheck and go vet.

Or maybe refer to IDE integrations, like we do with gofmt.

Relevant issue: golang/go#38968

[iHiD]

(cc @bitfield and @tehsphinx)

[tehsphinx]

According to golangci-lint, the drop in replacement is called revive:

I'd argue however, that students are best served installing and running golangci-lint with the default settings. As that is highly configurable, they can later adjust that to their needs.

[bitfield]

staticcheck is the default linter for VS Code now, and it's probably the most widely useful if we're to recommend a linter.

However, one critical thing golint does that staticcheck doesn't is to warn about missing documentation comments for functions, variables, and other public identifiers. We could presumably do this with the auto analyzer, couldn't we?

[junedev]

I am unsure what the best way forward is regarding the linter we use in the analyzer.

Summarizing the options mentioned above:

• revive: Same functionality as golint so it would include the check for missing comments. Not much work required to change the code because it is a drop-in replacement. It's unclear how well revive will be maintained in the future.
• staticcheck: No check for missing comments but default linter in VSCode so for a lot of students the feedback they see from the analyzer would be consistent with what they see in their IDE.
• golangci-lint: Probably most often used in real-world projects and would probably give the most feedback. However, revive is not enabled by default (reference) so we won't get it out of the box. Enabling revive in a way that is reproducable locally for the student would mean either a custom command (golanglint-ci run -E revive ...) or a .golangci.yml file in each exercise folder. Also I think this linter is a bit harder to understand than the others conceptually since it is a metalinter that combines others.

I will ask for input from other maintainers / Go people on Slack.

[fgm]

staticcheck is supposed to include most of the golint checks (see dominikh/go-tools#542), plus many more, so not many reasons to use revive. golangci-lint, being a metalinter bundling many tools, has frequent upgrade issues. For example even now, it cannot run several of its linters on 1.18, and has some peculiar failure modes needing cache cleanup. In most cases, I prefer the combination of goimports + staticcheck. The extra checks in golangci-lint add little value IMHO.

[andrerfcsantos]

Been thinking a bit more about this and I'm also in favor of using staticcheck as our standard linter.

• I don't think we are getting much benefit of all the linters golangci-lint provides. I think staticcheck provides a reasonable set of checks that should be all we need. I can leave without the comment check. For the exercise we teach comments, the tests themselves are checking if the comments are correct. Not sure we care about these comments in the other exercises.
• golangci-lint often has upgrade issues
• golangci-lint apparently can break checks of the underlying tools making staticcheck's author recommend to use linters directly instead of via golangci-lint.

[junedev]

Agreed. I also thought about this more and I have the same feelings about this as @fgm voiced above.

Nevertheless, I think an additional analyzer check for missing comments on exported functions would be good as those (in the correct format) are very idiomatic for Go. This was suggested above by bitfield.