Spectral Contexts in Go
hypirion.com
Spectral Contexts in Go
1–10 of 41 posts
Re: Spectral Contexts in Go
#2I'm not a big fan of context variables: they're basically a super clunky kind of goroutine-local global variable, with all the problems you might get with these kinds of mutable global variables. I would argue that if you're having to pass dependencies down, you should be explicitly dependency injecting them instead rather than implicitly via context.
Re: Spectral Contexts in Go
#3Don't do it. Don't past non-request-scoped data through contexts, and none of these are request-scoped. You can trivially pass such values through middlewares using methods or closures.
Also, while I think I know what "unlike Rust, these phantom types appear at runtime in Go" is saying, it's saying it in a really confusing way. These types do not "appear at runtime"; they are exactly like all other types, constructed at compile time and visible when interface-boxed at runtime. They're in no way "spectral".
Re: Spectral Contexts in Go
#4I'm not a big fan of context variables: they're basically a super clunky kind of goroutine-local global variable, with all the problems you might get with these kinds of mutable global variables. I would argue that if you're having to pass dependencies down, you should be explicitly dependency injecting them instead rather than implicitly via context.
They are not "goroutine local", they are essentially (at least the way they are used) a request-local variable. Which in itself is useful tool.
My only real issue with them is lack of type safety so you have to remember which contest var is what.
For example I'd like to have User context variable that is set somewhere early if user is authenticated but now at every subsequent call there needs to be a bit of fluff to check whether it is right type, else you risk runtime safety.
Re: Spectral Contexts in Go
#5I'm not a big fan of context variables: they're basically a super clunky kind of goroutine-local global variable, with all the problems you might get with these kinds of mutable global variables. I would argue that if you're having to pass dependencies down, you should be explicitly dependency injecting them instead rather than implicitly via context.
They are not "goroutine local", they are essentially (at least the way they are used) a request-local variable. Which in itself is useful tool. My only real issue with them is lack of type safety so you have to remember which contest var is what. For example I'd like to have User context variable that is set somewhere early if user is authenticated but now at every subsequent call there needs to be a bit of fluff to…
I think it always a mistake to start a goroutine without passing a context to it, since you are no longer able to cancel the goroutine unless you build your own mechanism to do so. Given that, I think you can handwave it a bit and regard context variables as goroutine local.
Re: Spectral Contexts in Go
#6I'm not a big fan of context variables: they're basically a super clunky kind of goroutine-local global variable, with all the problems you might get with these kinds of mutable global variables. I would argue that if you're having to pass dependencies down, you should be explicitly dependency injecting them instead rather than implicitly via context.
They are not "goroutine local", they are essentially (at least the way they are used) a request-local variable. Which in itself is useful tool. My only real issue with them is lack of type safety so you have to remember which contest var is what. For example I'd like to have User context variable that is set somewhere early if user is authenticated but now at every subsequent call there needs to be a bit of fluff to…
Not sure I understand the typing issue. The standard pattern is to provide an x.Context(ctx, ...) and an x.FromContext(ctx), and those are the only two functions that know about the context key, and they do the type-casting. Since they are the only functions knowing the context key (the key is often a pointer to an unexported variable), you are guaranteed type-safety as long as there is no unsafe code that can pretend-inject the key.
https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/...
Re: Spectral Contexts in Go
#7The author demonstrates attaching services to a context, which afaict goes against the Go authors' usage recommendations in https://pkg.go.dev/context:
> Use context Values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions.
Re: Spectral Contexts in Go
#8[deleted]
Re: Spectral Contexts in Go
#9I'm not a big fan of context variables: they're basically a super clunky kind of goroutine-local global variable, with all the problems you might get with these kinds of mutable global variables. I would argue that if you're having to pass dependencies down, you should be explicitly dependency injecting them instead rather than implicitly via context.
How would you do that with standalone functions? You'll need at least one parameter for cancelation, and one parameter for the logging context, and perhaps one more parameter for tracing.
Even passing the single context variable increases clutter a lot.
Re: Spectral Contexts in Go
#10Earlier quoted context omitted.
They are not "goroutine local", they are essentially (at least the way they are used) a request-local variable. Which in itself is useful tool. My only real issue with them is lack of type safety so you have to remember which contest var is what. For example I'd like to have User context variable that is set somewhere early if user is authenticated but now at every subsequent call there needs to be a bit of fluff to…
Not sure I understand the typing issue. The standard pattern is to provide an x.Context(ctx, ...) and an x.FromContext(ctx), and those are the only two functions that know about the context key, and they do the type-casting. Since they are the only functions knowing the context key (the key is often a pointer to an unexported variable), you are guaranteed type-safety as long as there is no unsafe code that can preten…
When people mention type safety in this context, they are talking about compiler guarantees. Application code that uses type assertions will never be "type safe" in the way that a compiler can ensure. So while you're correct that if the application code that does the type checking is bug free then the type safety is implied, but is not certain in all cases.