Mezclar Erlang y Haskell

Question

Si usted ha comprado en el paradigma de programación funcional, lo más probable es que te gusta tanto Erlang y Haskell. Ambos tienen núcleos puramente funcionales y otra bondad como hilos ligeros que los hacen una buena opción para un mundo de múltiples núcleos hacen. Sin embargo, hay algunas diferencias.

Erlang es un lenguaje tolerante a fallos demostrado comercialmente con un modelo de distribución madura. Tiene una característica aparentemente único en su capacidad de actualizar su versión en tiempo de ejecución a través de la carga de código caliente. (Manera fresca!)

Haskell, en el otherhand, tiene el sistema de tipos sofisticados mayor parte de cualquier lenguaje corriente principal. (Cuando defino 'corriente principal' para ser cualquier lenguaje que tiene un libro publicado hasta O'Reilly recuento de Haskell.) Su recta sola actuación roscado parece superior a la de Erlang y sus hilos ligeros se vea aún más ligero también.

Estoy tratando de armar una plataforma de desarrollo para el resto de mi vida de codificación y se preguntaba si era posible mezclar Erlang y Haskell para lograr una mejor plataforma de raza. Esta pregunta tiene dos partes:

1. Me gustaría usar Erlang como una especie de culpa MPI tolerantes a pegar instancias de tiempo de ejecución de GHC juntos. Habría un proceso de Erlang por GHC tiempo de ejecución. Si "sucedió lo imposible" y el tiempo de ejecución GHC murieron, entonces el proceso de Erlang detectaría que de alguna manera y morir también. características de carga y distribución de código caliente de Erlang se acaba de seguir trabajando. El tiempo de ejecución GHC podría estar configurado para utilizar un solo núcleo, o todos los núcleos en la máquina local, o cualquier combinación entre ellos. Una vez que la biblioteca de Erlang fue escrito, el resto del código de nivel de Erlang debe ser puramente repetitivo y genera automáticamente en función de cada aplicación. (Tal vez por un DSL Haskell por ejemplo.) ¿Cómo se puede lograr por lo menos algunas de estas cosas?
2. Me gustaría Erlang y Haskell sean capaces de compartir el mismo colector garabage. (Esta es una idea por otra parte mucho que 1.) Idiomas que se ejecutan en la JVM y CLR alcanzan una mayor densidad por compartir un tiempo de ejecución. Entiendo que hay limitaciones técnicas a la ejecución de Erlang (código caliente de carga) y Haskell (mayor polimorfismo kinded) ya sea en la JVM o el CLR. Pero ¿qué pasa con la desagregación sólo el recolector de basura? (Algo así el inicio de un tiempo de ejecución de los lenguajes funcionales.) La asignación sería, evidentemente, todavía tiene que ser muy rápido, así que tal vez que las necesidades de bits a ser enlazados estáticamente. Y debe haber una cierta mechansim distinguir el montón mutable del montón inmutable ( incuding escritura diferida una vez que la memoria) como GHC necesita esto. ¿Sería factible modificar tanto EAFI y GHC para que los recolectores de basura podrían compartir un montón?

Por favor, conteste con alguna experiencia (positivos o negativos), ideas o sugerencias. De hecho, cualquier voto (por debajo de abuso recta!) Es bienvenida.

Actualizar

Gracias por todas las respuestas hasta la fecha 4 -. Me enseñaron cada uno al menos una cosa útil que no sabía

En cuanto a el resto de la vida de codificación cosa - que incluyó un poco en broma a debate chispa, pero en realidad es cierto. Hay un proyecto que tengo en cuenta que tengo la intención de trabajar en hasta que muera, y necesita una plataforma estable.

En la plataforma he propuesto anteriormente, sólo escribiría Haskell, ya que el texto modelo de Erlang se genera automáticamente. ¿Cuánto tiempo va a Haskell pasado? Así Lisp todavía está con nosotros y no se ve como que va a desaparecer pronto. Haskell es BSD3 de código abierto y ha alcanzado una masa crítica. Si la programación en sí es todavía alrededor dentro de 50 años, esperaría Haskell, o alguna evolución continua de Haskell, todavía estaré aquí.

Actualización 2 en respuesta al mensaje de rvirding

De acuerdo - la implementación de un "Erskell / Haslang" máquina virtual completa universal, puede que no sea absolutamente imposible, pero sin duda sería muy difícil. compartir just nivel recolector de basura como algo parecido a una máquina virtual, sin dejar de difícil , suena un orden de magnitud menos difícil a mí, sin embargo. En el modelo de recolección de basura, los lenguajes funcionales deben tener mucho en común - el unbiquity de datos inmutables (incluyendo procesadores) y el requisito para la asignación muy rápido. Por lo que el hecho de que en común se incluye firmemente con monolítica máquinas virtuales parece un poco raro.

VM no ayuda a alcanzar la masa crítica. Basta con mirar cómo los lenguajes funcionales 'lite' como F # y Scala han despegado. Scala puede no tener la tolerancia a fallos absoluta de Erlang, pero ofrece una vía de escape para conseguir las muchas personas que están vinculadas a la JVM.

  

Mientras que tiene un único marcas montón   el paso de mensajes es muy rápido   introduce una serie de otros problemas,   principalmente, que se vuelve más haciendo GC   difícil ya que tiene que ser interactivo   y en el mundo no interruptiva por lo que   no puede utilizar los mismos algoritmos más simples   como el modelo de montón por proceso.

Por supuesto, eso tiene mucho sentido para mí. Las personas muy inteligentes en el equipo de desarrollo GHC parecen estar tratando de resolver parte del problema con un paralelo "parar el mundo" GC.

http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf

(Obviamente "parar el mundo" no volaría de Erlang general dada su caso de uso principal.) Pero incluso en los casos de uso donde "parar el mundo" está bien, sus aceleraciones no parecen ser universales. Así que estoy de acuerdo contigo, es poco probable que haya una mejor universalmente GC, que es la razón por la que se especifica en la parte 1. de mi pregunta que

  

El tiempo de ejecución GHC podría estar configurado para   utilizar un solo núcleo, o todos los núcleos en la   máquina local, o cualquier combinación de   entre.

De este modo, para un caso de uso dado, podría, después de la evaluación comparativa, optar por seguir el camino de Erlang, y ejecutar una ejecución GHC (con un GC singlethreaded) más un proceso de Erlang por núcleo y dejar que la memoria copia Erlang entre los núcleos para una buena localidad.

Alternativamente, en una máquina de procesador dual con 4 núcleos por procesador con ancho de banda de memoria bien en el procesador, la evaluación comparativa podría sugerir que corro un tiempo de ejecución GHC (con un GC paralelo) más un proceso de Erlang por procesador.

En ambos casos, si Erlang y GHC podrían compartir un montón, la puesta en común probablemente se une a una sola hebra de OS en ejecución en un solo núcleo de alguna manera. (Me estoy fuera de mi profundidad aquí, y por eso hice la pregunta.)

También tengo otra agenda - la evaluación comparativa de los lenguajes funcionales independientemente de la GC. A menudo leo de los resultados de los puntos de referencia de OCaml v GHC v v ... Erlang y maravilla la cantidad de los resultados son confundidos por los diferentes GC. ¿Qué pasa si la elección de GC podría ser ortogonal a la elección del lenguaje funcional? ¿Qué tan caro es GC de todos modos? Ver este post defensores del diablo del blog

http://john.freml.in/garbage-collection-harmful

por mi amigo Lisp John Fremlin, que tiene, con mucho encanto, dado su título de la entrada "recogida automatizada de la basura es basura". Cuando John reclamaciones que GC es lento y realmente no se ha acelerado mucho, me gustaría ser capaz de contrarrestar con algunos números.

Answer 1

Mucha gente Haskell y Erlang está interesado en el modelo donde la distribución de Erlang supervisa, mientras Haskell ejecuta los nodos de memoria compartida en paralelo haciendo todo el procesamiento de números / lógica.

Un comienzo hacia esta es la biblioteca de Haskell-Erlang: http://hackage.haskell.org/package / erlang

Y tenemos esfuerzos similares en Ruby tierra, a través de Hubris: http://github.com/ mwotton / Hubris / árbol / maestro

La pregunta ahora es encontrar a alguien que realmente empujar a través de la interoperabilidad Erlang / Haskell para averiguar las cuestiones difíciles.

Answer 2

Vas a tener una mezcla de GC entre Haskell y Erlang momento interesante. Erlang usa un montón y copia por proceso de datos entre procesos - como Haskell no tiene ni siquiera un concepto de procesos, no estoy seguro de cómo le gustaría asignar este GC "universal" entre los dos. Por otra parte, para un mejor rendimiento, Erlang usa una variedad de asignadores, cada uno con comportamientos ligeramente modificado que estoy seguro que afectaría a la sub-sistema de GC.

Al igual que con todas las cosas en el software, la abstracción tiene un costo. En este caso, sospecho que lo tienes que introducir tantas capas para conseguir los dos idiomas más de su falta de concordancia que acabaría con un buen calidad no (o útil) VM común.

En pocas palabras - abrazar la diferencia! Hay enormes ventajas para que no se ejecuta todo en el mismo proceso, en particular desde el punto de vista de fiabilidad. Además, creo que es un poco ingenuo esperar que viven poco tiempo, o b.) Se convierta en una especie de monje código de una lengua / VM para durar por el resto de su vida (a menos que piense en una.) Que funciona sólo en una proyecto individual). El desarrollo de software es todo acerca de la agilidad mental y estar dispuesto a utilizar las mejores herramientas disponibles para construir rápido, fiable código.

