Hacker News Reader

Comment by pier25 | Hacker News Reader

Aync/await is the best thing since sliced bread. It has made my life so much easier.

I understand the reasons why async/await is designed the way it is, but I still think it is backwards. Really if you wanted to truly make async programming approachable, you should make it transparent. What I mean by this is that instead of marking a function as async, and awaiting values, you'd mark lines as async, opting out of implicit awaits. I wrote up some thoughts on this here:

https://github.com/utilise/emitterify/issues/1#issuecomment-...

The way it is now, I defensively await things all over the place. What's worse, it propagates. If any of your function's dependencies are async, your function will also have to be async (or be ok with continuing operation after it's returned) and it turtles all the way down.

It is nicer than having to deal with promises directly though, there is that.

Agreed. Async is like a virus. Once you start somewhere pretty much everything else must be async too. In C# you can call async code from not async code and then call Task.Wait. Not sure if JS can do that.

But it still beats promises or callback hell.....

You can't really transition between async and sync scopes, no.

A better term than virus is that async is a monad. Welcome to programming with monads. ;)

JS async produces Promises like C# produces Task, so you can call an async function and use the result as a Promise.

Can you wait for a promise synchronously? I am pretty new to JS so please forgive if this is a stupid question.

It's not something JS engines allow today. It's also not something that entirely makes sense from the perspective of a browser threading model or even the libuv-based NodeJS threading model.

I know. We have some wacky use cases where it would make sense. The real answer would probably be to say "Don't use Node for this" but that's a different discussion above my pay grade.

The real answer is probably "those places you think need to synchronous don't need to be synchronous" and you need a refactor or a rearchitecture.

Trust me. We are not totally stupid. We need synchronous actions under some circumstances.

> But it still beats promises or callback hell.....

And then() hell ...

I started using Async/Await and liked it, but I've been learning more about functional programming and went back to Promises

It IS promises ;) labeling a function as async makes it return a promise. await is sugar for avoiding having to roll your own promise tree.

Sounds interesting -- do you have any resources handy that cover what you allude to (spec. comparing async calls to promises, and favoring the latter?) I use both in my ui code and they seem to have their niche for me. I prefer promise based calls when I want to separate out fetching data from the state-mutating callback, or when I may want to "cancel" something (ex: fetch a list of items for a list component, then unmount the component before the list returns -- no need to handle the response data anymore).

Unfortunately not, my opinion is simply based on my personal experience and on what I've been learning along the way. I find promises really handy for data processing pipelines (grab some data and perform some transformations over it to get it in the form you need), regardless of wether any of the steps is async or not. I still find async/await really useful and mix it with promises if I need it, but I prefer to keep my code as functional as I can. Besides, I don't really like how JavaScript handles exceptions and would rather staying away from try/catch if possible

There is no difference, async/await is just another promise notation.

Although async/await is simply syntax sugar around promises, there's a huge difference indeed. With async/await your code keeps an imperative style, while with promises code end up with a functional look

Agreed! once you start using it there's no going back (along with `util.promisify`)

Reply on news.ycombinator.com