Earlier quoted context omitted.
[flagged]
As it stands, this comment contains no information. Can you explain what about Lua is problematic?
[flagged]
Coroutines for Go
71–80 of 191 posts
Re: Coroutines for Go
#72Earlier 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…
> complain about `err != nil` after all
Not to nitpick this specifically but as a generic reminder not all complaints are worthy of shifting the trajectory of a massively popular programming language.
Balancing "worthy" and "unworthy" changes is really hard both in the community and discussions like this one. I don't envy the teams that have to do it.
Re: Coroutines for Go
#73Earlier 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…
The err!=nil is exactly what you don’t want to mention and the perfect example why you shouldn’t listen to all the close-minded takes some people might have.
Re: Coroutines for Go
#74Earlier quoted context omitted.
Still a kitchen sink move, though, isn't it? Like, no careful thinking and good 80/20 solution this time. Just "huh, we'd need coroutines to do this `right` so let's just do that" When they added generics, they really , really thought long and hard, and came up with a compromise that was brilliant and innovative in the balance it struck. I would have hoped to see something like that here, like "we're adding this one…
This has been under discussion for a long time. https://github.com/golang/go/issues/43557 https://github.com/golang/go/discussions/56413 I'm not sure Russ's personal blog is any kind of official statement "this is what we're doing" yet?
> I'm not sure Russ's personal blog is any kind of official statement "this is what we're doing" yet?
I've found it's generally a very strong indicator.
But to your point, this isn't a new issue, there's been a good amount of discussion around it over the years.
Re: Coroutines for Go
#75I 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…
For sure cut down code complexity for the single clever code writer who wanted to be fancy. Not so sure about all the readers that will come afterwards.
Re: Coroutines for Go
#76Earlier quoted context omitted.
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…
The concept of "coroutines" is as much about control flow as "subroutines" (function calls and return statements).
But when you have a construct that has their own call stacks, it's a relatively small step to implement lightweight threads with it.
Since doing concurrency happens much more often than any other smart use of coroutines, many people conflate the two.
I sometimes see this confusion in discussions about Kotlin's coroutines. An example of using coroutines that is not about concurrency: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.sequence...
Re: Coroutines for Go
#77Earlier quoted context omitted.
Why? Channels are already iterable using the range keyword. ch := make(chan int) go func() { for i := 0; i That is very simple.
"Enormous amount of overhead" is the operative phrase. In general, you want your concurrency operations to be significantly smaller than the payload of the operation. In the case of using channels as iterators with goroutines behind them, it works fine for something like a web page scraper, where the act of fetching a web page is enormously larger than a goroutine switch, but as a generalized iteration mechanism it's…
But if your iteration is so fast then you don’t need a channel at all. Just use a plain for loop.
Re: Coroutines for Go
#78Not 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.
Re: Coroutines for Go
#79Earlier quoted context omitted.
It’s not insane at all. How did you come to that conclusion? * Mutex lock+unlock: 10ns * Chan send buffered: 21ns * Try send (select with default): 3.5ns Missing from here is context switches. In either case, the overhead is proportional to how fast each iteration is. I have channels of byte slices of 64k and the channel ops don’t even make a dent compared to other ops, like IO. You should absolutely use channels if…
> Missing from here is context switches. Exactly. From rsc 's previous post[1]: > On my laptop, a C thread switch takes a few microseconds. A channel operation and goroutine switch is an order of magnitude cheaper: a couple hundred nanoseconds. An optimized coroutine system can reduce the cost to tens of nanoseconds or less. [1]: https://research.swtch.com/pcdata >
Yeah I 100% understand wanting to optimize this for something like generators if we imagine them as first-class constructs. But they’re not at all a replacement for channels – they would be an addition, or specialization. I’ve never seen real world Go code that has needed it but maybe this will change with generics. It’s worth keeping an eye on, at least.
Channels otoh are very versatile: everything from spsc to mpmc with buffering and starvation protections, fast cancelation and notifications, etc etc. They’re not perfect, but it’s a helluva bang-for-the-buck for a single primitive. Literally all you have to do for performance is add buffering and coalesce “units of work”, and you’re good to go.
Re: Coroutines for Go
#80The examples given prompt me to say: if all you have is Rube-Goldberg hammer, everything looks like an Escheresque nail.
Sieving primes by turning functions into coroutines, parsing text by yielding characters, all with unnatural functions and state management... that;s an improvement over what?