Live data from Hacker News

Context should go away for Go 2 (2017)

faiface.github.io

11–20 of 176 posts

Re: Context should go away for Go 2 (2017)

#11

> 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.

Goroutines have a tiny stack at the beginning, 4KB iirc. Having a goroutine-local storage will probably open a can of worms there.

Re: Context should go away for Go 2 (2017)

#12
This 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 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)

#14

This 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…

Scala has implicit contextual parameters: https://docs.scala-lang.org/tour/implicit-parameters.html.

Re: Context should go away for Go 2 (2017)

#16

This 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…

In Jetpack compose, the Composer is embedded by the compiler at build time into function calls

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)

#18
> If you use ctx.Value in my (non-existent) company, you’re fired

I 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.

Re: Context should go away for Go 2 (2017)

#20
post #3

Earlier quoted context omitted.

Yes, I was about to comment that “there won’t be a Go 2”, but I guess that wasn’t settled when the article was written.

as someone who's not in the community: why not?

To not repeat other's (Python) mistakes ;-)
Post reply on HN