4 ms·

> It's not hard to imagine a world where async/await was the more common early implementation and generators used async/await an implementation detail. It actu

• WorldMaker 2y ago
  > Promises have implications for event loop scheduling that preclude async (which implicitly returns a Promise) from providing synchronous semantics. Those also generally are implementation details of the chosen Promise/Futures/Tasks transformer model. The monad itself says nothing about how things are plumbed, event loops are just one common/useful way to plumb it. C# Tasks run synchronously by default, on the same thread, and there is no required event loop (but you may need to interoperate with the SynchronizationContext for one). (.NET for better and worse uses a heavier threading abstraction than microstasks/green-threads.) It's often a common misconception for .NET developers that Tasks are always async and run in other threads. You can write code with synchronous semantics in C# async/await. It requires care and understanding, but it is possible. One of the reasons async/await is so complicated in Python is that you can bring your own plumbing. The most common plumbing tools that are winning are event loop based, but there are other options, some of which allow synchronous semantics. Similarly, Rust's async/await support is nearly as complicated, just with fewer competing third party library options. Thinking about Futures/Promises/Tasks from a JS-heavy perspective (which I can presume by your preference for the name Promises) where everything has to be browser-mediated microtasks in an event loop makes it really easy to mistake this one monad tree (of microtasks on an event loop) for the overall forest of this large monad family (with a number of implementations under the hood).
  • eyelidlessness 2y ago
    I think you have completely misunderstood the point I was making. I was saying that you can’t implement JavaScript generators with JavaScript async/await, even in your hypothetical scenario where they’d been developed in the opposite order. The reason you can’t is because JavaScript async has specific semantics that are incompatible with JavaScript generators. It isn’t that my perspective is particularly skewed towards JavaScript, rather that the language semantics we’re discussing have semantics that you can’t generalize away entirely. And it isn’t so much that I don’t see the generalization you’re describing. You’re presumably coming from a place where you think it’s helpful to educate about the generalization, and that’s fine. But I’d suggest that when someone is clearly informed enough on the topic to clarify a language-specific nuance that diverges from the generalization, it probably isn’t because they’re ignorant, and it’s probably going to come off as rather condescending to respond as if they are.
    • WorldMaker 2y ago
      The topic at hand started as a generalization: "imagine a world where". That alternative world might not even have a Javascript. If you meant to make your point about the specifics of Javascript, I did not catch that change in topic and desire to talk about specifics, sorry.
      • eyelidlessness 2y ago
        Maybe you can “imagine a world” where you joined a conversation that was already taking place, about an article that framed the topic. It’s weird, and still rather condescending, to double down by suggesting I changed the topic which I was already engaged in before your imagination set the topic you think we were discussing. No need to apologize! But maybe, for your own benefit, go back and read through the thread again without trying to retcon your correctness onto it.
        • grddvbytdb 2y ago
          It was pretty obvious that the person was saying “hey generators and async/await are in some sense dual”. You’re unhinged.