Some punning with the title from Dave! I'll be interested to see where they go with this, but I can't say that the current context setup bothers me overly. Yes it can be abused and overused, but then so can patterns like middleware, closures, dependency injection or package globals - each have their place and a request specific bag of values is necessary sometimes (for carrying a trace id for example to trace execution across stacks, or carrying auth information from middleware through to handlers.
That said it'd be fine to separate out the concept of context for request-specific values and context for request timeouts or cancellation (which possibly belong elsewhere, not on the request). I suspect if looking at it again afresh (for go 2 say) they would perhaps redo the request struct and handle these three separate things itself as separate concerns. The end result would not be dissimilar though and the current approach lets us use this now, with the go 1 promise intact.
I really like context, it solves real problems, hope they don't get rid of it.
Some punning with the title from Dave! I'll be interested to see where they go with this, but I can't say that the current context setup bothers me overly. Yes it can be abused and overused, but then so can patterns like middleware, closures, dependency injection or package globals - each have their place and a request specific bag of values is necessary sometimes (for carrying a trace id for example to trace execution across stacks, or carrying auth information from middleware through to handlers.