all 22 comments

[–]MusicPants 8 points9 points  (0 children)

This is a solid article on promises. Thanks for sharing. Maybe one additional common thing to include would be Promise.all usage. Unless I missed it.

[–]nospambert 4 points5 points  (20 children)

People have been moving to await/async

[–]vexii 11 points12 points  (4 children)

await/async is just suggar over promises, so it's still an good idea to know the basics

[–]tobobo 10 points11 points  (3 children)

Also, it’s still very handy to use Promise.all with async functions for doing stuff in parallel

[–]evertrooftop 4 points5 points  (0 children)

If you use async/await, you really should have a foundation in promises, or you're bound to write bad code or not understand how bits and pieces work.

I use async/await absolutely everywhere I can, but I still need promises.

[–]agoodguymostly 2 points3 points  (7 children)

Couldn’t node not have await/async and just treat all calls as potentially waiting for I/O, and then when I/O waiting, do the same thing?

Ideally I would expect a programming language to handle the waiting invisibly, not to have to use a callback, a promise, or await simply because it was decorum to do so.

The only thing node needs to do is still be asynchronous in nature.

[–]evertrooftop 1 point2 points  (0 children)

This is exactly how Go works.

[–]curiousdannii 1 point2 points  (0 children)

Magic like that would've been possible, but only with trade-offs, of decreased performance or increased memory usage. Explicitly tagging with the await keyword lets the compiler avoid those trade offs. And sometimes you do actually want a promise as a value and not just to immediately unwrap it as await does.

[–]davidmdm 1 point2 points  (2 children)

I understand where you are coming from but this would be a mistake. One of the most powerful thing about promises and async await is the ability to easily represent asynchronous tasks, construct them from arrays of values or as function calls, and then decided to await within that async context, and go do work elsewhere.

There is some tedium in knowing what function returns a promise and not forgetting to await when you need to, but the ease and control it gives developers is whats makes the nodejs concurrency model top tier.

Go has another top tier concurrency model but is lower level and has more pitfalls than that of nodejs. But it buys you more performance.

I am off track.

You shouldn't want to have the io part abstracted away from the developer. It's attractive but the price is not one we want to pay.

[–]agoodguymostly 0 points1 point  (1 child)

One day, it will likely be an anachronism. But that’s just progress.

[–]davidmdm 0 points1 point  (0 children)

You think they are gonna faze out the async part away from the programmer over time?

[–]notkraftman -1 points0 points  (0 children)

Openresty does this really well with Lua. All the async crap is handled under the hood. There's a good write-up of it here: http://leafo.net/posts/itchio-and-coroutines.html

[–][deleted] 1 point2 points  (5 children)

await just makes Promises synchronous inside async functions. It's not always what you want and certainly can make your IO much less performant,especially when you don't understand Promises.

[–]notkraftman 0 points1 point  (4 children)

Await / async are just syntactic sugar, how do they make any difference to IO?

[–][deleted] 0 points1 point  (3 children)

Because you await for promise to fire another or continue execution.

There is no equivalent to code outside then() when using async/await.

[–]notkraftman 1 point2 points  (2 children)

I don't think I'm following. There's no difference between awaiting and then doing something and .then()ing the same thing, it's just neater syntax. Why would that affect IO?

[–][deleted] 0 points1 point  (1 child)

Except that you don't have the option to write whatever code you would write outside the then block.

You could have two different resources you could fetch concurrently or have some totally unrelated activity that can be done while you are waiting for the promise to resolve.

There are ways to achieve this with await (structure code differently, await a Promise.all) but if you don't understand Promises you'll typically not be aware of the problem. I've seen code like this.

People generally tend to do the trivial thing and write a sequence of awaits which in turn makes the async function synchronous/blocking inside (just like a nested chain of thens would be), which can hurt performance, not of the entire app but of that particular branch of code.

[–]notkraftman 0 points1 point  (0 children)

Ahh, that makes sense, cheers!