I would like a way of efficiently reading any available data from a net.Conn without blocking.

I'm the creator of the PostgreSQL database driver https://github.com/jackc/pgx. The PostgreSQL protocol is synchronous in almost all cases. The server typically does not send any unexpected messages. The overwhelming majority of network activity is simply sending a query and reading the response.

However, on rare occasions the server will send an unsolicited message (e.g. server shutting down, server settings changed, listen / notify notifications, etc.). It would be very helpful to be able to check for a pending unread message before sending a query to the server.

As I understand it, the standard advice is to use a goroutine to read the net.Conn and pass received messages through a channel. (The other occasionally mentioned suggestion is to use syscall.RawConn and do non-blocking reads at a lower level, but I don't think that is possible when using a *tls.Conn). I built a proof of concept variation of the driver that used a goroutine and a buffered channel and it caused the overall runtime of a simple select to increase by 22% when connected to a server on the same host.

In addition to the unacceptable performance cost, it also greatly increases complexity to have to manage goroutines and channels. For example, the PostgreSQL copy protocol can be used to send large amounts of data to the server at once (potentially millions of rows). In theory, this could be done in a single conn.Write(...). However, in rare occasions the server may send back data before the client has finished sending data. If both the client and the server send a large amount of data a deadlock will occur when the network buffers on either side fill up.

I want to handle this with simple code like the following:

for buf, more := getNextChunk(); more {
  conn.Write(buf)
  // handle errors

  conn.ReadNonBlocking(...)
  // handle any messages the server sent us
}

Instead, I have to use a couple goroutines and do concurrent reading and writing -- much more complicated than the idealized code above.

One of major advantages of Go is that I/O operations can be written in an easy to understand synchronous style instead of using callbacks, promises, or async -- the runtime handles it in the background. Even though Go's channels and goroutines make writing concurrent code easier it is still difficult and error prone. I don't want to do it unless I really have to. And the lack of a non-blocking read forces me to write concurrent code.