Little things like this are why Go is great. People make arguments against Go based just on available language syntax, but languages are more than just syntax; it is about the end-to-end development flow. I actually think C# and the .NET platform are the only other ecosystem that looks at development the same way. In most other ecosystems, you almost always need to step outside what the built-in language platform provides for any moderately complicated use-case.

Nice! Tracking connection reuse is really important if you are running any kind of benchmarks or comparisons both as the author of a new tool / service and as the person evaluating different options or client libraries.

I've hit a lot of walls not ensuring I was using connection pools correctly even when the service I'm calling was local/docker. File descriptor exhaustion happens often if you're not careful.

Author here... Thanks for sharing this. It has been fun to use while we get ready to launch https://probes.dev with tracing being core to the service.

I wish I had known this two years ago. I ended up writing my own embedded connection struct to trace these things [0].

  type Connection struct {
    net.Conn
    OnEventCallback func(clientClosed bool, serverClosed bool, err error)
  }

[0] https://github.com/s-macke/SlapperX/blob/master/src/tracing/...

hn title mangling strikes again.