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

141–150 of 191 posts

Re: Coroutines for Go

#141

Post by [deleted] »

alphazard wrote: post #44
rcme wrote: post #35

Earlier quoted context omitted.

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

In practice the difference would be closer to: getNext := iterableThing.Iterator() for { next, ok := getNext() if !ok { break } ... } vs. for next := range iterableThing.Iterator() { ... } One advantage is that it's slightly shorter, which matters for very common patterns--people complain about `err != nil` after all. Another advantage is there isn't another variable for everyone to name differently. Another advantag…

[deleted]

Re: Coroutines for Go

#142

Post by ackfoobar »

jillesvangurp wrote: post #132
ackfoobar wrote: post #119

Earlier quoted context omitted.

> Kotlin's sequence pre-dates co-routines. You misunderstood. The `Sequence` type does predate coroutines. But I meant the `sequence` builder function, which takes a block of suspending code to create a `Sequence`. The in-order traversal in the article can be translated to Kotlin: fun walk(t: Tree?): Sequence = sequence { if (t != null) { yieldAll(walk(t.left)) yield(t.value) yieldAll(walk(t.right)) } } As I have not…

Sequences actually were part of Kotlin 1.0. Co-routines were added later.

> Sequences actually were part of Kotlin 1.0.

But the `sequence` builder function was not. In fact it depends on coroutines.

Could you read my reply before repeating?

Re: Coroutines for Go

#143

Post by [deleted] »

AYBABTME wrote: post #103
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.…

I think coroutines in Go will make it possible to use Go as a host for clean definition of discrete element simulations. Without it, yielding to an actor is clunky.

[deleted]

Re: Coroutines for Go

#144

Post by [deleted] »

talideon wrote: post #48
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…

Coroutines and goroutines fill different niches. The latter already fill the niche the likes of Twisted fill. There's nothing here trying to pull anything akin to async/await into Go. Coroutines will fill a different nice more akin to Python's generators. There are a whole bunch of places where this could dramatically cut down on memory usage and code complexity where you have a composable pipeline of components you…

[deleted]

Re: Coroutines for Go

#145

Post by deepsun »

MathMonkeyMan wrote: post #84

Multitasking systems gave us processes. But those were too much. So we got threads, which are processes that share an address space, file table, and some other things. The scheduler can switch from one to the other more easily than between processes, and data can be shared between threads without needing serialization. But those were too much. So we got user space threads, which are logical threads of execution that…

Imagining next step could be something like: "process this collection of task-items as you wish". If you squint, any concurrent execution can be viewed as sequence of tasks (which can also be collections), even if there is only one or two of them.

Re: Coroutines for Go

#146

Post by usrbinbash »

xpressvideoz wrote: post #95

Reading the comments makes me feel bittersweet. - Many people consider coroutines and green threads to be more or less the same thing, when they both have their pros and cons. - The fact that the omission of iterators is even acceptable in the Go community saddens me. They seem to deliberately refuse any feature that might make the language even slightly more complex, in the name of simplicity. But hey, at least they…

> But hey, at least they retracted their opinion on generics.

No, we really didn't.

Generics were acceptable to the community only because they are fully backwards compatible with existing code, and can be safely ignored if you don't need them.

Which, not at all surprising, is what most golang code still does. Because as it turns out, outside of "collections" of one sort or another, practical use cases for generics are not that easy to find. Most code written never gets to see more than one type to begin with, and more than 2 is already a stretch.

If anything, the addition of generics showcased to the larger community, how little many of the vaunted features!!!!! that people keep demanding and labeling as "essential" are actually needed for a widely accepted and excellent language.

Re: Coroutines for Go

#147

Post by nmz »

dingxiong wrote: post #86
VWWHFSfQ wrote: post #53

Aside: Lua is an absolute work of art. Everything about the tiny language, how it works, and even all the little peculiarities, just makes sense.

hmm. why are Lua arrays 1-index based?

Because arrays start at 1, offsets start at 0

Re: Coroutines for Go

#148

Post by defrost »

nmz wrote: post #147
dingxiong wrote: post #86

Earlier quoted context omitted.

hmm. why are Lua arrays 1-index based?

Because arrays start at 1, offsets start at 0

Arrays are just a sequence of objects.

Indexes (traditionally) start at 1, offsets (measures from base) obviously start from zero.

Re: Coroutines for Go

#149

Post by enneff »

silisili wrote: post #124
enneff wrote: post #117

Earlier quoted context omitted.

What language change are you talking about? This is just a proposed construct to regularise and make efficient something people already do (as you says with “state”). I’ve used iterators similar to what’s described in this article to avoid allocations in critical code paths, but this would make those much less awkward to use (particularly with the upcoming range iterator language change).

Perhaps language change was bad wording, I guess I meant paradigm change encouraging? Just look at this func signature and first line... > func Pull[V any](push func(yield func(V) bool)) (pull func() (V, bool), stop func()) { > copush := func(more bool, yield func(V) bool) V { The main power of Go to me was always quickly being able to read and understand code. This type of coding has a lot of cognitive load to a rea…

The implementation of Pull may be a bit mysterious to the casual reader, but its usage seems clear enough to me from the function signature. Even without reading the docs I think it’s easy to guess what yield, pull, and stop should do (and how to implement yield). That’s what matters, imo.

Fwiw if you look at the source of some other idiomatic standard library functions you may find their implementation is of similar complexity. That’s the nature of good abstractions, though, they should make tricky things easy to use.

Re: Coroutines for Go

#150

Post by jwestbury »

marcus_holmes wrote: post #100
alphazard wrote: post #44

Earlier quoted context omitted.

In practice the difference would be closer to: getNext := iterableThing.Iterator() for { next, ok := getNext() if !ok { break } ... } vs. for next := range iterableThing.Iterator() { ... } One advantage is that it's slightly shorter, which matters for very common patterns--people complain about `err != nil` after all. Another advantage is there isn't another variable for everyone to name differently. Another advantag…

Only newbies tend to complain about `err != nil` in my experience. After a certain point it just clicks and they get used to it. There's a cadence to Go code (do the thing, check the error, do the thing, check the error) that is easy to read once you're used to it, but looks horribly verbose when you're coming from an exceptions-based language. Go has simplicity as a design goal. Part of that simplicity is not adding…

I'm used to `err != nil`, but it doesn't mean I like it. It's a lot of what amounts to boilerplate in a language that is mercifully short of boilerplate elsewhere. This is doubly true when you want custom error types, and need to start unpacking values from your custom error struct.
Post reply on HN