4 ms·
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 u
by erik_seaberg 6y ago
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.
- masklinn 6y agoWhat would "first-class context handling" be though, dynamic scoping?
- kevincox 6y agoProbably. 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.
- erik_seaberg 6y agoI'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.
- earthboundkid 6y agoI 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.