If you can write the indulgence (permission to sin) into the code it becomes self-documenting and that seems reasonable

e.g. #![allow(dinosaur::nonsense)] in Rust tells the tools that you know you're not supposed to do whatever dinosaur::nonsense might be, but you want to do it anyway in the following code and the hypothetical dinosaur linter shouldn't bother you about that.

When a maintenance programmer is staring at this block of code later, the fact you explicitly intended to do dinosaur::nonsense is right there, documented where it happens, and they can decide if the proper course of action is to leave that as it is, fix the code to not be dinosaur::nonsense, allow raven::stupidity because the new Raven linter is better but now warns about the same problem under a different name or what.

This is fine, in moderation! I'm objecting to the linter tool itself being configurable.

Golint is the worst precisely because it isn’t configurable, and some of the things it looks for are idiotic. “should replace i += 1 with i++” is probably the worst advice I have ever received.

I can see Go's point here though. Unlike C-style languages where i++ is an expression, in Go it's only a statement, it has no value, which eliminates some footgun opportunities.

It's a halfway house to a language like Swift or Rust where none of the assignments have value. So, in a context where you don't want a value, arguably i++ is a better choice by eliminating a footgun. I don't hate it.

If a linter is configurable it is no longer a linter.