I assume here that the proposal is not to change io.Reader but to create a new interface, maybe context.Reader. There are lot of uses of io.Reader where the Read operations will not block and therefore no context is necessary. A context.Reader would also require a wrapper function that converts a context.Reader to an io.Reader.
On Monday, August 7, 2017 at 6:06:23 PM UTC+2, Daniel Theophanes wrote: > Hello Micha, > > I'm not seeing any experiences (project building/maintaining) you are > reporting on. > > In the projects I've worked on the switch to Context has been a huge win > all across the board. I think it would be sweet to find an effect way to > make io.Reader take a context (I often want just that, and when I really > need it the solution tends to be more inefficient then it could be). > > Note, Context isn't just useful for servers. It is useful for any > application. Desktop applications with GUIs, services/daemons, web > services. In other words, if your application does an operation that could > block (file IO, network IO, running executable) and you either have a > halting program or a program you want to be responsive, Context is > exceptionally useful. > > As for Context.Values, I think you are dismissive of the real use-cases > without giving proper weight to them. It can be abused. Just like > go-routines and channels. I'm not saying we can't do better then the > current implementation, we probably can if the benefit is seen as worth the > cost of the change. > > You're saying context is viral. It is. Just like errors are viral. Once > you start returning them you need to propagate them back. Having a context > argument is saying "this function, or something this function calls may > block for undisclosed amounts of time and we need to know when to stop > blocking and back out." There might be a better way to do ctx (and maybe > errors) if the language was adjusted; I'm fairly sure go-routine local > storage isn't the answer but maybe something else would be. Maybe you could > create an Arena with a context and a pattern for returning execution on > error and an Arena could use multiple go-routines and such. However I think > where you would need to start is a named real experience building and > maintaining a solution in Go that gets real use. Then look at it and see > where it was painful and how it was so. > > Lastly as an aside, github emoji reactions are fine for what they are. But > they are not an engineering argument one way or another. Last time I > checked no one is running a popularity contest. > > Thanks, -Daniel > > > On Monday, August 7, 2017 at 6:40:05 AM UTC-7, Michal Strba wrote: >> >> Hi everyone! >> >> I've written a blog post called 'Context should go away for Go 2': >> >> https://faiface.github.io/post/context-should-go-away-go2/ >> >> The post is about the cancelation problem in Go, how context package >> solves it, why context package is bad anyway, and that Go 2 should do >> something about it. Hope you enjoy reading ;) >> >> PS: I'm not sure if this post is acceptable for an experience report. If >> you think it is / isn't, let me know. >> >> Michal Štrba >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
