1. 9
  1.  

  2. 5

    One wonders…why not assume that all functions are async by default?

    Then, you could imagine writing all statement with async in front of function invocations. Then, the interpreter could just immediately resolve the ones that can be resolved immediately (e.g., function that concatenated two strings). One could even imagine a script that does this to any existing codebase.

    Oh wait, that’d be dangerously close to the concurrency we already have in other languages. Sigh. :(

    EDIT: Seriously, it appears that the use of async is for cooperative multitasking, which wouldn’t be needed if JS had proper preemptive multitasking built into it.

    1. 1

      Oh wait, that’d be dangerously close to the concurrency we already have in other languages. Sigh. :(

      What other languages are you thinking of? I am vaguely aware of some attempts in Haskell, but I don’t know anywhere that autoparallelization took off.

    2. 2

      If you expand the scope beyond JavaScript, what the author wants from generators seems to be a combination of futures, streams, and scheduling. This article didn’t really convince me that a single syntax merges these concepts well. (For example, I’m not sure I would want to open a function and wonder if it was implementing an async operation or generating a stream.)

      1. 2

        It’s interesting to see how python and JS are becoming more similar every day :)