8 ms·

Wow that was informative. So ES Modules is really about the Red functions [1] getting module support. I find it fascinating watching our understanding of async

Wow that was informative. So ES Modules is really about the Red functions [1] getting module support. I find it fascinating watching our understanding of async computation mature over the years. [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function// http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

secondcoming 6y ago
The whole point of that article is that it hasn't really matured at all
- dgellow 6y ago
  I’m not sure if that’s true. I remember that at some point there were more than 2 systems, none were standards, and they were widely incompatible, I remember AMD for example: https://github.com/amdjs/amdjs-api/blob/master/AMD.md https://github.com/amdjs/amdjs-api/blob/master/AMD.md. I cannot find the others though.
wruza 6y ago
The last time I asked here why async-await is even a thing, when you can just introduce light/green threads, coroutines, you name it, everyone jumped that it is even better when you mark awaiting points explicitly. Now that it goes from a blog post of some popular language designer, seems no one gonna disagree. >async computation mature over the years A good thing, really, but would be much better if the experience from few decades ago wasn't ignored by cool kids who mature.
- gridlockd 6y ago
  The reason why async/await is a good fit for Javascript is that it neatly wraps up asynchronous callback hell and Promises, which were already ubiquitous in Javascript code, because the web runtime enforces non-blocking IO.
  - spanhandler 6y ago
    Never should have had to worry about that stuff to begin with, unless you were actively using it. I’ve read and written way more code that had to wrestle async back to sync than code that’s actually been able to let async happen at the local scope. Of course if you’re working in a framework (Express, say) one might expect that it would run your entire mostly-sync pile of code async, so it can hop over and process another request. And that’s fine. That’s how it should have worked. Most things should execute in an async context so other things can happen while they’re waiting on IO or whatever, but within them async behavior should have been what required a keyword or a bunch of hideous nesting or whatever.
  - pansa2 6y ago
    Do Promises and async-await work together better than, say, Promises and Lua-like stackful coroutines?
    - z3t4 6y ago
      I dont know Lua, but async/await in JavaScript is syntax sugar for a coroutine.
    - WorldMaker 6y ago
      This description is probably far more abstract than most would like (and it is probably wrong by not being exact enough, I am not a mathematician I am a software developer), but might be useful to some: coroutines are a join calculus and Promises are a monad. async/await is syntactic sugar for a monad (less general than Haskell's do-notation, more general than only Promises, though rarely in practice used much beyond Promises). You could plumb Promises on top of coroutines easily (and while JS engines are more traditionally event loops; other languages that support async/await such as Python use much more coroutine-like underbellies), and while you don't get the full "join calculus" power/flexibility by putting the monad abstraction on top of the join calculus, you get the benefit of monad transformers like async/await. Those benefits being that the async/await syntax and semantics for working with Promises more closely resembles the imperative code it replaces, whereas the join calculus is its own [sometimes easy, admittedly] learning curve with its own syntax and semantics. Most of the complaints about Promises are the usual complaints about monadic wrapping types that the types become "viral" and "color" all associated code. But that just means that the failure cases are more easily picked up by a static type checker than semantic failures in learning the join calculus.
- nemothekid 6y ago
  In regards to JS, any reasons for a sync await seems to be rationalization. Node is built on V8, which is built for browsers. Browsers have a single threaded execution model that also hides an event loop that runs the entire tab.
  - dboreham 6y ago
    Yes, async await is a bug, introduced to workaround the lack of proper concurrency in the runtime.
samth 6y ago
No, this is not correct. The split long predates async in JS The fundamental reason behind the difference between ES modules and CJS is that require() does synchronous I/O in a function, but that's not acceptable in the browser context. So you either need to make require an asynchronous function (meaning with a callback, back in 2010 when this happened) or move the I/O out of the execution of module itself, as import does.
- z3t4 6y ago
  Sync xhr is being depricated. Meanwhile Google and Facebook analytics/tracking freeze the main thread for a whooping two seconds. Why not push the module dependencies with http2 push? The problem is not technical. Its big money wanting to break backwards compatibility.
  - WorldMaker 6y ago
    Even HTTP/2 Push is an order of magnitude slower than local File I/O on a good day with perfect (internet) weather. ESM isn't even the first approach to try to deal with this, for instance AMD had nothing (at first) to do with "big money" and everything to do with average web developers trying their best to practically solve the module problem for the web and CommonJS was never going to be an option in a web browser (even if AMD or ESM spec authors had magic foresight to HTTP/2 or HTTP/3 they'd still have the same concerns with CommonJS). CommonJS was a mistake that the JS world is going to live with for years more.
    - z3t4 6y ago
      The Node.js module system is only loosely based on CommonJS. The Node.js module system is probably the biggest reason of the success of the Node.js ecosystem. Ifyou want to attack Node.js you would start with the module system.

secondcoming 6y ago

The whole point of that article is that it hasn't really matured at all

dgellow 6y ago
I’m not sure if that’s true. I remember that at some point there were more than 2 systems, none were standards, and they were widely incompatible, I remember AMD for example: https://github.com/amdjs/amdjs-api/blob/master/AMD.md https://github.com/amdjs/amdjs-api/blob/master/AMD.md. I cannot find the others though.

wruza 6y ago

The last time I asked here why async-await is even a thing, when you can just introduce light/green threads, coroutines, you name it, everyone jumped that it is even better when you mark awaiting points explicitly. Now that it goes from a blog post of some popular language designer, seems no one gonna disagree. >async computation mature over the years A good thing, really, but would be much better if the experience from few decades ago wasn't ignored by cool kids who mature.

gridlockd 6y ago
The reason why async/await is a good fit for Javascript is that it neatly wraps up asynchronous callback hell and Promises, which were already ubiquitous in Javascript code, because the web runtime enforces non-blocking IO.
- spanhandler 6y ago
  Never should have had to worry about that stuff to begin with, unless you were actively using it. I’ve read and written way more code that had to wrestle async back to sync than code that’s actually been able to let async happen at the local scope. Of course if you’re working in a framework (Express, say) one might expect that it would run your entire mostly-sync pile of code async, so it can hop over and process another request. And that’s fine. That’s how it should have worked. Most things should execute in an async context so other things can happen while they’re waiting on IO or whatever, but within them async behavior should have been what required a keyword or a bunch of hideous nesting or whatever.
- pansa2 6y ago
  Do Promises and async-await work together better than, say, Promises and Lua-like stackful coroutines?
  - z3t4 6y ago
    I dont know Lua, but async/await in JavaScript is syntax sugar for a coroutine.
  - WorldMaker 6y ago
    This description is probably far more abstract than most would like (and it is probably wrong by not being exact enough, I am not a mathematician I am a software developer), but might be useful to some: coroutines are a join calculus and Promises are a monad. async/await is syntactic sugar for a monad (less general than Haskell's do-notation, more general than only Promises, though rarely in practice used much beyond Promises). You could plumb Promises on top of coroutines easily (and while JS engines are more traditionally event loops; other languages that support async/await such as Python use much more coroutine-like underbellies), and while you don't get the full "join calculus" power/flexibility by putting the monad abstraction on top of the join calculus, you get the benefit of monad transformers like async/await. Those benefits being that the async/await syntax and semantics for working with Promises more closely resembles the imperative code it replaces, whereas the join calculus is its own [sometimes easy, admittedly] learning curve with its own syntax and semantics. Most of the complaints about Promises are the usual complaints about monadic wrapping types that the types become "viral" and "color" all associated code. But that just means that the failure cases are more easily picked up by a static type checker than semantic failures in learning the join calculus.
nemothekid 6y ago
In regards to JS, any reasons for a sync await seems to be rationalization. Node is built on V8, which is built for browsers. Browsers have a single threaded execution model that also hides an event loop that runs the entire tab.
- dboreham 6y ago
  Yes, async await is a bug, introduced to workaround the lack of proper concurrency in the runtime.

samth 6y ago

No, this is not correct. The split long predates async in JS The fundamental reason behind the difference between ES modules and CJS is that require() does synchronous I/O in a function, but that's not acceptable in the browser context. So you either need to make require an asynchronous function (meaning with a callback, back in 2010 when this happened) or move the I/O out of the execution of module itself, as import does.

z3t4 6y ago
Sync xhr is being depricated. Meanwhile Google and Facebook analytics/tracking freeze the main thread for a whooping two seconds. Why not push the module dependencies with http2 push? The problem is not technical. Its big money wanting to break backwards compatibility.
- WorldMaker 6y ago
  Even HTTP/2 Push is an order of magnitude slower than local File I/O on a good day with perfect (internet) weather. ESM isn't even the first approach to try to deal with this, for instance AMD had nothing (at first) to do with "big money" and everything to do with average web developers trying their best to practically solve the module problem for the web and CommonJS was never going to be an option in a web browser (even if AMD or ESM spec authors had magic foresight to HTTP/2 or HTTP/3 they'd still have the same concerns with CommonJS). CommonJS was a mistake that the JS world is going to live with for years more.
  - z3t4 6y ago
    The Node.js module system is only loosely based on CommonJS. The Node.js module system is probably the biggest reason of the success of the Node.js ecosystem. Ifyou want to attack Node.js you would start with the module system.