Horrible overhead. If the loop does something simple, like summing integers, 99% of time will be spent switching between goroutines.
From TFA:
"Because scheduling is explicit (without any preemption) and done entirely without the operating system, a coroutine switch takes at most around ten nanoseconds, usually even less. Startup and teardown is also much cheaper than threads."
"For this taxonomy, Go's goroutines are cheap threads: a goroutine switch is closer to a few hundred nanoseconds"
"Finally, the most natural channel based implementation is⦠slow. By a factor of nearly 50x. Buffering does help though, reducing that to a factor of 25x."
And even if it's a toy program and you don't care about performance, it's not as simple as just:
for {
next := <-channel
...
}
You have to set up the channel and the goroutine that feeds it, you need to safely close the channel when the iteration is done (but not before, unless you like panics), you need to deal with panics inside the goroutine and possibly support cancellation if the iteration breaks early (unless you love memory leaks).
If you try to implement this pattern by hand, you are all too likely to make fatal mistake, and this is doubly true in the hands of an inexperienced programmer.
I appreciate the fact that Russ wrote this long post, gradually implementing `coro.New()` and improving its functionality and safety β and only in the very end, we get a short paragraph about performance. Good performance is important to make this feature attractive to use, but if the feature is clunky and error-prone, it wouldn't be worth much, even with great performance.
I'm responding to a comment asking for a justification for sugar for function call based iteration. My comment is an attempt to draw a parallel to the need for sugar for channel based iteration. I'm not trying to suggest channel based iteration as an alternative to coroutines.
From TFA:
"Because scheduling is explicit (without any preemption) and done entirely without the operating system, a coroutine switch takes at most around ten nanoseconds, usually even less. Startup and teardown is also much cheaper than threads."
"For this taxonomy, Go's goroutines are cheap threads: a goroutine switch is closer to a few hundred nanoseconds"
Also check out https://news.ycombinator.com/item?id=29510751
and https://ewencp.org/blog/golang-iterators/index.html:
"Finally, the most natural channel based implementation is⦠slow. By a factor of nearly 50x. Buffering does help though, reducing that to a factor of 25x."