I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
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
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 ;-)
I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
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.
And Structs in Elixir can be compared to classes. That doesn't make them Object-Oriented.
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 atry/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 thetry/catch
statement and then mutate it depending on the result. I'm no expert, but this doesn't sound very functional to me.I'm pretty sure that was my comment's point as well ;-)
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.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:
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.