I agree on the getting the experience right for Go users piece and I think that we both see our views as in line with that theory. I think having less surprising, less gotchas and less defaults-gone-wrong behavior is better than enabling things that will get in their way and cost them development time. Remember the old adage that there are two hard things in programming, one of which is cache invalidation. I don't think we can get this correct. And so I stand by my point that this as a default will cause more harm than good. By the time a user has a sizable enough project (or dependencies) where test caching makes sense to use, it's reasonable to expect that they are no longer a beginner and that they can learn to use the flag if required to save themselves some test-run time. The other good thing about this, is we can easily change the default later to on once we figure out how good the feature is.
In addition to that I think our viewpoints on test caching are different because our use cases of Go are different. I come upon this feature not as someone who deals with large berths of unchanging Go packages all the time (Go and it's standard library, presumably like yourself), but relatively small packages that interact with databases. In my use case I don't want my tests cached on my primary project as my test bottleneck is not the Go code that would be cached, but the database interaction that cannot be cached (because of the lack of invalidation at this layer). I understand you'd like me to try it, but if there's a provable theoretical problem with it, isn't it practical to address it, and isn't switching the default a reasonable way to address that? In the end I still feel strongly against the inclusion of test caching by default, and think it will bring pain to those who are not specifically asking for the feature whom are knowledgeable and who can turn it on when necessary anyway. On the go vet issue I'm actually a bit indifferent and no longer wish to pursue it's exclusion as a default simply because I don't care about this one enough. But I still think you should think on the arguments I've made here because it's a very inconsistent position to have taken. To glob on to go test's responsibilities but at the same time rejecting the idea that these same issues discovered by go vet cause major problems in normally compiled code is odd. The major problem with that stance of course is allowing one and disallowing the other for the same crimes. I've made some additional comments inline. Thanks for taking the time to respond. I've made all my points and don't want to waste your time with another response, so I will try these features and report the cache invalidation issue with a real use case and real code to show why it's a problem. Thanks very much for Go 1.10 and each release before it, I really enjoy the language. Aaron On Friday, December 8, 2017 at 11:21:37 AM UTC-8, Russ Cox wrote: > > First, a general point. > > We care very much about getting the default experience right for Go users. > These features are opt-in because we believe in both cases that "on" is the > right default, that developers will be more productive with these on by > default than having to know to opt in. > > - You should also not have to ask for "go test" to point out certainly > erroneous code instead of forcing you to find that code by debugging a test > failure. > > This conflates the idea of testing the code by running the tests you've created, with making sure the code is clean and correct. But this just suggests even further that if there are such "certainly erroneous" pieces of code, that the compiler should be catching it. If it is necessary for the program to run correctly, then it should not be a valid program, the inclusion of this feature as a default even demonstrates the need for it. > - You should not have to ask for "go test ./...; modify a few source > files; go test ./..." to do the right thing and only rerun the test > binaries affected by your changes. > > Doing the right thing and only rerunning the test binaries affected is not always the right thing, just sometimes, cache invalidation as noted above. > A new Go programmer who doesn't know these features exist should get the > benefit of these from day 1, without having to learn to set extra > configuration (which doesn't actually exist) or type extra arguments on > every go test command. Of course, turning them on by default means they > have to be right, and we're very sensitive to that. If you find concrete > examples where automatic vet or automatic test caching is causing you pain, > please file issues so that we can look to see if the defaults need further > adjustment. But please give them a chance first, actually try them, and > then report concrete problems, not hypotheticals based on simply reading > the release notes. > > Now a few specifics. > > For test caching: > > > Or maybe you are trying to debug a flaky test (up-enter enough times to > get the intermittent error back now requires a -count=1). > > > Two things about this. First, you only have to type -count=1 once, since > the next up-enter will get it. But second, you may not have to type it all. > If the command you are running is "go test", with an implicit "test the > current directory", then there is no caching. See the description of "local > directory mode" in http://beta.golang.org/cmd/go/#hdr-Test_packages. > > It's about having the presence of mind to notice that the run has been cached, and remember to the obscure way to turn it off, we're introducing the ability for human error, for someone not to notice, and that's detrimental. I will be a bit bullish on the obscurity of how to turn it off, it's fairly obscure and "clever" to force a count to be 1 instead of 0, -nocache simply makes much more sense to me and probably to anyone reading the help and trying to understand how to turn it off. > For vet during test: > > > why just go vet? > > Because vet is about correctness, and so is testing. If you are running > "go test", you are in effect saying "check for bugs in this package". If > those bugs can be reported directly - this line has this specific problem - > instead of indirectly as test failures, that seems like a win. > This is a reasonable argument if you're willing to conflate "code correctness" with "run test code". I'm not yet willing to make the jump but happy to leave that one up in the air. > > > Why a subset of its checks? > > Because vet has historically been opt-in, not all of the checks are > appropriate to make opt-out. In particular, we won't enable a check during > 'go test' unless it is accurate essentially 100% of the time, and if that > "essentially 100%" is not exactly 100%, there has to be a very clear > workaround. The idea is that vet sits quietly and you don't know it's > running until it speaks up with something important, something you actually > are happy to find out about and fix without debugging a test. If we are > falling short of that with a specific check, please file an issue with > concrete details. > > > Why not golint? > > Because golint is not about correctness. Golint is mostly about what your > code *looks* like, not what it means. The things it points out aren't > nearly important enough to block running a test. > That's fair, I was trying to use a slippery slope argument. The inclusion of go vet's subset of tests opens the gates for the inclusion of any number of other things that could be lumped under the guise of "correctness". If these vet changes are indeed optional. > > > why are they not compiler errors? > > There's a balance to strike here, again to make sure that opt-out is > reasonable. The code is valid Go code, as you say, so it probably should > continue to compile, especially if it's just someone else's dependency. > Maybe that code path never runs in the program being compiled. On the other > hand, when you are running "go test" of a specific package, you're asking > "check for bugs in this package", so that seems like exactly the right time > to subject that package's code (and only that package) to additional > correctness checks and report any problems. > > The argument here seems to want to be on two sides of a fence. Either go vet's callouts are critical to the success of running programs, or it is not. If the case is being made that the problems are critical to the program's successful running, then they should be compiler errors. Why not eliminate all this bad code from the Go ecosystem. It feels bad if there is a large corpus of Go code that's not been 'go vet'd' and therefore cannot possibly run correctly that is sitting in my vendor directories. If we're going to make changes like this that are opinionated about what code can be tested, why not about what code can be compiled? It's possible this is a Go2 level discussion but creating such a discrepancy between test and build in the toolchain feels bad. If the argument is that we "should" run these things because the fixes - while not absolutely critical - would improve the program then why is it being run automatically? At that point it's no more than golint is.. > Once again, please give these a chance, try them, and report problems on > the issue tracker, with concrete details. That's how we'll make sure these > are ready to be on by default. > > Thanks for your help testing Go 1.10. > > Best, > Russ > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
