5 ms·

I'd like to point out that I never heard of coroutines before Go. Not even in computer science; and I did take an Operating Systems course. I also never seen a

• eru 14y ago
  > Not even in computer science; What did you specialize in? It's pretty easy to hit upon co-routines, if you have an interest in Scheme or even Haskell. But I can imagine, it's much harder if you are into, say, the innards of database schemas. (Just a random example.)
  • hasenj 14y ago
    I don't know why I didn't come across it. Maybe if I took Operating System II ..
    • javert 14y ago
      I think you would have had to go deeper into programming languages, not deeper into operating systems. Disclaimer: The above is definitely true for coroutines in general, but I don't know much about Go and whether its coroutines are truly unique.
      • MaxGabriel 14y ago
        I also heard of it in a programming languages course, and also in Udacity CS 212 I think. To add to the list, they're implemented in Python using yield statements
        • nas 14y ago
          Python's yield was originally a limited co-routine, something we coined as a "generator" (borrowing the word from Icon, which Tim was quite fond of). It was limited to one frame on the stack and could only return values. Recent enhancements have allowed values to be passed back into the suspended function. That's still not a full co-routine though since Python only lets you go one level down on the stack. As someone else mentioned, you need to get deeper into programming languages, not operating systems. Scheme has call/cc which can be used to build co-routines. Someone needs to clue in the nodejs crazies as well, callbacks are not the way to design a language. ;-)
          • mattgreenrocks 14y ago
            All of the node.js kids get really defensive when you point this out; as if async was supposed to be heinously ugly despite the fact that the entire raison d'etre of node.js is to be async. Programming advances so slowly because all of the training required to become familiar with it eventually becomes a blind spot.
          • swdunlop 14y ago
            It is hard to get excited about concurrency in vanilla Python while the Global Interpreter Lock still chokes everything down internally. (Vanilla, here, should be read "not Stackless.") For more effective use of lightweight processes, I'd probably reach for Erlang or Occam.
            • masklinn 14y ago
              Not sure why, the GIL is not an issue to node-style concurrency (based on an event loop and async IO), though you need alternative IO layers (Gevent provides exactly that, and can — if requested — monkeypatch the stdlib to replace standard synchronous IO calls by Gevent-provided async IO). In fact, mixing threads and an event loop with async IO is probably a good way to make everything blow up.
    • chubot 14y ago
      It's not surprising you didn't come across it -- I never did in school either. From what I can tell, it's because coroutines were an old idea that were eclipsed by OS threads and the like. They basically became interesting again when OS threads reached scalability limits. This paper by the authors of Lua has some good historical background: http://lambda-the-ultimate.org/node/2868 http://lambda-the-ultimate.org/node/2868 They also poke fun at Python in some ways because the coroutines are fairly limited. Python got them sort of ad hoc with yield in Python 2.4 and send() in Python 2.5. I think Python is by far the most popular language with any kind of coroutine. Coroutines aren't very popular or well understood.
• ww520 14y ago
  coroutine is an old concept before threading became popular. It was usually implemented as a green-thread library. For C, setjmp/longjmp was used to implement it. Some libraries messed around with the stack register to implement it. GO puts it as a first class citizen in the language. Other languages might call it Actor, light weight thread, fiber, task, etc. It's popular in embedded systems to implement cooperative threading using coroutine due to its simplicity and low overhead in resource utilization.
  • j2labs 14y ago
    A coroutine is not the same as an Actor, though actors can be implemented with coroutines.
• malkia 14y ago
  If you want to learn coroutines with a relatively small and easily embeddable language, you can try with lua - http://lua-users.org/wiki/CoroutinesTutorial http://lua-users.org/wiki/CoroutinesTutorial
• masklinn 14y ago
  > I also never seen any language doing interfaces like Go. OCaml has used structural subtyping since the beginning for its object layer. C++'s templates also use structural subtyping on type arguments. Pierce also covers the subject in TAPL. > I find that this is pretty impressive as a feature on its own. There are advantages and inconvenients to structural subtyping (compared to nominative): it's more flexible and has much lower overhead, but it's subject to false positives (structurally equivalent but semantically unrelated objects) and tends to have much worse error reporting. Not to mention structurally typed systems still usually have and need nominative types in their core, for "non-object" types.
  • hasenj 14y ago
    I don't know what structural subtyping is, but I no that Go's interfaces are nothing like anything in C++
    • dan00 14y ago
      class A { public: int do() { return 1; } }; class B { public: int do() { return 2; } }; template <typename T> int do(T t) { return t.do(); }
      • Olreich 14y ago
        How does one use that template? Can you show me a function that takes anything with a do() method? Like this?: do<A>(a) do<B>(b) Can I take any arbitrary type with an "int do()" method and use that with do? Like: do(Arbitrary)
        • dan00 14y ago
          "How does one use that template? Can you show me a function that takes anything with a do() method? Like this?:" It should work without the template parameter: do(a), do(b) "Can I take any arbitrary type with an "int do()" method and use that with do?" Yes.