But it's slow if you modified a file that is not involved in tested code paths.
This is just one concrete example. In general when the code size grows, very quickly it becomes impossible to tell if a given edit could possibly affect tests or not. So you want to run `go test` just in case so making it faster is a good thing.
Before 1.10 `go test` used to re-run tests unconditionally.
Since 1.10 it'll avoid re-running them in some cases.
Neither me nor the announcement claims "intelligence".
The rules are simple and effective which is the Go Way.
While you could try to make even better, more "intelligent" rules for determining wether to re-run the tests, those would quickly run into engineering complexity chasing diminishing returns. That is not the Go Way.
Historically the argument against them have been about adding needless complexity. I wonder who was asking for this and how they got it prioritized.
It was implemented by rsc subsequently, after discussion on the issue: https://go-review.googlesource.com/c/go/+/75631
I'm not sure what you're trying to insinuate.
This makes it wildly different from language changes, which require a lot more consideration.