Some thoughts: - The general point is correct -- time is not a synchronization mechanism - Flakey tests are bad for all the reasons listed - Shoddy synchroni

Some thoughts: - The general point is correct -- time is not a synchronization mechanism - Flakey tests are bad for all the reasons listed - Shoddy synchronization makes for flakey tests The example chosen -- waiting for a test server to be available is probably a huge source of the issues. However, I don't think the example -- really demonstrates how to do synchronization. My core objection is that it's really relying on the operating system to take care of the synchronization, and that winds up hiding it entirely: - the dial will not happen until the operating system has competed the `listen` call - the operating system is selecting a random port at the time of the `listen` call, and reports the chosen port to the user This is the correct way to approach this problem, but it doesn't really show a proper synchronization. It shows the operating system synchronizing on behalf of the program. It's also an example that probably only shows up in test -- client and server in the same process space. In practice, many clients and servers may start at the same time in different processes or on different hosts, meaning that the client has no signal at all that the server has become ready. The best thing that can really be done is quickly polling with low timeouts until the server reports healthy. I'd have liked to see use of a `sync.Cond`, or channel to signal that the operation has completed, and the waiting goroutine being safe to continue. It wouldn't fit well in this example, because, well, the operating system provides those facilities. Over, because it does come up a lot with the example used, I'm happy there is a blog posts addresses it. Hopefully I'll see less of the problem in the world. I suppose I hope the author writes a part 2, showing other ways sleeps creep in and how to remove them.