Passing the current user ID/tenant ID inside ctx has been super useful for us. We’re already using contexts for cancellation and graceful termination, so our application-layer functions already have them. Makes sense to just reuse them to store user and tenant IDs too (which we pull from access tokens in the transport layer).

We have DB sharding, so the DB layer needs to figure out which shard to choose. It does that by grabbing the user/tenant ID from the context and picking the right shard. Without contexts, this would be way harder—unless we wanted to break architecture rules, like exposing domain logic to DB details, and it would generally just clutter the code (passing tenant ID and shard IDs everywhere). Instead, we just use the "current request context" from the standard lib that can be passed around freely between modules, with various bits extracted from it as needed.

What’s the alternatives, though? Syntax sugar for retrieving variables from some sort of goroutine-local storage? Not good, we want things to be explicit. Force everyone to roll their own context-like interfaces, since a standard lib's implementation can't generalize well for all sitiations? That’s exactly why contexts we introduced—because nobody wanted to deal with mismatched custom implementations from different libs. Split it into separate "data context" and "cancellation context"? Okay, now we’re passing around two variables instead of one in every function call. DI to the rescue? You can hide userID/tenantID with clever dependency injection, and that's what we did before we introduced contexts to our codebase, but that resulted in allocations of individual dependency trees for each request (i.e. we embedded userID/tenantID inside request-specific service instances, to hide the current userID/tenantID, and other request details, from the domain layer to simplify domain logic), and it stressed the GC.

We added exactly this feature to Arc* and it has proven quite useful. Long writeup in this thread:

https://news.ycombinator.com/item?id=11240681 (March 2016)

* the Lisp that HN is written in

> an implicit context variable that allows you to pass stuff deep down the call stack, without intermediate functions knowing about it. [...] but is actually very useful and can result in cleaner code with less globals or less superfluous function arguments. [...] and it applies to everything down the call stack (but not in other threads/async contexts).

In my experience, these "thread-local" implicit contexts are a pain, for several reasons. First of all, they make refactoring harder: things like moving part of the computation to a thread pool, making part of the computation lazy, calling something which ends up modifying the implicit context behind your back without you knowing, etc. All of that means you have to manually save and restore the implicit context (inheritance doesn't help when the thread doing the work is not under your control). And for that, you have to know which implicit contexts exist (and how to save and restore them), which leads to my second point: they make the code harder to understand and debug. You have to know and understand each and every implicit context which might affect code you're calling (or code called by code you're calling, and so on). As proponents of another programming language would say, explicit is better than implicit.

I haven't seen it mentioned yet, but Odin also has an implicit `context` variable:

https://odin-lang.org/docs/overview/#implicit-context-system

> React has "Context", SwiftUI has "@Environment", Emacs LISP has dynamic scope (so I heard). C# has AsyncLocal, Node.JS AsyncLocalStorage.

Emacs Lisp retains dynamic scope, but it's no longer a default for some time now, in line in other Lisps that remain in use. Dynamic scope is one of the greatest features in Lisp language family, and it's sad to see it's missing almost everywhere else - where, as you noted, it's being reinvented, but poorly, because it's not a first-class language feature.

On that note, the most common case of dynamic scope that almost everyone is familiar with, are environment variables. That's what they're for. Since most devs these days are not familiar with the idea of dynamic scope, this leads to a lot of peculiar practices and footguns the industry has around environment variables, that all stem from misunderstanding what they are for.

> This is one of those ideas that at first seem really wrong (isn't it just a global variable in disguise?)

It's not. It's about scoping a value to the call stack. Correctly used, rebinding a value to a dynamic variable should only be visible to the block doing the rebinding, and everything below it on the call stack at runtime.

> Implicit context (properly integrated into the type system) is something I would consider in any new language.

That's the problem I believe is currently unsolved, and possibly unsolvable in the overall programming paradigm we work under. One of the main practical benefits of dynamic scope is that place X can set up some value for place Z down on the call stack, while keeping everything in between X and Z oblivious of this fact. Now, this is trivial in dynamically typed language, but it goes against the principles behind statically-typed languages, which all hate implicit things.

(FWIW, I love types, but I also hate having to be explicit about irrelevant things. Since whether something is relevant or not isn't just a property of code, but also a property of a specific programmer at specific time and place, we're in a bit of a pickle. A shorter name for "stuff that's relevant or not depending on what you're doing at the moment" is cross-cutting concerns, and we still suck at managing them.)

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

> Implicit context (properly integrated into the type system) is something I would consider in any new language.

Those who forget monads are doomed to reinvent dozens of limited single-purpose variants of them as language features.

Thread local storage means all async tasks (goroutines) must run in the same thread. This isn't how tasks are actually scheduled. A request can fan out, or contention can move parts of the computation between threads, which is why context exists.

Furthermore in Go threads are spun up at process start, not at request time, so thread-local has a leak risk or cleanup cost. Contexts are all releasable after their processing ends.

I've grown to be a huge fan of Go for servers and context is one reason. That said, I agree with a lot of the critique and would love to see an in-language solution, but thread-local ain't it.

And Java added ScopedValue in version 20 as a preview feature.

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

We already have implicit context. It's called thread local storage and dynamic scoping, and we figured out it's a bad idea a long time ago.

Explicitly passing data and lexical scoping is better for understandability.

A good pitch for dynamic (context) variables is that they're not globals, they're like implicit arguments passed to all functions within the scope.

Personally I've used the (ugly) Python contextvars for:

- SQS message ID in to allow extending message visibility in any place in the code

- scoped logging context in logstruct (structlog killer in development :D)

I no longer remember what I used Clojure dynvars for, probably something dumb.

That being said, I don't believe that "active" objects like DB connection/session/transaction are good candidates for a context var value. Programmers need to learn to push side effects up the stack instead. Flask-SQLAlchemy is not correct here.

Even Flask's request object being context-scoped is a bad thing since it is usually not a problem to do all the dispatching in the view.

Yeah, I agree 100% with you. The thing with Golang is that it's supposed to be a very explicit language, so passing the context as an argument fits in with the rest of the language.

Nevertheless: just having it, be it implicit or explicit, beats having to implement it yourself.