[kalekold]

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

This is such a bad take.

ctx.Value is incredibly useful for passing around context of api calls. We use it a lot, especially for logging such context values as locales, ids, client info, etc. We then use these context values when calling other services as headers so they gain the context around the original call too. Loggers in all services pluck out values from the context automatically when a log entry is created. It's a fantastic system and serves us well. e.g.

    log.WithContext(ctx).Errorf("....", err)

[sluongng]

Let me try to take the other side:

`ctx.Value` is an `any -> any` kv store that does not come with any documentation, type checking for which key and value should be available. It's quick and dirty, but in a large code base, it can be quite tricky to check if you are passing too many values down the chain, or too little, and handle the failure cases.

What if you just use a custom struct with all the fields you may need to be defined inside? Then at least all the field types are properly defined and documented. You can also use multiple custom "context" structs in different call paths, or even compose them if there are overlapping fields.

[Thaxll]

Because you should wrapp that in a type safe function. You should not use the context.GetValue() directly but use your own function, the context is just a transport mechanism.

[kflgkans]

If it is just a transport mechanism, why use context at all ant not a typed struct?

[ncruces]

Because dozens of in between layers don't need to know the type, and should in fact work regardless of the specific type.

Context tells you enough: someone, somewhere may do magic with this if you pass it down the chain.

And in good Go tradition it's explicit about this: functions that don't take a context don't (generally) do that kind of magic.

If anything it mixes two concerns: cancelation and dynamic scoping.

But I'm not sure having two different parameters would be better.

[bluetech]

> `ctx.Value` is an `any -> any` kv store that does not come with any documentation, type checking for which key and value should be available

The docs https://pkg.go.dev/context#Context suggest a way to make it type-safe (use an unexported key type and provide getter/setter). Seems fine to me.

> What if you just use a custom struct with all the fields you may need to be defined inside?

Can't seamlessly cross module boundaries.

[smarkov]

> `ctx.Value` is an `any -> any` kv store that does not come with any documentation, type checking for which key and value should be available.

On a similar note, this is also why I highly dislike struct tags. They're string magic that should be used sparingly, yet we've integrated them into data parsing, validation, type definitions and who knows what else just to avoid a bit of verbosity.

[homebrewer]

Most popular languages support annotations of one type or another, they let you do all that in a type safe way. It's Go that's decided to be different for difference sake, and produced a complete mess.

[saghm]

IMO Go is full of stuff like this where they do something different than most similar languages for questionable gains. `iota` instead of enums, implicit interfaces, full strings in imports (not talking about URLS here but them having string literal syntax), capitalization as visibility control come to mind immediately, and I'm sure there are others I'm forgetting. Not all of these are actively harmful, but for a language that touts "simplicity" as one of its core values, I've always found it odd how many different wheels Go felt the need to reinvent without any obvious benefit over the existing ones.

[techbrovanguard]

the second i tried writing go to solve a non-trivial problem the whole language collapsed in on itself. footguns upon footguns hand-waved away with "it's the go way!". i just don't understand. the "the go way" feels more like a mantra that discourages critical thinking about programming language design.

[throw_m239339]

> `ctx.Value` is an `any -> any`

It did not have to be this way, this is a shortcoming of Go itself. Generic interfaces makes things a bit better, but Go designers chose that dumb typing at first place. The std lib is full of interface {} use iteself.

context itself is an after thought, because people were building thread unsafe leaky code on top of http request with no good way to easily scope variables that would scale concurrently.

I remember the web session lib for instance back then, a hack.

ctx.Value is made for each go routine scoped data, that's the whole point.

If it is an antipattern well, it is an antipattern designed by go designers themselves.

[b1-88er]

Maybe he doesn't have a company because he is too dogmatic about things that don't really matter.

[PUSH_AX]

100%

People who have takes like this have likely never zoomed out enough to understand how their software delivery ultimately affects the business. And if you haven't stopped to think about that you might have a bad time when it's your business.

[pm90]

Someone has to question the status quo. If we just did the same things there would be a lot less progress. The author took the time to articulate their argument, and publish it. I appreciate their effort even if I may not agree with their argument.

[daviddever23box]

Bingo. Everything that can be wrongly used or abused started out its existence within sane constraints and use patterns.

[frankie_t]

The author gave a pretty good reasoning why is it a bad idea, in the same section. However, for the demonstration purposes I think the they should have included their vision on how the request scoped data should be passed.

As I understand they propose to pass the data explicitly, like a struct with fields for all possible request-scoped data.

I personally don't like context for value passing either, as it is easy to abuse in a way that it becomes part of the API: the callee is expecting something from the caller but there is no static check that makes sure it happens. Something like passing an argument in a dictionary instead of using parameters.

However, for "optional" data whose presence is not required for the behavior of the call, it should be fine. That sort of discipline has to be enforced on the human level, unfortunately.

[rubenv]

> As I understand they propose to pass the data explicitly, like a struct with fields for all possible request-scoped data.

So basically context.Context, except it can't propagate through third party libraries?

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

[elAhmo]

We effectively use this approach in most of our go services. Other than logging purposes, we sometimes use it to pass stuff that is not critical but highly useful to have, like some request and response bodies from HTTP calls, tenant information and similar info.