3 ms·

To follow up on my own snark: > Do people use coroutines? Yes, but not in production code. Now I'm wondering if I'm the one who's confused. Either the author

• mdomans 10y ago
  I know of goroutines and comparing Python's coroutines to goroutines is like saying that Porsche and Tata car's are same, since both have 4 wheels.
  • omni 10y ago
    Fair enough, I thought you were speaking more generally since the next sentence was: > I may be opinionated, but I've done concurrency in many languages and never ever have I seen anything less readable than coroutines.
• 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.
• jacquesm 10y ago
  Goroutines are coroutines within the context of a single thread only, but there may be more of those and a goroutine is as far as I know not always executed by the same thread on the next tick. It's just a way to conserve resources, if goroutines would be threads they'd use a lot more stack space and other precious bits.