Future vs Lazy

[cristianoc]

Is it correct to think about the current implementation as lazy evaluation, in that functions are delayed and executed on demand, rather than started asynchronously?

[gilbert]

Good question! This lib behaves like promises in the fact that they are executed as soon as you make one. In other words...

Future.make(resolve => {
  Js.log("executing!");
  resolve(10)
})

...will log "executing!" immediately, even if you never call Future.map or Future.get.

Why strictness? I went down a rabbit hole of researching the pros and cons of lazy vs strict, how JS promises might have benefitted if they were lazy instead, and even implemented lazy as a first draft. However, the only use case I could find for pro-lazy was "async data loading with a dependency graph". There might be more, but for the common case, strict is more convenient than lazy, and it's easy enough to go lazy when you need to by writing a simple thunk like let makePromise = (args) => new Promise(...).