DEV Community

Discussion on: Why to use async & await instead of the Promise class?

 
macsikora profile image
Pragmatic Maciej • Edited

Aren't most asynchronous operations side effects? Last time I checked I/O operations were considered side effects, for instance.

Yes, but you have referred that async/await is imperative, and Promises are not. They both are imperative, as they are doing side-effects, so there is no difference.

There's more to it than simply saying "imperative code is about side effects and mutations".

This is the only definition of imperative programming which doesn't break at the long term. Imperative programming needs to change state. You can use statements and write purely functional code. Statement are for sure constructs made for potentially side-effectfull programs, but it doesn't mean you can't use them in FP.

This is example of do notation:


do { putStr "Hello"
   ; putStr " "
   ; putStr "world!"
   ; putStr "\n" }

Its look and feel sequential. Does it mean it is imperative code? Its truly not. Does it mean it is not functional code, nope it doesn't either. "Do notation" is syntax sugar for chaining monads, the same as async/await is syntax sugar for chaining Promises.

Async/await was firstly introduced in functional language - F#. There is nothing non-functional in the concept itself.

That is true that in JS when we use async-await the code uses likely statements and try/catch, and truly these aren't concepts from functional world, but there is no difference between .catch in Promise chain and try/catch in async/await. Its the same thing but written differently.

Although I understand the sentiment that Promise chaining feels more like declarative programming, in reality both ways change the state and not declare the change like IO Monad in Haskell does, therefore both are imperative.