Hola!
Hace más de dos años venimos trabajando en diferentes tipos de proyectos haciendo uso de Akka/JVM/Scala. A la fecha hemos entregado exitosamente 14 proyectos de tamaño medio a grande, pasando por webapps, automatizaciones de procesos de laga duración, sistemas de autenticación y autorización, service registries, aplicaciones core de negocio, entre otros ejemplos.
En la mayoría de ellos hemos tenido que resolver problemas a través de la construcción de patrones para sistemas distribuidos: convergencia de estado a través de CvRDT, quórum a través de RAFT (hecho en casa), jitter y exponential backoff en el consumo de servicios, implementación de sagas para soportar transacciones de larga duración o no tan simples esquemas de recuperación ante catástrofes sobre distintos IaaS.
Lo que quiero tratar de decir con esta introducción es que calcular pi, o cualquier otro problema algorítmico es lo menos común de los problemas en los que hemos elegido Akka para resolverlos. De hecho, en las pruebas que hicimos de Erlang se quedó corto en la oferta de herramientas/toolkits/librerías para resolver este tipo de problemas.
Estoy seguro que Erlang ofrece un desempeño superior a Akka en el procesamiento sobre CPU o creación de hilos o context swaping de hilos. Pero hace mucho, pero mucho tiempo, que ese dejó de ser para nosotros el único criterio de selección o de evaluación de una tecnología. Por esa razón considero que un problema algorítmico no sería un escenario de prueba adecuado.
Por otro lado, está Elixir que es un lenguaje funcional con tipado dinámico. De entrada, para nuestro criterio, el tipado dinámico es una fuerte debilidad dado que muchas de las habilidades de FP sobre las que construímos nuestras aplicaciones se fundamentan en phantom typing, structural types y path dependent types con el propósito de que el compilador trabaje para nosotros en la verificación formal de los comportamientos que desarrollamos. Para eso necesitamos un lenguaje de tipado fuerte. Al final del día buscamos en lo posible lograr, eventualmente, lo que Idris es capaz de hacer hoy.
Por el lado del lenguaje a través del cual usamos Akka, hoy en día es muy importante el desarrollo de librerías y comportamientos a través dela implementación de elementos de la teoría de categorías. Afortunadamente en Scala existen dos librerías maduras y probadas en producción para este fin.
Con esta explicación busco sustentar el hecho de que si se compara Erlang contra Akka, no podemos limitarnos al modelo de actores pues, en nuestro caso, las razones por las cuales concluimos que para nosotros era mejor Akka/Scala/JVM fueron lenguaje, ecosistema, facilidad de construcción de sistemas distribuidos y verificabilidad de correctitud del código escrito.
¿Qué opinan?
muy cierto @yujikiriki, el toolset que existe (y lo nuevo que se esta cocinando) alrededor de la JVM es simplemente genial