我正在阅读文档的每一寸，并尝试尽可能多地了解Folktale。
最近，我决定尝试Future。
现在，尽管我了解Task和Promise之间以及Task和Future之间的区别（支持取消），但我仍不清楚{{ 1}}和Future。
我为什么要使用Promise而不是Future？我会得到什么好处？
好吧，你可以说：“这样，你实际上有了一个单子，而不是一个单子的遗憾借口。”
这本身就是一个很好的论点，但是...考虑到我总是需要从Promise转换为其他内容（对future），并且Promise的API几乎相同，作为一个新手，我不清楚我为什么要完全关心Future。
假设我具有此功能，其中Future是发出请求并返回一些结果的功能。
request是从响应对象提取数据的功能。
如果失败，我将extractRequestInfo错误并返回一个包含所有数据，badId和错误的对象。
catch鉴于这是一个HTTP请求，我知道我不需要const requestFruit = request => data =>
request( data )
.then( extractRequestInfo )
.catch( error => ( { badId: prop( [ "Id" ], data ), error } ) );
，因为这里没有取消操作。因此，我的选择是Task和Promise。
Future？Future吗？答案 0 :(得分：1)
引用创建者Quil的回复：
未来解决了Promise所做的相同问题，因此 两者之间的概念差异。区别在于如何 他们解决了问题。
承诺可以成功解决，也可以失败。在任何转变中 您应用诺言的价值，同步引发的错误将是 也暗中抓住并拒绝了诺言。这是有趣的 在async / await中，因为您可以处理这些错误（同步和 异步）的方式-您无需取消所有 同步操作变成一个承诺，因为运行时会做到这一点 为你。
缺点是很容易发现您所犯的错误 并不想让您的系统在不一致的状态下运行。一世 也不认为您可以在这里做太多静态分析。
期货没有这个问题，因为没有东西被举起 隐含的未来。如果您希望同步操作使用 将来用于处理错误的管道，您必须将它们放在那里 明确地。这使您可以更好地控制错误处理，并且 未捕获的错误仍会按预期使进程崩溃（避免 在某些情况下让程序进入不一致的内存状态 没想到），但是用这种方式编写程序需要花费更多的精力。
除此之外，如果您考虑使用“任务”，则期货将最终建模 具有成功案例，失败案例和任务的Task的值 取消情况。承诺只有成功的案例和失败的案例 情况下，因此将取消建模为特殊的失败值。这个 更改用于处理取消的习惯用法。有可能 使用Promise的代码处理失败而没有意识到这一点 特殊取消值，由于该值，可能会出现问题 在这些转换过程中很容易丢失。
在混合了承诺和任务的代码库中，这些问题更多 之所以复杂，是因为承诺所隐含的错误消除是 与错误的显式适应不太兼容 预期的任务/未来（这可能会导致这样的问题：＃163）。 与只有诺言的情况相比，发现这些错误要困难得多 或仅任务/未来。不确定处理这些的最佳方法是什么 案件。
对于原始讨论：