I think error handling is the thing about Go that people get most wrong. I believe that what's happened is that Go expected its users to be people fleeing C++ (they definitely got that one wrong), and instead they got a flood of Python and Java developers. Systems programming is error programming. Hiding and abstracting errors in systems code isn't a win; it's a handicap. Fiddly decisions about errors is the whole ballgame. But that's not the case in application code (EAFP!) and Go has been beset by that countervailing sentiment ever since.
That's not to say Go's got error handling perfect; it would be better with matching. But no mainstream language gets errors perfect. What unifies the strong systems languages is that they enable the overt programming of errors.
The second problem is nil, use of which is common and doesn't enforce error handling.
Are you saying that you’ve had 5 bugs caused by unnecessary imports?
It did so 5 times, versus how many times it gave a false positive where you just had to delete the import or underscore the variable?
Warnings are intended precisely for this type of "hey, you probably made a mistake here". Errors should imo be reserved for cases where the compiler is more or less sure you are wrong.
Rust has probably the biggest possible focus on "making sure only correct programs compile", and rustc does not error on an unused variable or import; it gives a warning. Precisely because it does not know if it is a bug, or just, I don't know, "commenting out the code that uses it to try something".
Also, in the case of an unused variable, you CAN blow it off, by using _. In fact, this makes it far easier to forget about it later compared to a warning that can be silenced in the same way, because if it's a warning you'll only do it if you're actually sure, while with an error you might do it even if you're less certain, because it's absolutely necessary.
Although, I guess this is the difference between being 13 years old and 7. For Rust easily accessible CI has always existed, for Go at the time of launch it took effort setting it up. Therefore best practices were pushed into the compiler to the detriment of the users, giving the same benefit trading effort writing the code.
There are other footguns like the unpredictable by-reference behaviour of slices and the printf functions corrupting your output if you make a type error but they are much less severe than the misguided idea that implicit default values are useful.