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

31–40 of 91 posts

Re: How do Promises Work?

#31

Post by erikpukinskis »

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 orchestrates that.

Re: How do Promises Work?

#32

Post by anonymoushn »

Shog9 wrote: post #18
radiospiel wrote: post #15

Earlier quoted context omitted.

I am not calling to ignoring the async nature of computing in general, I am calling for better tooling. The Linux (and other OS'es) kernel handles I/O asynchronously, yet processes using open(2) + friends work quite well and are usually written in synchronous style. That the actual asyncness is hidden in kernel space does in general not lead to bad programs; and whoever needs async in the space of a single process ca…

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?

Re: How do Promises Work?

#34

Post by Matthias247 »

radiospiel wrote: post #15
Shog9 wrote: post #5

Earlier quoted context omitted.

Sounds like a leaky abstraction. Easier to get started with maybe, but woe betide the legion of programmers who make assumptions based on the appearance of synchronous execution only to be left stranded when those assumptions don't hold. Asynchronous execution isn't an unfortunate design choice to be papered over; better to make it as easy as possible to learn and work with.

I am not calling to ignoring the async nature of computing in general, I am calling for better tooling. The Linux (and other OS'es) kernel handles I/O asynchronously, yet processes using open(2) + friends work quite well and are usually written in synchronous style. That the actual asyncness is hidden in kernel space does in general not lead to bad programs; and whoever needs async in the space of a single process ca…

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 think async/await is a good solution to make async code a little more readable.

Re: How do Promises Work?

#36

Post by findjashua »

chenglou wrote: post #9
findjashua wrote: post #7

Earlier quoted context omitted.

i love elixir actors / golang goroutines, since i don't have to give any special treatment to async operations.

Does elixir solve this problem? http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

the conclusion of the article specifies goroutines as solving this problem. Erlang processes are the same.

Here's a simple test for checking this: does the language provide a green-thread/coroutine abstraction, or do you work at the OS thread level:

In JS, C#, JVM languages, Python etc you work at the OS thread, so async operations need to be handled differently from synchronous one.

Elixir/Erlang, Go, Haskell etc provide green thread abstractions, so your green thread can block on an async operation without blocking the OS thread.

Elixir/Erlang is especially nice since each process (green thread) is completely isolated. This has multiple advantages:

i) when an erlang process (green thread) crashes, it doesn't take the other green threads on the OS thread down with it.

ii) garbage collection is per erlang process, not for the entire run-time. So the garbage collector doesn't halt everything when it runs. This makes it a really solid option for soft real-time systems

iii) stack trace is also per green thread, so you only see execution steps for the particular green thread in the stack trace, this makes debugging much much easier

iv) erlang processes can communicate with processes on other machines, this makes it a really good option for dist systems

The only drawback is that it's slow for cpu bound stuff, so i'd avoid it for anything that's computation intensive

disclaimer: elixir fanboy

Re: How do Promises Work?

#37

Post by Osiris »

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?

Some Promise library add support for things like `.timeout` so you can force a promise to reject if the promise takes too long to resolve.

In cases like a node.js server, Promises allow a single node instance to handle thousands of concurrent requests because the event loop isn't blocking waiting for a single IO request to complete, the process can happily do lots of other things while Promises are pending.

Re: How do Promises Work?

#38

Post by the_af »

nanodeath wrote: post #22
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.

As far as I can tell, there's two differences. 1) a Promise typically has a "public" API and a "private" API -- the private API has read/write access and the public API has only read access. This way you can return the public API object to consumers of a method/library without worrying about them mutating the promise. 2) Promises tend to be more...composable? Java's "CompletableFuture" API fails on the #1 point I mad…

Then again, Scala's Future/Promise terminology seems to be something else, though of course related.

Re: How do Promises Work?

#39

Post by vonklaus »

barrkel wrote: post #28
hvmonk wrote: post #11

I have seen how Promises' concept was abused in a project at work. All the promises were just returning Future objects, and they were exposed everywhere. And, in case a future fails for some reason, there was no way to have a new Future: all users were doing future.get, resulting in an exception thrown to the caller. What a mess.

IMO if you're to get the benefits of promises, you need to use callbacks rather than using synchronous accessors like a .get() method. Making a 'get' accessor available just encourages blocking, reducing the very parallelism and asynchrony that promises are introduced to make usable. When you chain and compose together operations on promises using a nice fluent API, you're building up a monadic value that encapsulate…

i have really been trying to work on this, amd my js design in general.i have been trying to watch at least 1 doug crockford lecture a day and dig in to node design patterns.

i am a mediocre developer and it is super hard to find resources. either they are way to beginner such as an introduction yo for loops, a project structure that is not modular but one monolithic binary for the basic example or an otherwise simplified usecase that can not really be extended very well.

otoh, some stuff is way to intense and can't grep that either. if you know of any good design patterns that explain concepts like promises, leveraging functional closures in a factory/singleton or otherwise great code concepts; but explained either at the intermediate or beginner level, that would be great.

i love resources that assume limited knowledge, they just don't seem to go into the interesting/useful parts of the language in enough depth to leverage

Post reply on HN