3 ms·
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
by djha-skin 3y ago
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 feature to goroutines to have control in specific situations" feels like something that would be better than "we're going full Rust on this problem and just adding it."
- morelisp 3y agoThis has been under discussion for a long time. https://github.com/golang/go/issues/43557 https://github.com/golang/go/issues/43557 https://github.com/golang/go/discussions/56413 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?
- chrsig 3y ago> 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.
- earthboundkid 3y agoIn the old discussion, I specifically complained about how it would add back door coroutines to Go via iterators, and now Russ has a post about formalizing the concept of a coroutine, while also keeping the optimization of coroutines as a runtime implementation detail. I feel vindicated. :-) https://github.com/golang/go/discussions/56413#discussioncomment-4052481 https://github.com/golang/go/discussions/56413#discussioncom...