What is Folktale's Future for?

Question

Background

I am reading every inch of the docs and trying to learn about Folktale as much as I can. Recently, I decide to try Future.

Do we need a Future?

Now while I understand the difference between Task and Promise and between Task and Future ( support for cancellation ) it is not clear to me the difference between Future and Promise.

Why would I ever want to use a Future instead of a Promise ? What benefits would I have? Well, you can say: "This way you actually have a monad, instead of a sorry excuse for a monad".

And that is a fine argument on it's own but... having in mind I always need to convert from Promise to something else ( to future ) and that the Future's API is pretty much the same, it is not clear to me, as someone new, why I should care about Future at all.

Code sample

Lets assume I have this function, where request is a function that makes a request and returns some results.

extractRequestInfo is a function that extracts data from the response object. If something fails, I catch the error and return an object with all the data, the badId and the error.

const requestFruit = request => data =>
    request( data )
        .then( extractRequestInfo )
        .catch( error => ( { badId: prop( [ "Id" ], data ), error } ) );

Given that this is an HTTP request, I know I don't need a Task because there is no cancellation I can do here. So my options are Promise and Future.

Questions

1. How would I use Future in this sample?
2. Since this is something that can fail, should I use Result as well?

Answer 1

Quoting the response from the creator Quil:

Future solves the same problem Promise does, so there isn't much of a conceptual difference between the two. The difference is more in how they solve the problem.

Promises can either settle successfully or fail. In any transformation you apply to a promise's value, errors thrown synchronously will be implicitly caught and reject the promise as well. This is interesting in async/await because you can handle these errors (synchronous and asynchronous) in a similar way--you don't need to lift every synchronous operation into a promise, because the runtime will do that for you.

The downside of this is that it's very easy to catch errors that you didn't intend to, and have your system run in an inconsistent state. I don't think you can do much with static analysis here either.

Futures don't have that problem because nothing is lifted into a future implicitly. If you want synchronous operations to use the Future pipeline for handling errors, you have to put them there explicitly. This gives you more control over error handling, and uncaught errors will still crash the process as expected (avoiding having your program run into inconsistent memory states for cases you didn't predict), but it takes more effort to write programs this way.

Other than that, if you consider Tasks, Futures model the eventual value of a Task with a success case, a failure case, and a cancellation case. Promises only have a success case and a failure case, so cancellation is modelled as a special failure value. This changes the idioms for handling cancellations a bit. It's possible for code using promises to handle failures without being aware of this special cancellation value, which may be a problem since this value may easily be lost during these transformations.

In codebases that mix promises and tasks, these problems are more complicated because the implicit-lifting of errors that promises do is not very compatible with the explicit-lifiting of errors that tasks/futures expect (this can lead to problems like this one: #163). Finding these bugs becomes a lot harder than if you had only promises or only tasks/futures. Not sure what's the best way to handle these cases yet.

For the original discussion:

https://github.com/origamitower/folktale/issues/200