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

151–160 of 191 posts

Re: Coroutines for Go

#151

Post by nasretdinov »

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…

Even coroutines can't save us programmers from the dread of having to explain every little possible detail to the computer, in a way that doesn't take forever to execute if you provide input that is even slighly different from what the programmer had in mind

Re: Coroutines for Go

#152

Post by FZambia »

Wondering whether coroutines may be a step towards async event-based style APIs without allocating read buffers for the entire connection. I.e. a solution to problems discussed in https://github.com/golang/go/issues/15735. Goroutines provide a great way to have non-blocking IO with synchronous code – but when it comes to effective memory management with many connections Go community tend to invent raw epoll implementations: https://www.freecodecamp.org/news/million-websockets-and-go-.... So my question here – can coroutines somehow bring new possibilities in terms of working with network connections?

Re: Coroutines for Go

#153

Post by masklinn »

ackfoobar wrote: post #137
masklinn wrote: post #128

Earlier quoted context omitted.

In fact python had general coroutines first in yield, which is mostly used for iteration (“generators”) and state machines. Some frameworks (e.g. twisted) did use them for concurrency, and the core team originally planned something similar, however the ergonomics were not what they wanted (especially when mixing coroutines-for-concurrency and coroutines-for-iteration), so they went for a more specialised design.

> did use them for concurrency > went for a more specialised design My impression is that JS evolved similarly - (ab)using generator for concurrency, then specialized async-await as a language feature.

Kinda? But that was a very short cycle, both promises and generators were added to the language in ES6 (though the community had been coalescing around promises — “thenables” — for a while), the first draft for async functions was actually created during the development cycle of ES6, and it was shipped in ES7.

Re: Coroutines for Go

#154

Post by Patrickmi »

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…

Generics didn’t even change up 20% of my codebase and from that 20% there where libraries, am not sure if Go or C habits has hatched into me, but I see generics as another library that one programmer from somewhere just solved something

Re: Coroutines for Go

#155

Post by jonathanstrange »

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…

I'm a bit surprised about the lack of languages that parallelizes code automatically as much as possible, but only as far as measured performance suggests. It requires a semantics that supports concurrency, for example iteration over sequences needs to be in unspecified order by default, and also rests on whole program flow analysis, but I see no principle obstacles.

Hasn't Microsoft done some research on such a language years ago already? There is also ParaSail made by someone from the Ada community. What happened to these projects? Nobody uses them?

Re: Coroutines for Go

#156

Post by throwaway2037 »

mcronce wrote: post #46
morelisp wrote: post #42

Earlier quoted context omitted.

Ad absurdum, then anything other than full curried 1-ary-exclusive functions is coloring. You can easily bridge context-using and non-context-using code, you can have nested contexts, you can have multiple unrelated contexts, you can ignore the context, probably most critically you can't pass values back up the context , I don't see any way these look like function coloring.

Not sure about in Python, but in Rust, you can easily bridge sync and async code. The function coloring problem is, at least in that case, grossly overstated.

Why was this downvoted? The person makes an interesting point.

For discussion, can you please provide a short sample in Rust to demonstrate your point? I would like to hear more.

Re: Coroutines for Go

#157

Post by fooyc »

ben0x539 wrote: post #121
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 { ... }

Well, what was wrong with: for { next :=

The article mentions race conditions

Re: Coroutines for Go

#158

Post by gpderetta »

jonathanstrange wrote: post #155
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…

I'm a bit surprised about the lack of languages that parallelizes code automatically as much as possible, but only as far as measured performance suggests. It requires a semantics that supports concurrency, for example iteration over sequences needs to be in unspecified order by default, and also rests on whole program flow analysis, but I see no principle obstacles. Hasn't Microsoft done some research on such a lang…

Turns out that autopar is an extremely hard problem beyond simple use cases. And for simple use cases existing solutions work fine (pragma omp for goes a long way for example).

Re: Coroutines for Go

#159

Post by gpderetta »

uhura wrote: post #135
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…

I would prefer to add a `yield` param to functions so it can better interact with the current type system. This means that for a function to yield, it needs to have the so called `yield` param and you can only yield inside a yield function functions with the same yield signature or does not contain a signature at all. So the example would be rewritten into something like: x := func(:z int) { for { z++ :- z } } for y…

Sure, as long as I can close over a yield object. There is no reason for filter and map to know that the last function parameter takes a continuation.

Re: Coroutines for Go

#160

Post by throw-ru-938 »

JyB wrote: post #75
talideon wrote: post #48

Earlier quoted context omitted.

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.

Isn't this literally the entire point of Golang?
Post reply on HN