Sometimes, I feel like I don't quite understand the core Go team's writings. I don't mean this in a bad way, though. We are computer scientists by nature, not craftsmen of prose. And yet, I have this feeling that we could strive to do a better job at communicating our thoughts, especially when something as
big as the future of Go is at stake.
The particular occasion that made me share my thoughts was this recent post on Go generics by Russ Cox.
I claim to be somewhat versed in both reading and writing, but it took me a couple of reads before I found the interesting bits in it.
Without going into a deep analysis at this point, I am simply going to share those highlighted excerpts below:
Because we will not have any production experience with generics, we will make clear in the release notes that production uses of generics should be approached with appropriate caution.
If you are updating your package to use generics, please consider isolating the new generic API into its own file, build-tagged for Go 1.18 (//go:build go1.18), so that Go 1.17 users can keep building and using the non-generic parts.
third-party tools may not support generics in full at the Go 1.18 release
the only way to reduce the uncertainty is to make generics available by default
The most important thing everyone here can do is write some generic code and let us know if you find bugs, unclear compiler errors, and so on. I have written some generic data structures recently and am very happy with the overall experience.