4 ms·
I agree with the author wholeheartedly. I see the solution that contexts solve, but it seems like a hacky bolt on that made an otherwise beautiful language cum
by axaxs 9y ago
I agree with the author wholeheartedly. I see the solution that contexts solve, but it seems like a hacky bolt on that made an otherwise beautiful language cumbersome.
A solution? Well, I'd had a few passing thoughts but never really vetted them much or thought of implementation, just throwing things at the wall. I'll share anyways.
A) A supervisor type system. the 'go' command would return some id, eg
x := go runthis()
where x is the id. This could then be used to identify, kill, etc things at a supervisor level.
B) Maybe more esoteric, but treating go routines as implicit channels. There's a few ways this could go, but it would be similar to the above, except the return would be an channel. This could allow passing signals to the goroutine, and also, retrieving values from the goroutine. Eg
x := go run()
y := <-x // y is the return value of x
or
x := go run()
x <- 1 // terminates the x goroutine
- nemothekid 9y agoI 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.
- placeybordeaux 9y agoI really like B, I'd prefer to see killing the goroutine by closing the channel and then adding a ChildChannel.dependsOn(ParentChannel) for explicitly deciding when you want to end a whole tree of computation.
- derefr 9y agoLike Erlang's links, sort of.