4 ms·
I always thought that context should just be a goroutine local thing always available, automatically inherited when `go` is executed (obviously with the option
by gray_-_wolf 3y ago
I always thought that context should just be a goroutine local thing always available, automatically inherited when `go` is executed (obviously with the option to set an explicit one).
- mariusor 3y agoI think Jonathan Blow's programming language, Jai, has an implicit context available to any function. However in Jai the context has a lot of implicit functionality, on the top of my head at least logging plumbing, and allocator plumbing.
- deleted 3y ago[deleted]
- swdunlop 3y agoI think of contexts as being Go's answer to dynamic variables in earlier languages, like Lisp, and less like thread local storage (like Pthreads). Much like how Go works with errors, explicit is favored over implicit -- being able to see the context pass through, and whether a function expects a context, tells you a lot about the function you are about to call. If a function does not take a context, you know it probably cannot be interrupted, just like when a function does not return an error, you know it should not fail. In my work projects, this is also a cue that the function does not do any logging since we always carry a zerolog.Logger in our contexts enriched with trace information about the request and handler. This also makes life easier for me as a reviewer -- I can see the context passing, I can spot when there is a bad pattern, like retaining a context, or failing to handle an error. It does not require me to maintain a detailed mental map of which functions employ dynamic variables or can throw exceptions.