Hacker News Reader

Comment by bigdubs | Hacker News Reader

The issue here is contexts were introduced after the API for `http.NewRequest()` was guaranteed to be stable, so there are in effect (2) different versions of the api, one without contexts and one with.

IMHO it's a rock and a hard place; either you break compatibility, or you have a slightly more confusing API.

View on HN

Or you add first-class context handling to the language, because this won't be the last time and continually adding more plumbing to every method signature is unsustainable.

What would "first-class context handling" be though, dynamic scoping?

Probably.

I know dynamic scoping is considered dirty but I'm not convinced that it doesn't have its place. I think the problem in the past is that dynamic scoping often replaced syntactic scoping. But it can be a nice replacement for when you are deciding between a global or a context parameter to every function.

I'm thinking something like panicking all the goroutines started in a context that's been cancelled, and something like defer to handle cleanup during cancellation. Some expression that can read and write a typed value for a key in the current context (not even the standard library can do this without generics). If contexts have to become part of the calling convention, that's fine, just don't add more noise to every function call in the source.

I think dynamic state makes more sense than package level state for Go. Anything package level need to be either read-only or mutex-locked for thread safety. Removing package level state and having per call dynamic state instead would be better.

At least having a deprecation warning in the docs would be nice. Doing it compile time doesn't seem like the kind of thing golang would do; that seems like a thing external linters might have in that ecosystem (and likely already does).

Reply on news.ycombinator.com