2 ms·
I'm guessing it's the latter, and perhaps not without cause. Traditionally, coroutines require the programmer to explicitly yield. With Go, you don't have to th
by weberc2 10y ago
I'm guessing it's the latter, and perhaps not without cause. Traditionally, coroutines require the programmer to explicitly yield. With Go, you don't have to think about that much; you can pretty much treat them as lightweight threads and trust the scheduler to do the right thing. Goroutines aren't pre-empted, but the yield points aren't explicit (though they are well defined and thus easy to reason about).
- jerf 10y ago"Traditionally, coroutines require the programmer to explicitly yield." When terms move from academia into common usage, they inevitably blur. Academia had a specific definition of coroutine that includes that. Programmers now use "coroutines" in a way that I have a hard time distinguishing from "threads", Pythonic "generators", and in the worst cases "something vaguely concurrent". Any given author may have a clear idea of what they mean (and in particular, I'm not making any specific accusations about the author of this piece) but the term is rapidly approaching uselessness in the general programming community.