Answer 3

A pesar de que este es un hilo bastante viejo, si los lectores todavía está interesado entonces vale la pena echar un vistazo a Nube Haskell , que trae concurrencia estilo Erlang y distribución al establo GHC.

La próxima biblioteca -proceso-plataforma distribuida añade soporte para OTP-esque construcciones como gen_servers, árboles de supervisión y varios otros "Haskell sabor" abstracciones tomados de e inspirados por Erlang / OTP.

Answer 4

1. Se podría utilizar un proceso de gen_supervisor OTP para monitorear casos Haskell que desovan con open_port (). Dependiendo de cómo salió del "puerto", usted entonces podrá reiniciarlo o decidir que se detuvo a propósito y dejar que el correspondiente proceso de Erlang mueren, también.

2. fugheddaboudit. Incluso éstas máquinas virtuales independiente del lenguaje que hablan de tener problemas con los datos transmitidos entre lenguas veces. Usted debe serializar los datos simplemente entre los dos alguna manera:. La base de datos, XML-RPC, algo por el estilo

Por cierto, la idea de una plataforma única para el resto de su vida es probablemente poco práctico, también. De las tecnologías informáticas y el cambio de la moda con demasiada frecuencia puede esperar que se pueden seguir usando un solo idioma para siempre. Su misma pregunta señala esto:. Nadie es el idioma que todo lo que podría desear, incluso hoy en día

