Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    LeonineKing1199
    @LeonineKing1199
    Execution only resumes when the iterator's .next() is called
    So when you type yield, you're actually suspending execution inside the generator
    Mark Moore
    @mmoo9154
    Execution stops (yields) at any yield... But, on the next call to the iterator, execution resumes just after the yield. Yes?
    LeonineKing1199
    @LeonineKing1199
    Yup
    You can yield almost anywhere too, it's crazy
    Mark Moore
    @mmoo9154
    Now I kinda get what's going on.
    LeonineKing1199
    @LeonineKing1199
    Generators in JS are quite the mindfuck if you've never seen anything like it before
    Yeah
    In essence, a generator is just an executable region of memory that can be suspended and called into
    Generators are simplified coroutines
    So google "coroutines" if you really wanna see how crazy this stuff can be.
    Mark Moore
    @mmoo9154
    I have. I've done a lot of multithreaded coding, but mostly in c++. I get what's going on. Really appreciate your patience.
    LeonineKing1199
    @LeonineKing1199
    Yeah, JS iterators != C++ iterators, that's for sure
    Boost has coroutines, actually
    Mark Moore
    @mmoo9154
    Maybe add that tip to the co doc on npm. ;-) "google "coroutines" if you really wanna see how crazy this stuff can be."
    LeonineKing1199
    @LeonineKing1199
    But they're crazy to implement in C++
    Ha
    TJ's not big on updating co
    co is supposed to die when async/await are released officially
    Mark Moore
    @mmoo9154
    ahhh...
    LeonineKing1199
    @LeonineKing1199
    Yeah, if you look on the github issues for co, you'll see him specifically deny requests for expanding the module
    Mark Moore
    @mmoo9154
    Well, thanks again!
    LeonineKing1199
    @LeonineKing1199
    No problem!
    I'm like the only one here. But I'm allergic to work so I can answer any questions you may have :)
    Mark Moore
    @mmoo9154
    Is there a way to save this transcript? I haven't used gitter before just now
    LeonineKing1199
    @LeonineKing1199
    Um, not that I'm aware of
    Mark Moore
    @mmoo9154
    np
    LeonineKing1199
    @LeonineKing1199
    There's a C++ gitter that I'm a part of too
    So if you ever feel like chatting about C++, there is a gitter for it
    Barney Carroll
    @barneycarroll
    Hi folks!
    I've been working with promises for ages, and
    in the last year I've been using async / await with some delight
    Something I didn't get early on in my playing with async / await was a fair bit of criticism that deemed the proposal redundant since we already had generators
    This was because I'd never really grokked generators, they were too broad in their use cases and I'd never come up with a scenario where I'd used them to significant effect
    Barney Carroll
    @barneycarroll
    However recently I've discovered the power of splitting low level logic into subroutines and I've realised just how useful generators can be
    co was always cited as the empowering toolkit that made generators shine, so I thought I'd come back and read a bit in the hope of getting some more ideas of the possibility space of generators
    Barney Carroll
    @barneycarroll
    And I'm surprised to see that the README says generators and generator functions are now only consumable as yieldables as a backward compatibility measure, with the recommendation being that people use promises instead
    This strikes me as odd, since it suggests that in the modern spec world, co is essentially relegating itself to async / await with special unwrapping behaviour
    Does anyone have any insight as to the rationale behind "avoid yielding generators"?
    LeonineKing1199
    @LeonineKing1199
    I'm not sure I understand the logic as well :P
    Delegating generators just increases the amount of iterations the generator supports
    Maybe it's a pain in the ass to maintain the code? Though I couldn't see how that's true
    It's simple to yield co(...); though so I'm not complaining
    I think it's because in the future, await will only work with promises
    co was built with planned obsolescence in mind. Generator delegation probably is a hurdle to that because it won't work natively with await
    Barney Carroll
    @barneycarroll
    TBH I've had mysterious problems trying to get recursive generators to work anyway, I can't blame co for wanting to keep the API predictable and limit generators to anonymous constructs wrapped in a co call
    LeonineKing1199
    @LeonineKing1199
    I'm glad someone brought some life into this gitter :P
    Barney Carroll
    @barneycarroll
    Haha
    Transient life!
    LeonineKing1199
    @LeonineKing1199
    I think TJ's main goal was to have co be used and then when ES7 hits, people can just replace yield with await and it'll all just work