Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How do Promises Work?

robotlolita.me

Post reply on HN
Print view View original

81–90 of 91 posts

Re: How do Promises Work?

#81

Post by ilaksh »

ashark wrote: post #8
radiospiel wrote: post #3

Nicely done, thanks! Still, having to explain a concept as simple as eventual computation reinforces my belief that promises as a whole is broken, and should be done in something that looks like synchronous code with some help of the underlying runtime. (And no, ES7's async is not good enough for me here)

NodeJS: you needed 5% of your code to be async, so we made everything async so you get to write awkward async-but-not-really code for the other 95%, too. That's better, right? At least that's how it's always felt when I've used it for anything non-trivial yet well within its typical set of use cases.

Use async/await with babel.

Re: How do Promises Work?

#83

Post by qaq »

dboreham wrote: post #19
ashark wrote: post #8

Earlier quoted context omitted.

NodeJS: you needed 5% of your code to be async, so we made everything async so you get to write awkward async-but-not-really code for the other 95%, too. That's better, right? At least that's how it's always felt when I've used it for anything non-trivial yet well within its typical set of use cases.

Despite the downvotes, you are absolutely correct. My feeling, after working on a moderately complex server application in Node is that it was designed for only very simple applications that can be done with one level of callback. I find the "it works this way because its better" cult quite irritating. It works that way because the #*(^#$&^ JS interpreter isn't multithreaded.

on the browser side modern browsers support webworkers

on the node side https://www.npmjs.com/package/webworker-threads

Re: How do Promises Work?

#84

Post by bhrgunatha »

taternuts wrote: post #82

TIL: fulfil vs fulfill [1] 1. http://grammarist.com/spelling/fulfil-fulfill/

The second nGram linked there (showing the rise of fulfill - with 2 l's in American English)[1] seems to show that the increase in use of 2 l's started around the same time as Noah Webster's dictionary was first published. [2]

I've always been fascinated why there is such a difference between spelling in "British" and "American" English, I remember reading that the main reason was Webster's dictionary and his desire to reform spelling according to pronunciation. That Wikipedia article though quotes John Algeo: "He was very influential in popularizing certain spellings in America, but he did not originate them."

So now I'm as confused as ever. Why DID the spellings change so significantly. I can accept that they took hold due to Webster's work, but I wonder why the differences arose in the first place?

[1] https://books.google.com/ngrams/graph?content=fulfil%2Cfulfi...

[2] https://en.wikipedia.org/wiki/Noah_Webster#Dictionary

Re: How do Promises Work?

#85

Post by lomnakkus »

Matthias247 wrote: post #56
rdtsc wrote: post #45

Earlier quoted context omitted.

> Either you use the leaky blocking IO abstraction over the async IO What do you mean the leaky blocking IO. It is the non-blocking IO that is leaky, isn't it. If at the business logic there is a request being processed that needs to go through steps a,b,c and then return. b, can't be done unless a finishes and c unless b finishes is mapped pretty cleanly to an execution context of a thread/actor/goroutine/task/proce…

What I meant is that blocking IO is a leaking abstraction, because IO is always asynchronous. What blocking does is adding an extra step (start the process AND waiting for the result) and thereby hiding something. I agree that if you have some pure linear steps (do A, then do B, then do C, and probably use the result from the last step for the next), then the synchronous abstractions work fine. But as soon as you add…

I think you're using the term "leaky abstraction" much more literally than most other people do. If we take your interpretation to the logical (albeit extreme) conclusion, then even "read the value of variable X" is asynchronous and should really be modeled asynchronously.

> for heavy IO related code, and for this I am more happy with working in an asynchronous single-threaded environment.

You're not describing the majority of applications. The vast majority of applications do negligable amounts of complex network I/O (ignoring GUI, which is handled for them by... an abstraction).

It would be a bad idea to base our abstractions on things only needed for a tiny minority of applications.

Re: How do Promises Work?

#86

Post by Matthias247 »

rdtsc wrote: post #73
Matthias247 wrote: post #56

Earlier quoted context omitted.

What I meant is that blocking IO is a leaking abstraction, because IO is always asynchronous. What blocking does is adding an extra step (start the process AND waiting for the result) and thereby hiding something. I agree that if you have some pure linear steps (do A, then do B, then do C, and probably use the result from the last step for the next), then the synchronous abstractions work fine. But as soon as you add…

> because IO is always asynchronous. Creating a socket() creates a blocking socket by default, doesn't it. Doing a recv on it, blocks the current thread. Pretty sure by default IO is synchronous. Sure at some point they are all connected to a single wire plugged into the switch and there is a single network card. But if you are thinking that low, then well javascript is not the framework to talk about we are in firmw…

That the default posix socket API is in blocking mode by default was a decision that was made lots of years ago and for some specific reasons. If the reasons at that time might have been different, then it could now also be async by default. So I don't think that tells us whether one or the other model is the more natural or a better one.

Look at the LWIP library for embedded for example. There the async API is the default one, and you have to take the extra mile (and some performance hit) to get the blocking behavior. The midori OS prototype also seems to have implemented a pure async IO subsystem.

I also think it depends on the use-case whether one or the other model is more appealing, but I don't think it's only for performance reasons. A lot of people here think about IO mainly in terms of http request processing because web services are the usual domain here. For this such applications I think blocking abstractions come quite naturally, because you there you read the input stream once, then do a sequence of intermediate processing steps and then write a response. If you instead are working on other domains (writing a message broker, a gateway application, http/2 library, realtime sensordata processing system, ...) where there is no linear sequence of read/write operations and where you have shared state between your IO endpoints then your needs and the preferred building blocks might be different.

Re: How do Promises Work?

#87

Post by Matthias247 »

lomnakkus wrote: post #85
Matthias247 wrote: post #56

Earlier quoted context omitted.

What I meant is that blocking IO is a leaking abstraction, because IO is always asynchronous. What blocking does is adding an extra step (start the process AND waiting for the result) and thereby hiding something. I agree that if you have some pure linear steps (do A, then do B, then do C, and probably use the result from the last step for the next), then the synchronous abstractions work fine. But as soon as you add…

I think you're using the term "leaky abstraction" much more literally than most other people do. If we take your interpretation to the logical (albeit extreme) conclusion, then even "read the value of variable X" is asynchronous and should really be modeled asynchronously. > for heavy IO related code, and for this I am more happy with working in an asynchronous single-threaded environment. You're not describing the m…

I don't think there are really numbers that tell us what the vast majority and the tiny minority of applications use. I think most people will have here some personal bias, because they see the applications that they are working on, the applications that their particular industry is working on and think that the rest of world might be similar.

When I worked on simulation code some years ago I haven't thought about complex IO at all. Even when I did some basic web development (with PHP...) 16 years ago I had nothing but synchronous IO and was happy. Now realtime gateway systems are my daily business and the "typical application" looks completly different.

And you already have given GUI as a counter example yourself. More then a tiny majority of applications have a GUI. And all major GUI frameworks are built on top of asynchronous abstractions, because you want GUIs to be reactive (no hanging due to blocking stuff), and because every input port (either from a human input device or from network) can change the shared state and cause output to more than one output device.

Re: How do Promises Work?

#88

Post by viperscape »

erikpukinskis wrote: post #31
wonnage wrote: post #24

> Another way of solving this problem comes from the realisation that we only really need to keep track of the dependencies for a promise while the promise is in the pending state, because once a promise is fulfilled we can just execute the function right away! This is a common gotcha in Javascript implementations, in that you think you want this, but you really don't! Now you never know if your code is synchronous o…

I get what you're saying, but for some reason it doesn't feel right to me. Part of it is that if your API requires you to think about whether or not it will run in the current or next tick, that's probably not the right API. I find in JavaScript it's best to just assume your callbacks could be called at any time, in any order. And if you need a specific priority then write some code that actually explicitly orchestra…

I find that hard to do when some libraries make heavy use of async, you basically have to bend to the library when writing your own code

Re: How do Promises Work?

#90

Post by erikpukinskis »

viperscape wrote: post #88
erikpukinskis wrote: post #31

Earlier quoted context omitted.

I get what you're saying, but for some reason it doesn't feel right to me. Part of it is that if your API requires you to think about whether or not it will run in the current or next tick, that's probably not the right API. I find in JavaScript it's best to just assume your callbacks could be called at any time, in any order. And if you need a specific priority then write some code that actually explicitly orchestra…

I find that hard to do when some libraries make heavy use of async, you basically have to bend to the library when writing your own code

I don't blame you. I basically don't use any libraries any more because the proliferation of promises (and libraries with promise-like architectures) has made everything impossible to reason about or debug. But I have the luxury of being a wizard in the forest who answers to no one.
Post reply on HN