The testing/synctest experiment is interesting to me. That kind of testing isn’t easy to do well, and I’ve seen a lot of people get it wrong, and a lot of fake-clock libraries that miss the mark and don’t provide a reliable way to synchronize the test code with the code under test. At $WORK we wrote and published our own library that does allow getting it right, but it’s still a lot of work, and it’s a huge pain if you ever use third-party code that wants to use time and doesn’t know about your fake clock.
synctest is able to make things a lot simpler because it has the backing of the runtime. Anything started within it gets a version of the time package that uses a fake clock kind of like the one in the Go Playground, and specially instrumented channels. That means no compatibility pain, but also more symmetry between the test harness and the code being tested. If you want to set something up and then assert that something is true 30 seconds later, the test code just needs to time.Sleep(30*time.Second) in between those two points, and then synctest.Wait() to run everything to quiescence. Sometimes the Wait isn’t even needed, but I don’t think it ever hurts.
I never understood the desire for building external tools using the go.mod of the repo you use them in. I’d rather just pin and build tools I used based on the released versions with same dependencies that the author builds, tests, and releases with.
While this is a good point, it doesn’t cover the fact that Go was one of the only languages that I know that didn’t had a good way to pin tools versions, that ends up creating the unfortunate issue in how you declare those tools in the specific version you need and keep it up to date.
This almost always involved a sub-optimal solution, either tools.go (with all its issues) or having some other way to declare it (it could be in README.md of the project or a Makefile), but you ended up needing something.
I usually just write go run tool@version in scripts but I see the issue. This tools solution would be fine to me UX wise but I’d always want the tools built with the go.mod.of their main!
The
testing/synctestexperiment is interesting to me. That kind of testing isn’t easy to do well, and I’ve seen a lot of people get it wrong, and a lot of fake-clock libraries that miss the mark and don’t provide a reliable way to synchronize the test code with the code under test. At $WORK we wrote and published our own library that does allow getting it right, but it’s still a lot of work, and it’s a huge pain if you ever use third-party code that wants to usetimeand doesn’t know about your fake clock.synctestis able to make things a lot simpler because it has the backing of the runtime. Anything started within it gets a version of thetimepackage that uses a fake clock kind of like the one in the Go Playground, and specially instrumented channels. That means no compatibility pain, but also more symmetry between the test harness and the code being tested. If you want to set something up and then assert that something is true 30 seconds later, the test code just needs totime.Sleep(30*time.Second)in between those two points, and thensynctest.Wait()to run everything to quiescence. Sometimes theWaitisn’t even needed, but I don’t think it ever hurts.Some of the things that I found interesting:
go.mod(https://go.dev/issue/48429): no moretools.gojust so you can pin tools versionsruntime/debug.BuildInfo.Main.Version: https://go.dev/issue/50603go test/build -json): https://go.dev/issue/62067crypto(pure Go instead of the previous solution using BoringSSL): https://go.dev/issue/69536I never understood the desire for building external tools using the go.mod of the repo you use them in. I’d rather just pin and build tools I used based on the released versions with same dependencies that the author builds, tests, and releases with.
While this is a good point, it doesn’t cover the fact that Go was one of the only languages that I know that didn’t had a good way to pin tools versions, that ends up creating the unfortunate issue in how you declare those tools in the specific version you need and keep it up to date.
This almost always involved a sub-optimal solution, either
tools.go(with all its issues) or having some other way to declare it (it could be in README.md of the project or a Makefile), but you ended up needing something.I usually just write go run tool@version in scripts but I see the issue. This tools solution would be fine to me UX wise but I’d always want the tools built with the go.mod.of their main!
I also enjoyed going through the deck “Go ten years ago, Go ten years from now”, also from Daniel Marti. I was interested to learn about Go moving to a swisstable-based hashmap.
You can also look at https://tip.golang.org/doc/go1.24
Really pumped for the
go toolsubcommand. It will be a lot easier to keep these updated, instead of having a makefile variable that is growing stale.Oh man, GOAUTH has been a long time coming.