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.
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
From what I read, it is basically the same thing.
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.
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.
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