DEV Community

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

Collapse
 
savagepixie profile image
SavagePixie

Yeah, honestly the argument "async/await is better because I can write messy code using promises" is getting old. I can write really crappy code with any syntactical construct, but that doesn't make them any better or worse.

At the end of the day, I think it mostly comes down to style. If you prefer imperative code, you'll like async/await better because it's more imperative. If you prefer functional code, you'll like promises better.

Collapse
 
macsikora profile image
Pragmatic Maciej • Edited

First of all async await is a syntax sugar for Promises. Doing one vs another has not sense, both are in the same bandwagon. Secondly async/await can be more compared with Haskell do notation. Imperative code is about side effects, mutations. Until you don't do that you cannot say it's imperative code, therefore using async await vs raw promise is more code style

Thread Thread
 
savagepixie profile image
SavagePixie • Edited

First of all async await is a syntax sugar for Promises. Doing one vs another has not sense, both are in the same bandwagon.

That doesn't make them the exact same, though. Nor does it make them equivalent in all regards. Even if they are meant to achieve the same goal, they are expressed differently. This means that there's got to be some difference between them. So it makes sense to discuss their differences.

Secondly async/await can be more compared with Haskell do notation.

And Structs in Elixir can be compared to classes. That doesn't make them Object-Oriented.

Imperative code is about side effects, mutations. Until you don't do that you cannot say it's imperative code

Aren't most asynchronous operations side effects? Last time I checked I/O operations were considered side effects, for instance.
There's more to it than simply saying "imperative code is about side effects and mutations". As far as I'm aware, all programming languages deal with side effects in one way or another, however functional they are.
Besides, imperative code also uses, for instance, statements. In order to deal with errors with async/await, you use a try/catch statement. If you want the value of a variable to depend on whether an asynchronous operation is successful, you need to create a variable outside of the try/catch statement and then mutate it depending on the result. I'm no expert, but this doesn't sound very functional to me.

therefore using async await vs raw promise is more code style

I'm pretty sure that was my comment's point as well ;-)

Thread Thread
 
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.