Twitter的未来比Scala的未来有什么优势？

我知道Scala未来会更好的原因很多。有没有理由改用Twitter？除了Finagle使用它这一事实。

据我所知，使用Twitter的

未来的主要区别在于它可以被取消，这与scala的
未来的
不同

此外，过去还支持跟踪调用链（您可能知道，当使用未来时，普通堆栈跟踪几乎是无用的）。换言之，你可以展望未来，说出是哪个
map
/
flatMap
链产生了它。但是如果我理解正确的话，这个想法已经被放弃了。
免责声明：我在Twitter工作，负责未来的实现。稍微考虑一下上下文，我们在Scala对
未来的
有一个“良好”的实现之前就开始了自己的实现

以下是推特未来的功能：


有些方法名称不同，Twitter的
Future
在companion中有一些新的helper方法

e、 例如：
Future.join（f1，f2）
可以处理异构的Future类型

Future.join(
  Future.value(new Object), Future.value(1)
).map {
  case (o: Object, i: Int) => println(o, i)
}

o
和
i
保留它们的类型，它们不会被铸造到最不常见的超类型
中


保证按顺序执行一系列onSuccess：
e、 g:



#1保证在#2之前执行


线程模型有点不同。没有ExecutionContext的概念，在Promise（未来的可变实现）中设置值的线程是执行未来图中所有计算的线程。
e、 g:


直到最近，Twitter的未来还是唯一一个实现高效尾部递归（即，您可以拥有一个递归函数，它可以在不破坏调用堆栈的情况下调用自己）。它已经在Scala 2.11+中实现（我相信）

是的，但他们不久前不赞成取消（），赞成减少强制性加薪（）。是否在生产代码中使用了cancel（）？它有用吗？我没有使用它，部分原因是我不想被非标准twitter的
未来所束缚。但很容易看出它的用途。假设您同时生成了一些期货，然后通过
Future.sequence
加入它们的结果以生成最终结果。如果有一个失败了，你会很快失败，换言之，为了避免无用的计算，你会取消所有其他的未来。可以说，处理这种情况的标准/更好/不太脆弱的方法（不依赖于未来的取消）是使用参与者。至于
cancel
被弃用，取而代之的是
raise
，理由仍然是：这是scala未来的
中不存在的东西，可能会让你接触到Twitter的版本。@RégisJean Gilles顺便说一句，“如果任何一个失败了，你会很快失败”——这对于标准的
未来.sequence
，都不是问题，因为它直到序列中所有的
未来
完成才完成，即使其中一些提前失败。“它直到序列中所有的未来完成才完成，即使其中一些提前失败。”我是说，有时候你确实不想只完成（失败）当其中一个输入未来失败时的最终未来，但也会在任何一个输入未来失败时立即停止所有未来的执行<代码>未来。序列
当然不能这样做。取消是有意义的，特别是当你发出重复的请求来对抗延迟时……你好，史蒂夫。好久不见了。希望你一切顺利。关于这个问题，线程模型上的部分是一个巨大的差异，事实上，我忘记了那个。使用scala的
Future
我们必须请求隐式执行上下文，每次我们只想映射到未来，即使是添加日志之类的琐事，而使用Twitter的
Future
我们可以借助原始的未来线程，我不知道Scala为什么不提供类似于Twitter的LocalScheduler的ExecutionContext。
f.onSuccess { 
  println(1) // #1
} onSuccess { 
  println(2) // #2
}

val f1 = new Promise[Int]
f1.map(_ * 2).map(_ + 1)
f1.setValue(2) // <- this thread also executes *2 and +1

class MyMessage extends Exception

val p = new Promise[Int]
p.setInterruptHandler {
  case ex: MyMessage => println("Receive MyMessage")
}

val f = p.map(_ + 1).map(_ * 2)
f.raise(new MyMessage) // print "Receive MyMessage"