←back to thread

257 points pmig | 1 comments | | HN request time: 0s | source
Show context
bryancoxwell ◴[] No.43096481[source]
> But there are obviously work around solutions in the Go ecosystem. It uses the Context ctx, which we pass around functions in order to juggle data around in the application.

Man. This works. The context API allows/enables it. But I’d really recommend against passing data to functions via context. The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing, but this breaks down when data is hidden inside a context. Dependency injection is entirely possible without using the context package at all, interfaces are great for it.

replies(8): >>43096604 #>>43096796 #>>43096956 #>>43097757 #>>43098179 #>>43098205 #>>43099616 #>>43099625 #
cflewis ◴[] No.43096796[source]
FWIW the internal Google style guide says to not pass anything via Context unless you _really_ know what you're doing and why. Things that make sense: security tokens and tracing. Things that don't make sense: almost everything else.
replies(2): >>43098194 #>>43099440 #
throwaway2037 ◴[] No.43098194[source]

    > internal Google style guide
Can we read this somewhere?
replies(2): >>43098893 #>>43099040 #
konart ◴[] No.43099040[source]
I'm not sure about Google style guild but Go's context package docs state:

"Use context Values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions."

https://pkg.go.dev/context

Using context as a some sort of a mule is an antipattern.

replies(1): >>43109870 #
throwaway2037 ◴[] No.43109870[source]

    > Using context as a some sort of a mule
I never saw the term "mule" used in this way. Very succinct!
replies(1): >>43109914 #