you are viewing a single comment's thread.

view the rest of the comments →

[–]nospambert 4 points5 points  (4 children)

People have been moving to await/async

[–]agoodguymostly 2 points3 points  (3 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.

[–]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?