3 ms·

I don't think A would work because the Go team has been opposed to goroutine id's, the main detractor being it would be used to create thread local storage. I

I don't think A would work because the Go team has been opposed to goroutine id's, the main detractor being it would be used to create thread local storage. I like B, but a major use case for Go is http servers, and I can see that being awkward when most frameworks don't expose the creation of the gorountine.

bbatha 9y ago
> I don't think A would work because the Go team has been opposed to goroutine id's, the main detractor being it would be used to create thread local storage. I find this a weird stance. Idiomatic Go already has pervasive mutable globals, and life before main. Aside from cancelation the other thing that `context.Context` poorly abstracts is goroutine local storage. Having go routine ids and the new sync.Map seem like a backwards compatible way to add these features to go now.