Cette réponse reflète mon expérience d'utilisation d'Akka dans Scala et de ses types Actor et Future. Je ne me considère pas encore comme un expert, mais j'ai fait quelques systèmes utilisant ces bibliothèques et je sens que je commence à développer une idée de la façon de les utiliser.
Le choix d'utiliser un acteur par rapport à un futur concerne la nature de la concurrence dont vous avez besoin. Les contrats à terme se composent de façon monadique et dans des graphes structurés en DAG, ce qui rend certaines structures de calcul très élégantes. Mais ils ont des limitations sévères. Fondamentalement, le calcul qui est effectué simultanément dans un avenir doit être autonome (ou tout au plus référence uniquement état externe immuable) ou vous n'avez pas résolu le problème de l'interférence inter-thread avec tous les risques inhérents tels que l'impasse, conditions de course, comportement imprévisible ou corruption de structure de données. Lorsque votre calcul implique un état mutable de longue durée, un acteur encapsule celui qui empêche de manière sûre la corruption et les conditions de concurrence. D'un autre côté, les acteurs ne sont pas composables, mais ils fournissent beaucoup de flexibilité dans la façon dont vous construisez des réseaux de calculs en interaction. Cela n'est vrai que si vous ne limitez pas les réponses des acteurs à toujours et seulement en les envoyant (la réponse à une requête) à l'acteur à partir duquel la requête a été reçue. Si vous envoyez uniquement des réponses à l'acteur demandeur, vous êtes limité à un modèle d'interaction inter-acteur structuré en arborescence.
Dans n'importe quel système réel, non trivial, vous êtes très susceptible d'utiliser les deux formalismes, Future et Actor.