It's not so much off-putting as just covering up for the fact that the explanation above is pedagogically bad. I had to open both snippets in two tabs so I cou

It's not so much off-putting as just covering up for the fact that the explanation above is pedagogically bad. I had to open both snippets in two tabs so I could flip between them and spot all the actual differences, which is that 1) the listener creation was moved out of the go-routine, 2) the port was changed to auto, and 3) the sleep call was removed. Making the server support multiple instances at same time is a distraction, because you could do the same with the old code. The trick here is that creating the listening socket in the original thread means you can also use auto-port assignment and then fetch the port from the returned object. This would be unnecessary if you queried for a free port first, so perhaps the point here is that an atomic port reserve-and-listen system also prevents race conditions over the port number. These are all good angles that could be naturally woven into the explanation. Instead you get furries discussing moldy bread, which doesn't tell you anything, but I suppose makes both reader and writer feel like they got something out of it. Personally, I feel like the post is cheating by suggesting "in order to synchronize a server and a client, just create the server inside the client!" ... ummm. If you could do that, you wouldn't have a synchronization problem in the first place.