| Have you looked at golangci-linter [1] at all? It's a competing project that also implement a bunch of linter rules, and was created because gometalinter is too slow. One reason golangci-linter is faster is that it shares the same in-memory representation of the linted packages between all the linters. From what I can tell, Revive requires that each rule parse the file itself, which is the same design gometalinter use, and it will absolutely kill performance for anything that needs to operate on the full AST. Also, the Go community does not need a bunch of competing linter tools. For one, at means that tools like Visual Studio Code's Go plugin [2] will have to build special support for each linter tool. Gometalinter was nice because it built lots of rules (including golint) into a single tool, so you just needed that one tool. I agree with the others about configuration. I think a lint tool should have a configuration work out of the box that reflects Go standards that everyone, without doubt, uses. More controversial conventions such as requiring all exported functions to have comments don't need to be included. [1] https://github.com/golangci/golangci-lint [2] https://github.com/Microsoft/vscode-go |
Revive is a project, which I started about 9 months ago but recently found time to put some finishing touches and open source it. It's not a linter aggregator; it's a framework which provides tools for reducing the friction for development of custom rules for static analysis of your applications.
And no, the individual rules in revive do not parse the files. There's an abstraction on a higher level which parses the files ones. Each rule may request type information for the package which is then cached and reused across the invocations as well. That's how revive manages to improve the performance of golint to this extent.