Judging from this thread Go users are regularly using various tricks and hacks to avoid the compiler errors. So evidently Go programmers can't be trusted to handle compiler errors responsibly and not use hacks to hide them. In which case, what is the point of making in an error? It just makes things more difficult for the responsible programmers who don't ignore warnings (instead of a warning that they will notice they have to find and remove an obscure line of code).

It was an interesting experiment to make these things errors only, but it's clear that it has failed.

I wonder if we can fix the "warnings ui" somehow, so that they work better. The fundamental tension seems to be that programmer thinks he knows what he is doing, adds a warning override and the warning goes away. But then it may turn out that he didn't and the warning indicated a real problem.

The problem is the S/N of warnings. Our programmer removed a warning so that real warnings wouldn't drown in a see of false warnings.

The question is then, can we have our cake and eat it too? We don't want to completely forget about low risk warnings, we just almost completely. Maybe we could have some kind of exponential backoff when you ignore warnings?