There are lints for that, if that's really a big issue for you.
I don't want that because I don't want to litter my code with `_ = fmt.Printf()`
`Printf()` is a very common function. It returns an error. I don't care about an error from `Printf` and I don't want to make my code more ugly to avoid bugs I'm not writing in the first place.
I've been writing Go code since before v1. I really can't recall a case where I wrote a bug because I forgot to handle an error.
I get how you can forget something you do once a month.
I don't get how you can forget to handle an error in Go when that's something you do every couple of lines of code written.
I regularly see both of the problems I mentioned when reviewing imported dependencies. Yes, the linters can help for your own code base, but something that forces correctness into all code is a big advantage over something that your dependencies may or may not bother with.
Most people, I admit, do not review their dependencies, but that in and of itself is a problem.
Your fmt.Printf issue is trivially addressed by implementing PrintfOrDrop() which wraps that - and if this was the way Go behaved, you can be certain the standard library would add these variants for conciseness.
I don't want that because I don't want to litter my code with `_ = fmt.Printf()`
`Printf()` is a very common function. It returns an error. I don't care about an error from `Printf` and I don't want to make my code more ugly to avoid bugs I'm not writing in the first place.
I've been writing Go code since before v1. I really can't recall a case where I wrote a bug because I forgot to handle an error.
I get how you can forget something you do once a month.
I don't get how you can forget to handle an error in Go when that's something you do every couple of lines of code written.