> It’s very similar to thread-local storage. We know how bad of an idea thread-local storage is. Non-flexible, complicates usage, composition, testing. I kind of do wish we had goroutine local storage though :) Passing down the context of the request everywhere is ugly.
Context should go away for Go 2 (2017)
11–20 of 176 posts
Re: Context should go away for Go 2 (2017)
#12React has "Context", SwiftUI has "@Environment", Emacs LISP has dynamic scope (so I heard). C# has AsyncLocal, Node.JS AsyncLocalStorage.
This is one of those ideas that at first seem really wrong (isn't it just a global variable in disguise?) but is actually very useful and can result in cleaner code with less globals or less superfluous function arguments. Imagine passing a logger like this, or feature flags. Or imagine setting "debug = True" before a function, and it applies to everything down the call stack (but not in other threads/async contexts).
Implicit context (properly integrated into the type system) is something I would consider in any new language. And it might also be a solution here (altough I would say such a "clever" and unusual feature would be against the goals of Go).
Re: Context should go away for Go 2 (2017)
#13Re: Context should go away for Go 2 (2017)
#14This is about an explicit argument of type "Context". I'm not a Go user, and at first I thought it was about something else: an implicit context variable that allows you to pass stuff deep down the call stack, without intermediate functions knowing about it. React has "Context", SwiftUI has "@Environment", Emacs LISP has dynamic scope (so I heard). C# has AsyncLocal, Node.JS AsyncLocalStorage. This is one of those id…
Re: Context should go away for Go 2 (2017)
#15Re: Context should go away for Go 2 (2017)
#16This is about an explicit argument of type "Context". I'm not a Go user, and at first I thought it was about something else: an implicit context variable that allows you to pass stuff deep down the call stack, without intermediate functions knowing about it. React has "Context", SwiftUI has "@Environment", Emacs LISP has dynamic scope (so I heard). C# has AsyncLocal, Node.JS AsyncLocalStorage. This is one of those id…
https://medium.com/androiddevelopers/under-the-hood-of-jetpa...
I’m still not sure how I feel about it. While more annoying, I think I’d like to see it, rather than just have magic behind the hood
Re: Context should go away for Go 2 (2017)
#17What a nice attitude.
Re: Context should go away for Go 2 (2017)
#18I was unsuccessful to convey the same message in my previous company (apart from being fired part). All around the codebase you'd see function with official argument and unofficial ones via ctx that would panic everything if you forgot it was used 3 layers down (not kidding). The only use case I've seen so far that is not terrible of context value is if you have a layer of opentelemetry as it makes things transparent and as a caller you don't have to give a damn how the telemetry is operated under the hood.