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

101–110 of 191 posts

Re: Coroutines for Go

#101

Post by 12345hn6789 »

38 wrote: post #85
chrsig wrote: post #69

Coroutines are one thing that i'd probably prefer language support for rather than a library. x := co func(){ var z int for { z++ yield z } } y := x() for y := range x { ... } or something to that effect. It's cool that it can be done at all in pure go, and I can see the appeal of having a standard library package for it with an optimized runtime instead of complecting the language specification. After all, if it's p…

wow that is horrible. none of that is intuitive, which is one of Go strength. you would need to specific learn the Go semantic of coroutine to have any chance of writing or even reading code like this.

I've written go for a year or so. That looks close to go code I look at every day. I wouldn't be surprised if it was in the language.

Re: Coroutines for Go

#102

Post by 38 »

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…

I use Go daily. honestly generics didn't change my code much at all.

I use them now somewhat, but only because they offer slightly better sugar at the call site. at the definition site, they are just as ugly as you expect, granted the Go syntax is about the best I have seen from other languages. so in the end I think we really lost some simplicity in order to silence the whining about no generics. not a good tradeoff.

Re: Coroutines for Go

#103

Post by AYBABTME »

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.

Re: Coroutines for Go

#104

Post by cakoose »

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.

One core Lua thing that I think is an ugly mistake: trying to represent maps (dictionaries) and arrays using a single logical data type.

Most languages use different data types but with some API overlap, e.g. maps and arrays are both "iterable". Lua goes too far, I think, and tries to make them the exact same, a data type they call "table".

One side-effect is that you have some operations that only really make sense for maps or lists, but since they work on all tables, they're defined awkwardly, e.g:

> The length of a table t is defined to be any integer index n such that t[n] is not nil and t[n+1] is nil; moreover, if t[1] is nil, n can be zero. For a regular array, with non-nil values from 1 to a given n, its length is exactly that n, the index of its last value. If the array has "holes" (that is, nil values between other non-nil values), then #t can be any of the indices that directly precedes a nil value (that is, it may consider any such nil value as the end of the array).

Re: Coroutines for Go

#105

Post by hgsgm »

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…

>This seems like a "can implement, but not very cleanly" case, which would be a great justification for a library, but not a language feature.

First sentence of OP:

> This post is about why we need a coroutine package for Go

Then in the girst section after the intro:

> Later, I will argue for an optimized implementation provided directly by the runtime, but that implementation should be indistinguishable from the pure Go definition.

Re: Coroutines for Go

#106

Post by xwowsersx »

dingxiong wrote: post #87
xwowsersx wrote: post #66

Somewhat on topic given that OP brought up coroutines in Python: what resources have folks used to understand Python's asyncio story in depth? I'm just now finally understanding how to use stuff, but it was through a combination of the official documentation, the books "Using Asyncio in Python" and "Expert Python Programming", none of which were particularly good. Normally I'd rely just on the official docs, but the…

This blog helps me a lot about the motivation and underlying mechanism of python asyncio https://tenthousandmeters.com/blog/python-behind-the-scenes-...

Thanks a lot, I'll check that out.

Re: Coroutines for Go

#107

Post by hgsgm »

silisili wrote: post #2

Not 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.

A dozen different incompatible iterator implementations (the current stdlib) isn't easier.

Channels are slow for no good reason when they aren't wrapping blocking operations.

Re: Coroutines for Go

#108

Post by hgsgm »

JyB wrote: post #78
silisili wrote: post #2

Not 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.

You’re absolutely right. People advocating for it can’t seem to see beyond their nose.

Yes, the person who spent 15 years developing the Go language can't see beyond his nose.

Re: Coroutines for Go

#109

Post by hgsgm »

vaastav wrote: post #6

Not 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.

This is covered in the article.

Re: Coroutines for Go

#110

Post by hgsgm »

MichaelMoser123 wrote: post #92
chrsig wrote: post #69

Coroutines are one thing that i'd probably prefer language support for rather than a library. x := co func(){ var z int for { z++ yield z } } y := x() for y := range x { ... } or something to that effect. It's cool that it can be done at all in pure go, and I can see the appeal of having a standard library package for it with an optimized runtime instead of complecting the language specification. After all, if it's p…

you need language support for coroutines - what happens when the stack runs out in one of the coroutine? With a library solution you would have to kill the co-routine, or kill the program. If you want the stack to grow transparently, then that can only be done by the generated code, it has to watch stack usage and then grow the stack on demand (i think you have something like that with goroutines) Well, maybe a libra…

You don't need language support for coroutines if you have language support for relocatable/chunkable stack, which Go has.
Post reply on HN