Hacker News Reader

Comment by cle | Hacker News Reader

I really disagree with this. A function taking a Context is a really important signal to me about the semantics of that function. I also much prefer being able to see context values explicitly passed around, instead of values that magically appear out of the ether, without a clear code path to find out where they came from, what goroutine it's bound to, where that goroutine came from and its lifecycle, etc.

View on HN

The context is just a big bag of stuff. you don't know what's really in it. Ends up almost any method that needs something from the big bag ends up having a context parameter, but you don't know why that method needs it.

Separating these concerns (cancellation vs. bag-of-request-scoped stuff) might make sense. I'm specifically talking about the cancellation side of contexts. I don't think there's a good answer to this other problem of whether those two concerns should be combined into one mechanism, the options that I know about all have mixed tradeoffs.

I still think an explicit bag-of-stuff is better than an implicit one though.

Believe me I've tried to write Go code that doesn't follow the Go conventions and can't get my PRs approved even with tiny differences. So the idea that I could separate these two concerns might be a good one, but in practice it would be impossible.

Right, you don't know what's in it, but you know you need to forward it if you start a goroutine.

I also need to forward it to nonroutines because there is a logger in the context and almost every function wants to use the logger. So essentially, we have to almost alway pass context as the first argument to any function unless its some private function trivial function.

Yes, but I will curse everyone who didnt pass the logger so we lost the logcontext :(

Treating a context value as a bag to fetch data out of is the first mistake. They should only ever be used to control things like deadlines and whether or not a part of a function executes. IMHO they should disallow attaching values to a context.

Yes/no/maybe? context is one of the few ways to get contextual logging and tracing to work in a almost general way in Go. But I have also used it to pass the authenticated user to the handlerfunc. I dont dig it, but it works and avoids the need to keep a static map of request pointers somewhere to figure out which user was in this request...

Reply on news.ycombinator.com