Most experienced, or even intermediate, Nix users probably already know to clean their sources. However, I can't recall any Nix tutorials explaining how or why you should "clean the source". Simply, you should filter a source tree to remove version control files and build results. This prevents those files from contaminating the tree imported by the Nix builder, and this leads to more repeatable builds.
The authors of the Go language have invested to ensure that benchmarking and profiling are well-supported by the language's tooling. This puts Go ahead of many other language, but the tools provided fall short of being sufficient. The standard tools don't handle measurement uncertainty, and so cannot (on their own) correctly answer basic performance questions.
In Canada, bill C-10 is generating controversy. I don't have an opinion, mostly because it is not clear to me what it regulates. I suspect that ambiguity about what constitutes user-generated content is driving a lot of the controversy. Discussion is hampered by a category error.
Go's standard library includes a useful function,
time.Sleep, which pauses the current goroutine for at least the specified duration. This is all well and good, and commonly found in the standard libraries of many languages, but unfortunately the function is less useful in a post-context world.
Unpopular opinion: Idiomatic Go panics. Not instead of proper error handling, but there remain times when panicking is the best option for correct code. Unfortunately, the use of panic is frowned upon so strongly that even correct uses are likely to get criticized in review. This post hopefully explains when panics are acceptable and idiomatic in Go.