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

51–60 of 91 posts

Re: How do Promises Work?

#51

Post by ashark »

bm1362 wrote: post #50
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.

Compare this to Go, what % of go code do you think lies inside a go routine?

Potentially almost all of it, but the point is that if _most_ of your requirements are "get thing, do thing with it, decide other thing to do based on that" you don't have to spin off three goroutines to accomplish it (roughly the equivalent, as far as wasted effort/mental overhead goes, of needless promises/callbacks which are abused to work out identically to performing those things in sequence). You do it all in one. Maybe it's just me, but I find that most of the time what I need to do can be boiled down to between 1 and 3 (and usually on the lower end of that) lists of things that need to be done in sequence (threads, if you will) and that Node is a poor fit for that, since its ideal case seems to be doing dozens of things, none of which depend on one another, then collecting them at the end, which is something I rarely ever need to do—if I do, typically the the "dozens of things" are really just one or two things with different data and therefore are very easy to parallelize without resorting to Node's typical patterns.

I'm sure there's a workload where async-all-the-things makes things easier rather than harder, I just haven't run into it.

[EDIT] "rarely never" to the intended "rarely ever"

Re: How do Promises Work?

#52

Post by inglor »

btilly wrote: post #41
runn1ng wrote: post #20

Earlier quoted context omitted.

What is the difference between "Promise" and "Future"? From what I read, it is basically the same thing.

People do not use the terms consistently. The difference is SUPPOSED to be that a Future is read-only while a Promise is settable. And should be set at most once! So you can use a Promise as a Future, but you can't always use a Future as a Promise. Linguistically you can understand this as, "I Promise you'll see a Future answer." I need to be able to write to the Promise to fulfill it. You can only hope that some day…

That changes by language - what you say is true in Scala, but in JavaScript the terminology is different. A future is not defined, a promise is a future and a deferred is a promise.

Re: How do Promises Work?

#53

Post by inglor »

hotBacteria wrote: post #40

I found this document : https://github.com/kriskowal/q/tree/v1/design very helpful to understand how promises work behind the scene Also liked being able to access the author's reasoning and the motivations behind his design decisions

If you're going to mention Kris and concurrency, you better mention: https://github.com/kriskowal/gtor

Re: How do Promises Work?

#55

Post by btilly »

inglor wrote: post #52
btilly wrote: post #41

Earlier quoted context omitted.

People do not use the terms consistently. The difference is SUPPOSED to be that a Future is read-only while a Promise is settable. And should be set at most once! So you can use a Promise as a Future, but you can't always use a Future as a Promise. Linguistically you can understand this as, "I Promise you'll see a Future answer." I need to be able to write to the Promise to fulfill it. You can only hope that some day…

That changes by language - what you say is true in Scala, but in JavaScript the terminology is different. A future is not defined, a promise is a future and a deferred is a promise.

That is what I mean about people being inconsistent.

The ideas are much older than Scala, JavaScript, and many of the people commenting in this discussion. Believe it or not, both terms date back to the late 1970s.

Scala got it right. JavaScript got it wrong. And polyglots like me have to suffer with having to sort out who means what, where, on what platform.

Re: How do Promises Work?

#56

Post by Matthias247 »

rdtsc wrote: post #45
Matthias247 wrote: post #34

Earlier quoted context omitted.

Imho in this area there is really no general good solution: Either you use the leaky blocking IO abstraction over the async IO - and you will require multiple threads/tasks for doing anything more complicated and lots of complex synchronization. Or you use the async APIs directly and need to work with callbacks/promises/etc., but you can at least avoid synchronization. I personally prefer the async solution, and I th…

> 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 various timeouts, different error handling strategies, multicast communication, cancellation and other stuff to your async IO procesing then it isn't purely linear anyway. I often end up implementing quite complex state machines for heavy IO related code, and for this I am more happy with working in an asynchronous single-threaded environment.

Re: How do Promises Work?

#57

Post by bm1362 »

ashark wrote: post #51
bm1362 wrote: post #50

Earlier quoted context omitted.

Compare this to Go, what % of go code do you think lies inside a go routine?

Potentially almost all of it, but the point is that if _most_ of your requirements are "get thing, do thing with it, decide other thing to do based on that" you don't have to spin off three goroutines to accomplish it (roughly the equivalent, as far as wasted effort/mental overhead goes, of needless promises/callbacks which are abused to work out identically to performing those things in sequence). You do it all in o…

To be clear, I agree. I've argued for explicit concurrency rather than always asnyc. I prefer Go over Node for this very reason.

Re: How do Promises Work?

#58

Post by SerpentJoe »

anonymoushn wrote: post #32
Shog9 wrote: post #18

Earlier quoted context omitted.

Apples and oranges. You're describing a platform where it's considered acceptable for programs to block on IO and jump through hoops in rare cases where that's absolutely not ok. A set of assumptions that maybe still made sense 30 years ago, and also a leaky abstraction, but one we've become accustom to working around. If you want that in JavaScript, you can have it; promises were created on the assumption that async…

What are you going to do in Javascript, though, if the I/O takes some time to happen? In golang or lua or whatever I can say "this execution context should block on the I/O for x seconds, then give up and return an error." (the other tens of thousands of execution contexts can keep going) In Javascript I would probably do... the same thing? But I would do it using promises?

You can do something like this (using Bluebird's Promise.delay for convenience):

    // using Promise.race so whoever finishes first wins
    var fetchingWithTimeout = Promise.race([
      
      // first promise: actually try to perform the computation
      fetching,
      
      // second promise: wait x seconds, then reject
      Promise.delay(x*1000).then(Promise.reject('Timed out')),
      
    ]);
You can apply the timeout wherever you want (or apply different timeouts in different corners of the app) without throwing out the raw promise to perform the computation no matter the time cost.

Re: How do Promises Work?

#60

Post by vectorjohn »

btilly wrote: post #43
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…

This is a common gotcha in Javascript implementations, in that you think you want this, but you really don't! No, I really, really, DO want this. And I want my entire codebase written in such a way that this is fine. You need consistent abstractions to make asynchronous logic flow comprehensible. And once you have them, stick to them rigorously. Promises are such an abstraction. Build on it, don't ruin it. Yes, there…

I think you (or I) misunderstand what you're replying to. When they said "you really don't want this", they're saying you don't want promises to sometimes be async and sometimes resolve in the same tick. Always make them async. That agrees with you, since it would mean you can always treat promises the same.
Post reply on HN