Diferentes implementaciones de Scala Actor Descripción

Question

Estoy tratando de encontrar la implementación del actor 'correcto'. Me di cuenta de que hay un montón de ellos y es un poco confuso elegir uno. Personalmente, estoy especialmente interesado en actores remotos, pero creo que una descripción completa sería útil para muchos otros. Esta es una pregunta bastante general, así que no dude en responder solo por la implementación que conoce.

Conozco las siguientes implementaciones de Scala Actor (SAI). Por favor agregue los que faltan.

• Scala 2,7 (diferencia a)
• Scala 2,8
• Akka (http://www.akkasource.org/)
• Lift (http://liftweb.net/)

• Scalaz (http://code.google.com/p/scalaz/)

  ---

• ¿Cuáles son los casos de uso objetivo para estas EFS (peso ligero frente al marco empresarial "pesado")

• ¿admiten actores remotos? ¿Qué deficiencias tienen los actores remotos en las EFS?
• ¿Cómo es su rendimiento?
• ¿Cuán activa es la comunidad?
• ¿Qué tan fáciles son para empezar? ¿Qué tan buena es la documentación?
• ¿Qué tan fácil es que se extiendan?
• ¿Qué tan estables son? ¿Qué proyectos los están usando?
• ¿Cuáles son sus deficiencias?
• ¿Cuáles son sus principios de diseño?
  • ¿Están basados ​​en hilos o en eventos (recibir/reaccionar) o en ambos?
  • anidada recibe
  • hotswapping bucle de mensajes del Actor

Answer 1

Por lo que yo sé, sólo Scala y Akka apoyar a los agentes remotos.

Akka está respaldado por soluciones escalables, que ofrecen soporte comercial y complementos para Akka. Akka parece una solución de peso pesado, que apunta a la integración con los marcos existentes (camel, AMQP, JTA, Comet, Spring, Redis) y STM y persistencia adicionales.

Akka comparado con Scala no es compatible con recepciones anidadas, pero admite hotswapping el bucle de mensajes de actores y tiene ambos actores basados ​​en hilos y eventos y los llamados "basados ​​en eventos de un solo hilo".

Answer 2

Scala 2.7.7. vs 2.8 después de The Scala 2.8.0 RC3 distribution:

Los nuevos reactores proporcionan actores más livianos y puramente basados ​​en eventos con identificación de remitente opcional e implícita. Se agregó soporte para actores con semántica estilo daemon. Los actores se pueden configurar para usar el grupo de unión/unión JSR166y eficiente, lo que resulta en mejoras de rendimiento significativas en 1.6 JVM. Los programadores ahora son conectables y más fáciles de personalizar.

También hay un documento de diseño de Haller: Scala Actors: Unifying Thread-based and Event-based Programming

Answer 3

me di cuenta de que hace cumplir akka partidos exhaustivos. Entonces, incluso si técnicamente receive espera una función parcial, la función no debe ser parcial. Esto significa que debe manejar cada mensaje de inmediato.

Answer 4

Ésta es la comparación más completa que he visto hasta ahora:

http://doc.akka.io/docs/misc/Comparison_between_4_actor_frameworks.pdf través http://klangism.tumblr.com/post/2497057136/all-actors-in-scala-compared

Answer 5

A partir del Scala 2.10, actores Scala es obsoleto y Actores Akka es ahora parte de la distribución estándar