[tptacek]

I keep count in my own code of the number of bugs Go's "damnable use requirement" has caught for me, and I'm now up to 5. It's not a big number, but they were real bugs that would have annoyed the shit out of me if they'd made it into shipping code. I think this is one of the polarizing decisions Go made that is going to turn out to be universal orthodoxy 10 years from now.

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.

[dontlaugh]

The biggest problem with the error handling is that it's not composable. It's better than unchecked exceptions, but that's not saying much.

The second problem is nil, use of which is common and doesn't enforce error handling.

[Laiho]

I find it inconstant to be so pedantic about unused vars/imports to avoid bugs, but then leave error handling to what it is.

[AnimalMuppet]

I think solid error handling is the difference between production and prototype code, even in applications. They may not have to be handled in the same way as in systems programming, but they still have to be handled in a careful, consistent, disciplined way.

[masklinn]

> I keep count in my own code of the number of bugs Go's "damnable use requirement" has caught for me, and I'm now up to 5.

Are you saying that you’ve had 5 bugs caused by unnecessary imports?

[tptacek]

I'm saying I've had that stupid import error pop up in my face 5 times and changed my code as a result, rather than the imports, because it surfaced an error.

[ColonelPhantom]

Shouldn't it be a warning, though? You'll still notice it, but you aren't forced to deal with the problem immediately.

[tptacek]

I'm not saying it caught syntax errors. I'm saying it caught actual bugs in my code. I don't want to be allowed to blow those off.

[ColonelPhantom]

>I'm saying it caught actual bugs in my code.

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.

[Gwypaas]

Together with that any reasonable codebase denies any warnings from the compiler, Clippy or changes from running Rustfmt when running CI. Which is pretty much equal to Go best practice, using something like Golangci-lint instead.

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.