In our experience, missing network timeouts are one of the first sources of resiliency bugs in server applications. Unfortunately, these bugs are rare to experience during development and are not very easy to write tests for. As a result, we often see components hanging because somewhere in a dependency three layers down someone forgot to add an explicit timeout to a network connection/request/call. This is the result of many factors, one being that many languages (Go included) does not have default timeouts for network operations even though having a default timeout would align better with the common case (how many times do network operations require to not have timeouts?)

I realize this may be seen as an over-reaction to the problem, but I would argue that if the Go standard packages had default timeouts set on all network operations a whole class of resiliency problems would, for the majority of uses, disappear.

A couple of notes:

• I'm not arguing it would solve all network-triggered resiliency problems in all cases, only in a good majority.
• I'm also not arguing that users shouldn't be allowed to explicitly disable such timeouts, or to set them to something different. While I argue that the common case is that network operations should have a timeout, I agree that there may be a minority of cases where no timeouts make sense (the most common being when a different mechanism to detect timeouts is in use).

To summarize the proposal:

• A suitable set of default timeouts should be identified (e.g. in net/http: add InactivityTimeout to http.DefaultClient #22982 @bradfitz suggests 3 minutes as reasonable for http.DefaultClient)
• The default timeouts identified above should be added to the Go standard packages

I'm unsure if this would break go1 compat, so feel free to classify as Go2 if required.