.NET lenguaje para programación simultánea

Question

Esta puede ser una pregunta que otros han visto, pero estoy tratando de encontrar un lenguaje diseñado para (o con soporte de idiomas para) programación simultánea que se pueda ejecutar en la plataforma .net.

He estado haciendo desarrollo lateral en erlang para tener una idea del idioma y me ha encantado lo fácil que es obtener un sistema estable simultáneo o incluso distribuido. Me llevó a Scala, que también tenía un buen sistema que utilizaba actores, sin embargo, Scala.net no parece tener esta funcionalidad actualmente (concede que se trata de un sistema concurrente frente a un sistema distribuido). Los dos lenguajes .net que estaba viendo son Axum y F #.

¿Son estas las únicas opciones que tengo? ¿Hay otros? Y, si son las únicas opciones, ¿cuáles son las ventajas/desventajas de cada uno?

Answer 1

Axum es un proyecto de investigación. Un proyecto de investigación real , donde solo ideas de él terminarán en productos. (A diferencia de F #, que se convirtió en un producto completo). Ni siquiera estoy seguro de que la licencia permita su uso para desarrollar aplicaciones de producción.

F # es una buena elección.

Clojure también se ejecuta en la CLI, y es una buena opción, también.

El puerto CLI de Scala está actualmente en proceso de resucitación (con financiación oficial de Microsoft, en realidad), y las bibliotecas Scala's Actor (ambas integradas, así como Akka) son bastante buenas.

En referencia al comentario de @ wmeyer anterior: Scala en sí no tiene ninguna disposición para la programación distribuida. (Tampoco lo hace Clojure). Ambos generalmente se basan en la miríada de frameworks Java que existen para ese propósito, como Terracotta. Sin embargo, Akka tiene tienen actores remotos para programación distribuida, y Akka es en gran medida compatible con API con la biblioteca incorporada Scala Actor, que permite una transición sin problemas.

Erlang sería genial. Kresten Krab Thorup está trabajando actualmente en Erjang, una implementación de Erlang en la JVM, y tiene algunos resultados bastante impresionantes: corriendo en HotSpot, Erjang escala de manera comparable a BEAM, a veces incluso mejor. Por ejemplo, en el (in) famoso benchmark de anillo de proceso con 10000 procesos, Erjang arranca solo un poco más lento que BEAM, pero cuando repites la carrera varias veces y el JIT entra, supera a BEAM después de aproximadamente 3 carreras (y curiosamente , BEAM comienza a desacelerarse después de 4 carreras).

Estoy bastante seguro de que podrías construir un "#rlang" en el DLR y el TPL que funciona igual de bien.

Answer 2

En realidad estoy usando F # para hacer programación concurrente y distribuida en este momento. Creo que está funcionando muy bien. Los tipos de unión facilitan la definición de mensajes tipificados estáticamente. La serialización de .NET es demasiado lenta para nosotros, pero reemplazarla con un analizador personalizado y unparser fue fácil y el rendimiento ahora es lo suficientemente bueno. Los flujos de trabajo asincrónicos y los procesadores de buzones hacen que sea más fácil pasar mensajes fácilmente. La inferencia tipo significa que toda mi base de códigos es pequeña y fácil de mantener.

Answer 3

Creo que Jörg ya respondió tu pregunta sobre Axum (y no sé mucho sobre ella), así que solo agregaré un par de cosas sobre F # - una cosa a tener en cuenta es que F # no es realmente un lenguaje concurrente. Solo tiene buenas bibliotecas para hacer un desarrollo paralelo.Las opciones más notables son:

• tareas de la Biblioteca paralelo y PLINQ que están disponibles en C# también, pero pueden parecer un poco más agradable en Fa #, especialmente si utiliza los tipos de datos inmutables. Hay algunos buenos ejemplos F # de usar estos dos en Parallel Programming with .NET y escribí un blog post sobre la versión F #.

• flujos de trabajo asincrónicos no son esencialmente diseñado para la programación concurrente - que le permiten escribir código no bloqueante en general (que es bastante útil en la programación concurrente) y que le permiten escribir los cálculos que se puede iniciar y administrado. Usted las puede utilizar para:

  • paralelismo basado en tareas (un poco como Parallel Library de tareas) usando StartChild método
  • cálculos de datos en paralelo usando Async.Parallel
    _
• programación basada en agentes utilizando el tipo MailboxProcessor desde F # le permite usar la simultaneidad de paso de mensajes que es bastante similar a Erlang. Se basa en flujos de trabajo asíncronos, lo que le brinda algunos beneficios (por ejemplo, esperar que un mensaje sea no bloqueante).

En resumen, creo que es más importante elegir el paralelo modelo de programación más adecuado para la tarea que el lenguaje utilizado para codificar que - siempre y cuando el idioma que da la energía suficiente para codificar la programación modelo. En este caso, el modelo de programación moldea tu mente más que el lenguaje. Axum se basa en el modelo de actor (transmisión de mensajes), así que creo que con cierto esfuerzo, podría envolver agentes F # para que se vean bastante similares a la API de Axum.

Answer 4

Desde .NET 4.5 puede usar C# async/await. Traté de explicar un hilo seguro, actor based design usando async/await. AsyncWcfLib está destinado a ayudar al crear sistemas concurrentes o distribuidos.