Coroutines for Go
research.swtch.com
Coroutines for Go
1–10 of 191 posts
Re: Coroutines for Go
#2Not sure I'm a fan. Looking through the examples, I feel like this makes the language much harder to read and follow, but maybe that's just my own brain and biases.
Further, it doesn't seem to me to allow you to do anything you can't currently do with blocking channels and/or state.
Re: Coroutines for Go
#3I don’t think Coroutines would fit in with Go. There is a huge emphasis on simplicity. Coroutines add a massive amount of complexity. In addition, goroutines provide the best parts of Coroutines - cheap, easy to use, non-blocking operations - without a lot of the pain pints such as “coloring” or functions and issues with using things like mutexes.
Just the question of whether one should use a goroutine or a coroutine adds complexity.
Re: Coroutines for Go
#4I thought that the entire point of green threads was so that I didn't have to use something like Python's `yield` keyword to get nice, cooperative-style scheduling.
I thought go's `insert resumes at call points and other specific places` design decision was a very nice compromise.
This is allowing access to more and more of the metal. At what point are we just recreating Zig here? What's next? An optional garbage collector?
Re: Coroutines for Go
#5what? I'm a Go newb, but isn't this what goroutines and channels get you?
Re: Coroutines for Go
#6Not sure if this really is required. Most cases in Go are served well by GoRoutines and for yield/resume semantics, 2 blocking channel are enough. This seems to add complexity for the sake of it and not sure it actually adds any new power to Go that already didn't exist.
Re: Coroutines for Go
#7I thought that the entire point of green threads was so that I didn't have to use something like Python's `yield` keyword to get nice, cooperative-style scheduling. I thought go's `insert resumes at call points and other specific places` design decision was a very nice compromise. This is allowing access to more and more of the metal. At what point are we just recreating Zig here? What's next? An optional garbage col…
Garbage collector in Go is optional. You can switch off garbage collection by setting the environment variable GOGC=off.
More info about GOGC: https://dave.cheney.net/tag/gogc
Re: Coroutines for Go
#8I have written Go professionally for many years now and don't want to see it become something like the Python Twisted / Tornado / whatever frameworks.
The go keyword nicely prevents the annoying function coloring problem, which causes quite a bit of pain.
Sometimes in high performance contexts I'd like to be able to do something like e.g. per CPU core data sharding, but this proposal doesn't scratch those kinds of itches.
Re: Coroutines for Go
#9Not sure if this really is required. Most cases in Go are served well by GoRoutines and for yield/resume semantics, 2 blocking channel are enough. This seems to add complexity for the sake of it and not sure it actually adds any new power to Go that already didn't exist.
Goroutines + channels add an enormous amount of overhead. Using them as iterators is basically insane.
Re: Coroutines for Go
#10Not sure if this really is required. Most cases in Go are served well by GoRoutines and for yield/resume semantics, 2 blocking channel are enough. This seems to add complexity for the sake of it and not sure it actually adds any new power to Go that already didn't exist.
Goroutines + channels add an enormous amount of overhead. Using them as iterators is basically insane.
Why? Channels are already iterable using the range keyword.
ch := make(chan int)
go func() {
for i := 0; i