5 ms·

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, i

• seivan 11y ago
  Hmm, I never got into using Promises. Jumped directly into Rx* and Observables.
  • untog 11y ago
    ...okay?
• runn1ng 11y ago
  What is the difference between "Promise" and "Future"? From what I read, it is basically the same thing.
  • nanodeath 11y ago
    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 made above, but otherwise has a whole slew of then* methods that aren't on Java's Future. Then again, that might just be because Java's Future is mind-numbingly simplistic.
    • the_af 11y ago
      Then again, Scala's Future/Promise terminology seems to be something else, though of course related.
  • btilly 11y ago
    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 the Future will arrive.
    • inglor 11y ago
      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.
      • btilly 11y ago
        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.
  • dustingetz 11y ago
    In Javascript: Promise is read-only (public interface), Deferred is writable (private) on JVM: Future is read-only (public), Promise is writable (private) The writable interface has "resolve" and "reject" to return a value. The readable interface has "then", "error", "finally" etc which let you compose and combine functions that deal in asynchronous values. The best Javascript implementation of promises is Bluebird, which doesn't expose a Deferred instance to avoid confusion, it is very nice. bluebirdjs.com/docs/api-reference.html
• barrkel 11y ago
  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 encapsulates the whole computation. You can then apply error handling to the final monadic value and be sure all errors across the whole computation will route to a single handler. When reading and writing code, the division between "creating the computation" and "running the computation" is thereby explicit and the error handling obvious. I've found promises most useful in managing asynchronous operations in the browser. With UI widget support (disabling things for the duration of a promise computation, showing spinners, showing progress bars, etc., automatically handling errors in an error alert area) it makes non-blocking UI much much easier to get right. For parallelism, I find different approaches easier to reason about, whether it's work queues or something like parallel LINQ / Java 8 Streams.
  • vonklaus 11y ago
    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