[frankie_t]

If you use a type like `map[string]any` then yes, it's going to be the same as Context. However, you can make a struct with fields of exactly the types you want.

It won't propagate to the third-party libraries, yes. But then again, why don't they just provide an explicit way of passing values instead of hiding them in the context?

[eadmund]

> why don't they just provide an explicit way of passing values instead of hiding them in the context?

Hiding them in a context is the explicit way of passing values through oblivious third-party libraries.

In some future version of Go, it would be nice to just have dynamic scoping. But this works now, and it’s a good pattern. The only real issue is the function-colouring one, and that’s solvable by simply requiring that every exported function take a context.

[skywhopper]

Precisely because you need to be able to pass it through third party libraries and into callbacks on the other side where you need to recover the values.

[lawrjone]

Yeah most people talking here are unlikely to have worked on large scale Go apps.

Managing a god-level context struct with all the fields that ever could be relevant and explaining what they mean in position independent ways for documentation is just not scalable at all.

Import cycles mean you’re forced into this if you want to share between all your packages, and it gets really hairy.