Context is in no way shape or form a crutch. It is a required element of any multi-user or distributed system. You may call it something else, but in the end it is a “context”.
> On Jan 16, 2019, at 7:29 PM, Space A. <reexist...@gmail.com> wrote: > > Problems are fine. And developer should be able to take care of them. That's > what he does. Context is basically a crutch. So are you proposing to make a > crutch a language construct? > > > четверг, 17 января 2019 г., 0:43:58 UTC+3 пользователь robert engels написал: > I agree with all of those assessments. That’s why I think the “context” needs > to be moved into a language construct. Then the developer is insulated from > most (all) of these problems - that is the “current context” propagates > unless specifically told not to when creating the Go routine. In almost all > cases the context is a single reference so it should be cheap to propagate. > > If the “context” was a higher level standardized concept, then the “values” > could be typed, so all of the benefits of the Java way - transactions, > logging, “current user”, etc. can all be addressed in a type-safe manner. > > I’ve stated a few times that a Go routines lack of context (name, purpose, > etc) is a huge problem. It really limits the ability to write very high > performance applications (pinning routines to cores, groups of routines to > CPU’s, marking some routines as “delay GC”, etc.). > > > On Jan 16, 2019, at 3:33 PM, Ian Lance Taylor <ia...@ <>golang.org > > <http://golang.org/>> wrote: > > > >> On Wed, Jan 16, 2019 at 7:15 AM Robert Engels <ren...@ <>ix.netcom.com > >> <http://ix.netcom.com/>> wrote: > >> > >> > >> I don’t see the complexity nor the real difference between Go routines and > >> Threads. In Java TLS is not passed to new threads you need to be explicit. > >> The ThreadLocal doesn’t allow access to other threads locals even with > >> thread groups, etc. As far as I understand Go has no concept of parent Go > >> routine - at least not exposed - so I don’t see the issue. > > > > The difference is that in Java creating a new thread is a relatively > > heavyweight operation. It's not hard, but it's not routine. It's > > reasonable that when creating a new thread you consider how to handle > > any thread local variables. In particular everybody understands that > > the new thread will not have access to any of the thread local > > variables of the parent thread. > > > > In Go new goroutines are started frequently and casually. For > > example, it's routine for people to change a loop computing a list of > > values into a loop that starts a goroutine for each computation. If > > we are using a thread-local context.Context to cancel a goroutine, > > then one would naturally expect all those goroutines to inherit that > > Context value, so that they too will be stopped. If they don't > > inherit it, then we need some extra mechanism to set the thread-local > > Context, and we need to remember to do that. If they do inherit it, > > then we need to think about the cases where they shouldn't inherit it. > > Either way, the operation is sometimes implicit and sometimes > > explicit. That is confusing. > > > > In Java it's not confusing to always make thread-local handling > > explicit. In Go that would be frustrating and awkward. > > > > Ian > > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
