I agree, the current behaviour is quite unfortunate. In fact, I'm pretty sure I added an entry point named recv_ to network-bytestring to work around precisely this problem.

 

I think that it was modeled after the Handle API, which provides an isEOF function that you can call to see whether a Handle is done before you try reading it. This works well enough on a Handle because it's buffered, but sockets aren't buffered, and the symmetric isEOF function isn't available. I don't like the way the Handle API works, but I grudgingly accept it as not amenable to change.

There's another problem with the network APIs: they mirror the BSD socket API too faithfully, and provide insufficient type safety. You can try to send on an unconnected socket, and to bind a socket that's already connected, both of which should be statically forbidden. The APIs for datagram-oriented networking ought to be distinct from the stream-oriented variety, I think, even if the underlying C-level calls end up being substantially the same.

Really, the big thing that's missing here is enough application of elbow grease from someone who's got a good eye for design and doesn't mind all the slog involved. I think that if someone published a network-alt package (much like the one that was published a few years ago) and tooted their horn vigorously enough, we could put the existing network package out to pasture in fairly short order.