Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coroutines for Go

research.swtch.com

Post reply on HN
Print view View original

51–60 of 191 posts

Re: Coroutines for Go

#51

Post by rakoo »

rcme wrote: post #35
alphazard wrote: post #22

It looks like a lot of people are missing the point here. Yes a coroutine library would be a worse/more cumbersome way to do concurrency than the go keyword. The use case motivating all the complexity is function iterators, where `range` can be used on functions of type `func() (T, bool)`. That has been discussed in the Go community for a long time, and the semantics would be intuitive/obvious to most Go programmers.…

What is wrong with: for { next := getNext() ... } What is the advantage of writing this as: for next := range getNext { ... }

None of the proposals submit your idea of writing things differently. The article proposes an implementation that is fully doable and usable with current spec and no breaking changes.

The point of coroutines is that they are little contexts that serve to be called

- many times

- sometimes with different parameters

- change state

- might be interrupted by callers

- might interrupt callers themselves

All of this can be done by other means. Just like any sorting can be done by copy pasting the same code, but generics make it less tedious. That's the same idea here. Some problems can be implemented as interleaving coroutines, and their definition is simple enough that you want to write it all in the body of some CreateCoroutine() function instead of taking out another struct with 5 almost empty functions. It will not solve all problems, but can more clearly separate business logic and orchestration.

Re: Coroutines for Go

#52

Post by rakoo »

Zach_the_Lizard wrote: post #8

I 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 it…

> The go keyword nicely prevents the annoying function coloring problem, which causes quite a bit of pain.

The good thing is, nothing in the post even proposes anything that might fall in the function coloring problem.

Re: Coroutines for Go

#54

Post by ketchupdebugger »

yakubin wrote: post #33
ketchupdebugger wrote: post #32

I'm not sure why author is advocating for single threaded patterns in a multithreaded environment. Not sure why he's trying to limit himself like this. The magic of goroutines is that you can use all of your cores easily not just one. Python and Lua has no choice.

Coroutines are a control-flow mechanism. They're a single-threaded pattern in as much as for loops are a single-threaded pattern. Ability to write multithreaded programs does not exclude the need for good single-threaded tools.

Looking at python's asyncio coroutine library, they are just mocking multithreading with asyncio.gather. Since coroutines can be executed in any order they are not really control-flow mechanisms. The selling point of coroutines over traditional threads is its lightweight but its moot since goroutines has similar memory cost to coroutines. The only real benefit is that coroutines are non blocking while goroutines may be blocked. There is no real benefit of having python's coroutine in go since goroutines does the same but better.

Re: Coroutines for Go

#55

Post by valenterry »

Zach_the_Lizard wrote: post #8

I 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 it…

Don't worry, it will get even worse, because its foundations are worse than pythons - and it also has less flexibility because it's not interpreted. Like it or not, it's going to happen. I also predicted that generics would be added to Go and folks here laughed about it. :)

Re: Coroutines for Go

#56

Post by dgb23 »

Cthulhu_ wrote: post #30
gkfasdfasdf wrote: post #12

Earlier quoted context omitted.

Ok so garbage collection is optional, how about garbage generation? Is there any way to manually clean up resources if GOCG=off, or will memory usage continue to grow unbounded as new objects are created?

I think in theory you can write code (or do some tricks) to avoid all heap allocation.

You mean not growing the heap or literally no allocation?

Re: Coroutines for Go

#57

Post by aaronbee »

rcme wrote: post #35
alphazard wrote: post #22

It looks like a lot of people are missing the point here. Yes a coroutine library would be a worse/more cumbersome way to do concurrency than the go keyword. The use case motivating all the complexity is function iterators, where `range` can be used on functions of type `func() (T, bool)`. That has been discussed in the Go community for a long time, and the semantics would be intuitive/obvious to most Go programmers.…

What is wrong with: for { next := getNext() ... } What is the advantage of writing this as: for next := range getNext { ... }

Your code is an example of a "pull iterator", and it's not as much of a concern.

The harder case to deal with is a "push iterator", which are often much simpler to implement, but less flexible to use. See https://github.com/golang/go/discussions/56413

The OP is about converting a push iterator into a pull iterator efficiently by using coroutines. This provides the best of both worlds, simple iterator implementation and flexible use by its caller.

Re: Coroutines for Go

#58

Post by t8sr »

vaastav wrote: post #7
djha-skin wrote: post #4

I 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

Only very theoretically - in Go, you don't control whether memory goes on your stack or the heap, and heap escape analysis is notoriously unpredictable. There is no explicit free. You would have to write Go in a completely crazy way to be able to turn off the GC and have the program not grow unbounded.

You might think "I'll just use static buffers everywhere", but allocations can occur in unexpected places. The compiler does some very basic lifetime analysis to eliminate some obvious cases (loops...), but it's really hard to avoid in general.

Re: Coroutines for Go

#59

Post by t8sr »

Cthulhu_ wrote: post #30
gkfasdfasdf wrote: post #12

Earlier quoted context omitted.

Ok so garbage collection is optional, how about garbage generation? Is there any way to manually clean up resources if GOCG=off, or will memory usage continue to grow unbounded as new objects are created?

I think in theory you can write code (or do some tricks) to avoid all heap allocation.

"In theory" being the operative words there. Turn on heap escape analysis sometime, you'll be surprised how hard it is to avoid.
Post reply on HN