context.Context is used in a number of situations, including for a "don't call it a request-scoped global". And whatever, web frameworks always end up with one

context.Context is used in a number of situations, including for a "don't call it a request-scoped global". And whatever, web frameworks always end up with one of those. Would love to see languages do better, but ok. My concern with its use in golang is that so much seems to get jammed into it. My experience with it is that it ends up being a holding pen for all the things that other systems do with initialization-time dependency injection / resource lookup sorts of things, but replaced with "oh just pass `ctx` as an argument everywhere". From what I've seen of Go, it looks like that happens because of the state management idiomatic constraints of the language, which in turn seem GC-related. In a garbage-collected language, I'd put a bunch of context-y things into some sort of request executor datastructure, the web framework would manage the initialization and retention of that, and request handlers would operate against those intialized data structures. That doesn't line up all that well with idiomatic Go, and so we end up needing to hide those sorts of things somewhere else. Enter context-abuse. Of course, there are plenty of use cases where those sorts of patterns aren't relevant. Right tool for the job and whatnot. Again, I'm a casual golang user at best -- I bet I'm missing some newer / better approaches, and would love to learn more about what they are.