4 ms·

The problem with such rejection is that every serious project written in Go has invented compiler warnings outside the compiler, with linters.

by jen20 2y ago

foldr 2y ago
Is this a problem? Linters are also used with lots of languages that do have compiler warnings. Go just removes the no man’s land between honest-to-goodness compiler errors and linter warnings about code smells. I see no issue with having the latter handled entirely by tools designed for the job.
kjksf 2y ago
Why is it a problem? `go vet` is part of Go toolchain so the designers very much understand and acknowledge that code can have issues that are not always errors. The distinction they made is very simple: an error is something that is always wrong and a vet warnings is something that is possibly wrong but not always. They made a judgement call to split the responsibility: compiler only reports errors, other tools, including `go vet`, can tell you about other issues. For example: passing a large struct by value to a function is potentially a performance problem but it's also correct code. If you ever tried to compile C++ code with different compilers you would know why it's a wise decision. The set of warnings is vast and not standardized so you take C++ source from project. It compiles for them but doesn't compile for you because you use different compiler or enabled different set of warnings. At which point you either try to get the other project to "fix" something that isn't an issue for them or you do stupid, pointless, time consuming work adjusting your build system. The same would happen in Go and it would be a reusability killer. You use some library in your program but it doesn't compile because you decided to use more strict set of flags. Lack of warnings switches also simplifies the toolchain. In go it's just `go build` and it works. In C++ you have to write some kind of makefile because everyone executes `cc` with different set of flags.

The problem with such rejection is that every serious project written in Go has invented compiler warnings outside the compiler, with linters.

by jen20 2y ago

The problem with such rejection is that every serious project written in Go has invented compiler warnings outside the compiler, with linters.

foldr 2y ago

Is this a problem? Linters are also used with lots of languages that do have compiler warnings. Go just removes the no man’s land between honest-to-goodness compiler errors and linter warnings about code smells. I see no issue with having the latter handled entirely by tools designed for the job.

kjksf 2y ago

Why is it a problem? `go vet` is part of Go toolchain so the designers very much understand and acknowledge that code can have issues that are not always errors. The distinction they made is very simple: an error is something that is always wrong and a vet warnings is something that is possibly wrong but not always. They made a judgement call to split the responsibility: compiler only reports errors, other tools, including `go vet`, can tell you about other issues. For example: passing a large struct by value to a function is potentially a performance problem but it's also correct code. If you ever tried to compile C++ code with different compilers you would know why it's a wise decision. The set of warnings is vast and not standardized so you take C++ source from project. It compiles for them but doesn't compile for you because you use different compiler or enabled different set of warnings. At which point you either try to get the other project to "fix" something that isn't an issue for them or you do stupid, pointless, time consuming work adjusting your build system. The same would happen in Go and it would be a reusability killer. You use some library in your program but it doesn't compile because you decided to use more strict set of flags. Lack of warnings switches also simplifies the toolchain. In go it's just `go build` and it works. In C++ you have to write some kind of makefile because everyone executes `cc` with different set of flags.