Answer 5

Como dizzyd mencionó en su comentario no todos los datos de los mensajes se copian, existen grandes binarios fuera de los montones de proceso y no se copian.

Uso de una estructura de memoria diferente para evitar tener montones-de proceso por separado es ciertamente posible y se ha hecho en un número de implementaciones anteriores. Si bien tener una sola pila hace que el paso de mensajes muy rápido que introduce una serie de otros problemas, sobre todo que al hacerlo GC se hace más difícil, ya que tiene que ser interactivo y global no interruptiva por lo que no puede utilizar el mismos algoritmos más simples como el modelo de montón por proceso.

Mientras que el uso tienen estructuras de datos inmutables no hay ningún problema con la robustez y seguridad. La decisión sobre qué modelos de memoria y GC para su uso es una gran disyuntiva, y por desgracia no universalmente mejor modelo.

Mientras Haskell y Erlang son ambos lenguajes funcionales que son en muchos aspectos muy diferentes idiomas y tienen muy diferentes implementaciones. Sería difícil llegar a una máquina "Erskell" (o Haslang) que podría manejar ambos idiomas de manera eficiente. Yo personalmente creo que es mucho mejor mantenerlos separados y para asegurarse de que tiene una muy buena interfaz entre ellos.

Answer 6

La optimización de atención admite CLR cola con un código de operación explícita tail (como el usado por F #), que la JVM no (todavía) tiene un equivalente, lo que limita la aplicación de un estilo de lenguaje tales. El uso de AppDomains separados hace permitir que el CLR al código de intercambio en caliente (véase, por ejemplo esta entrada del blog que muestra cómo se puede hacer).

Con Simon Peyton Jones de trabajo justo en el pasillo de Don Syme y el equipo de F # en Microsoft Research, sería una gran decepción si no nos vemos, finalmente, un IronHaskell con algún tipo de estatus oficial. Un IronErlang sería un proyecto interesante -. La mayor parte del trabajo probablemente sería portar el planificador verde-threading sin conseguir tan pesado como el motor de flujo de trabajo de Windows, o tener que ejecutar un haz VM en la parte superior del CLR