61–70 of 176 posts
This is about an explicit argument of type "Context". I'm not a Go user, and at first I thought it was about something else: an implicit context variable that allows you to pass stuff deep down the call stack, without intermediate functions knowing about it. React has "Context", SwiftUI has "@Environment", Emacs LISP has dynamic scope (so I heard). C# has AsyncLocal, Node.JS AsyncLocalStorage. This is one of those id…
Scala has implicit contextual parameters: https://docs.scala-lang.org/tour/implicit-parameters.html .
Earlier quoted context omitted.
I believe this problem isn't solvable under our current paradigm of programming, which I call "working directly on plaintext, single-source-of-truth codebase". Tenant ID, cancellations, loggers, error handling are all examples of cross-cutting concerns. Depending on what any given function does, and what you (the programmer) are interested in at a given moment, any of them could be critical information or pure noise.…
Monads but more importantly MonadTransformers so you can program in a legible fashion. However, there's a lot of manual labour to stuff everything into a monad, and then extract it and pattern match when your libraries don't match your choice of control flow monad(s)! This is where I'd prefer if compilers could come in. Imagine being in the bowels of a DB lib, and realising that the function you just write might be w…
Still, I believe the core insight here is that we need different perspectives at different times. Using your example, most of the time I probably don't care whether the code is cancellable or not. Any mention of it is distracting noise to me. But other times - perhaps next day, or perhaps just five minutes later, I suddenly need to know whether the code is cancellable, and perhaps I need to explicitly opt out of it somewhere. It's highly likely that in those cases, I may not care about things like error handling logic and passing around session identifiers, and I would like that to disappear in those moments, etc.
And hell, I might need an overview of the which code is or isn't protected, and that would be best served by showing me an interactive DAG of functions that I can zoom around and expand/collapse, so that's another kind of perspective. Etc.
EDIT:
And then there's my favorite example: the unending holy war of "few fat functions" vs. "lots of tiny functions". Despite the endless streams of Tweets and articles arguing for either, there is no right choice here - there's no right trade-off you can make here up front, and can never be, because which one is more readable depends strictly on why you're reading it. E.g. lots of tiny functions reduce duplication and can introduce a language you can use to effectively think about some code at a higher level - but if there's a thorny bug in there I'm trying to fix, I want all of that shit inlined into one, big function, that I can step through sequentially, following the actual execution order.
It is my firm belief that the ability to inline and uninline code on the fly, for yourself, personally, without affecting the actual execution or the work of other developers, is one of the most important missing piece in our current tooling, and making it happen is a good first step towards abandoning The Current Paradigm that is now suffocating us all.
Second one would be, along with inlining, the ability to just give variables and parameters fixed values when reading, and have those values be displayed and propagated through the code - effectively doing a partial simulation of code execution. Being able to do it ad hoc, temporarily, would be a huge aid in quickly understanding what some code does.
Earlier quoted context omitted.
You're spawning a goroutine per Read call? This is pretty bonkers inefficient, to start, and a super weird approach in any case...
Yes, but this is just proof of concept. For any given case, you can optimize your approach to your needs. E.g. single goroutine ReadCloser: type ioContextReadCloser struct { io.ReadCloser ctx context.Context ch chan *readReq } type readReq struct { p []byte n *int err *error m sync.Mutex } func NewIoContextReadCloser(ctx context.Context, rc io.ReadCloser) *ioContextReadCloser { rcc := &ioContextReadCloser{ ReadCloser…
Earlier quoted context omitted.
Yes, but this is just proof of concept. For any given case, you can optimize your approach to your needs. E.g. single goroutine ReadCloser: type ioContextReadCloser struct { io.ReadCloser ctx context.Context ch chan *readReq } type readReq struct { p []byte n *int err *error m sync.Mutex } func NewIoContextReadCloser(ctx context.Context, rc io.ReadCloser) *ioContextReadCloser { rcc := &ioContextReadCloser{ ReadCloser…
A mutex in a hot Read (or any IO) path isn’t efficient.
This is about an explicit argument of type "Context". I'm not a Go user, and at first I thought it was about something else: an implicit context variable that allows you to pass stuff deep down the call stack, without intermediate functions knowing about it. React has "Context", SwiftUI has "@Environment", Emacs LISP has dynamic scope (so I heard). C# has AsyncLocal, Node.JS AsyncLocalStorage. This is one of those id…
> 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…
But many statically typed languages allow throwing exceptions of any type. Contexts can be similar: "try catch" becomes "with value", "throw" becomes "get".
there's no Go 2
What if for the hypothetical Go 2 we add an implicit context for each goroutine. You'd probably need to call a builtin, say `getctx()` to get it.
The context would be inherited by all go routines automatically. If you wanted to change the context then you'd use another builtin `setctx()` say.
This would have the usefulness of the current context without having to pass it down the call chain everwhere.
The cognitive load is two bultins getctx() and setctx(). It would probably be quite easy to implement too - just stuff a context.Context in the G.
> It’s very similar to thread-local storage. We know how bad of an idea thread-local storage is. Non-flexible, complicates usage, composition, testing. I kind of do wish we had goroutine local storage though :) Passing down the context of the request everywhere is ugly.