> I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster.

In almost every code base I have worked with where warnings weren't compile errors, there were hundreds of warnings. Therefore it just best to set all warnings as errors and force people to correct them.

> Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.

I work with a colleague that doesn't compile/run the code before putting up a MR. I informed my manager who did nothing about it after he did it several times (this was after I personally told him he needed to do it and it was unacceptable).

This BTW this happens more often than you would expect. I have read PRs and had to reject them because I read the code and they wouldn't have worked, so I know the person had never actually run the code.

I am quite a tidy programmers, but it difficult for people even to write commit messages that aren't just "fixed bugs".

Go is a very opinionated language. If you don't like K&R indentation, tough - anything else is a syntax error.

It's kind of like the olden days.

You're not supposed to question the wisdom of the Go developers. They had a very good reason for making unused variables be an unconfigurable hard error, and they don't need to rigorously justify it.