Le mélange Erlang et Haskell

Question

Si vous avez acheté dans le paradigme de programmation fonctionnelle, les chances sont que vous aimez aussi bien Erlang et Haskell. Les deux ont des noyaux purement fonctionnels et d'autres bonté tels que des fils légers qui les rendent un bon moyen pour un monde multi-cœurs. Mais il y a quelques différences.

Erlang est un langage de tolérance aux pannes commercialement éprouvée avec un modèle de distribution mature. Il a une caractéristique apparemment unique dans sa capacité à mettre à jour sa version lors de l'exécution via le chargement de code à chaud. (Way cool!)

Haskell, sur le autrepart, a le système de type le plus sophistiqué d'une langue dominante. (Là où je définir le terme « mainstream » comme une langue qui a un livre O'Reilly publié alors Haskell compte.) Ses performances mono-thread straightline semble supérieure à celle Erlang et ses fils légers look encore plus léger aussi.

Je suis en train de mettre sur pied une plate-forme de développement pour le reste de ma vie de codage et je me demandais s'il était possible de mélanger Erlang et Haskell pour obtenir une meilleure plate-forme de la race. Cette question comporte deux parties:

1. Je voudrais utiliser Erlang comme une sorte de faute MPI tolérant à coller les instances d'exécution GHC ensemble. Il y aurait un processus Erlang par exécution GHC. Si « l'impossible est arrivé » et le moteur d'exécution GHC sont morts, alors le processus Erlang détecterait que d'une certaine manière et mourir aussi. chargement de code à chaud de Erlang et les caractéristiques de distribution seraient tout simplement continuer à travailler. Le moteur d'exécution GHC peut être configuré pour utiliser un seul noyau, ou tous les noyaux sur la machine locale, ou une combinaison quelconque entre les deux. Une fois que la bibliothèque Erlang a été écrit, le reste du code de niveau Erlang doit être purement et passe-partout généré automatiquement sur une base par application. (Peut-être par un DSL Haskell par exemple.) Comment peut-on atteindre au moins certaines de ces choses?
2. Je voudrais Erlang et Haskell pour pouvoir partager le même collecteur garabage. (Ceci est une idée beaucoup plus loin que 1.) Langues qui fonctionnent sur la machine virtuelle Java et le CLR permettent d'atteindre une plus grande masse en partageant une exécution. Je comprends qu'il ya des limites techniques à l'exécution Erlang (loading code à chaud) et Haskell (polymorphisme kinded supérieur) soit sur la machine virtuelle Java ou le CLR. Mais qu'en est-dégroupage juste le garbage collector? (Trier le début d'une exécution pour les langages fonctionnels.) La répartition se serait évidemment encore être vraiment rapide, alors peut-être que peu doit être lié statiquement. Et il devrait y avoir une certaine mechansim de distinguer le tas mutable du tas immuable ( démenés écriture différée une fois la mémoire) que les besoins GHC cela. Serait-il possible de modifier à la fois HIPE et GHC pour que les éboueurs pourraient partager un tas?

S'il vous plaît répondre à toutes les expériences (positives ou négatives), des idées ou des suggestions. En fait, tous les commentaires (à court d'abus droit!) Est la bienvenue.

Mise à jour

Merci pour les 4 réponses à ce jour -. Chacun m'a appris au moins une chose utile que je ne savais pas

En ce qui concerne le reste de codage vie chose - j'inclus légèrement la langue dans la joue de susciter le débat, mais il est en fait vrai. Il y a un projet que je pense que je l'intention de travailler jusqu'à ce que je meure, et il a besoin d'une plate-forme stable.

Dans la plate-forme que je propose ci-dessus, je n'écrire Haskell, comme boilerplate Erlang est automatiquement généré. Alors combien de temps va durer Haskell? Eh bien Lisp est toujours avec nous et ne ressemble pas à ça va disparaître de sitôt. Haskell est open source BSD3 et a atteint une masse critique. Si la programmation elle-même est toujours là dans 50 ans, je pense Haskell, ou une évolution continue de Haskell, sera toujours là.

Mise à jour 2 en réponse au poste de rvirding

D'accord - la mise en œuvre d'une complète « Erskell / Haslang » machine virtuelle universelle pourrait ne pas être tout à fait impossible, mais il serait certainement en effet très difficile. partage just le niveau de garbage collector comme quelque chose comme une machine virtuelle, tout en difficile , semble un ordre de grandeur moins difficile à moi si. Le modèle de collecte des ordures, les langages fonctionnels doivent avoir beaucoup en commun - la unbiquity des données immuables (y compris thunks) et l'exigence d'allocation très rapide. Donc, le fait que la standardisation est fourni étroitement avec les machines virtuelles monolithique semble assez étrange.

machines virtuelles n'aider à atteindre une masse critique. Il suffit de regarder comment les langages fonctionnels « Lite » comme F # et Scala ont décollé. Scala ne peut pas avoir la tolérance de faute absolue de Erlang, mais il offre une voie d'évacuation pour les très nombreuses personnes qui sont liées à la machine virtuelle Java.

  

Tout en ayant un tas de marques unique   un message qui passe très vite il   introduit un certain nombre d'autres problèmes,   surtout que faire GC devient plus   difficile car il doit être interactif   et globalement non interruptif de sorte que vous   ne peuvent pas utiliser les mêmes algorithmes plus simples   que le modèle de segment de mémoire par processus.

Absolument, cela fait sens pour moi. Les gens très intelligents sur l'équipe de développement GHC semblent essayer de résoudre une partie du problème avec un parallèle « arrêter le monde » GC.

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

(Il est évident que « arrêter le monde » ne volerait pas pour Erlang général compte tenu de son cas principal d'utilisation.) Mais même dans les cas d'utilisation où « arrêter le monde » est OK, leurs speedups ne semblent pas être universel. Donc, je suis d'accord avec vous, il est peu probable qu'il y ait une meilleure GC universellement, ce qui est la raison pour laquelle j'ai spécifié dans la partie 1. de ma question que

  

Le moteur d'exécution GHC peut être configuré pour   utiliser un seul noyau, ou tous les cœurs sur la   machine locale, ou une combinaison quelconque de   entre les deux.

De cette façon, pour un cas d'utilisation donnée, je pourrais, après l'étalonnage, choisir de suivre la voie Erlang, et exécuter une exécution GHC (avec un singlethreaded GC) plus un processus Erlang par cœur et laisser Erlang mémoire de copie entre les noyaux pour une bonne localité.

En variante, sur une machine à deux processeurs avec 4 coeurs par processeur avec une bonne bande passante de mémoire sur le processeur, l'étalonnage peut suggérer que je dirige une exécution GHC (avec un GC parallèle) plus un processus Erlang par processeur.

Dans les deux cas, si Erlang et GHC pourraient partager un tas, le partage serait probablement lié à un seul thread OS fonctionnant sur un noyau unique en quelque sorte. (Je reçois de ma profondeur ici, ce qui est la raison pour laquelle je posais la question.)

J'ai aussi un autre ordre du jour - l'analyse comparative des langages fonctionnels indépendamment du GC. Souvent, je lis des résultats des benchmarks de OCaml v GHC v Erlang v ... et je me demande dans quelle mesure les résultats sont faussées par les différents GCS. Que faire si le choix de GC pourrait être orthogonale à choix de langage fonctionnel? Quel est le coût GC de toute façon? Voir ce diable les défenseurs de blog

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

par mon ami John Lisp Fremlin, qu'il a, au charme, étant donné son titre de poste « collecte des ordures est automatisée des déchets ». Lorsque John affirme que GC est lent et n'a pas vraiment accéléré beaucoup, je voudrais être en mesure de contrer avec quelques chiffres.

Answer 1

Beaucoup de gens Haskell et Erlang sont intéressés par le modèle où Erlang supervise la distribution, alors que Haskell exécute les noeuds de mémoire partagée en parallèle font tout le nombre crissant / logique.

Un départ vers c'est la bibliothèque Haskell-Erlang: http://hackage.haskell.org/package / Erlang

Et nous avons des efforts similaires dans les terres Ruby, via Hubris: http://github.com/ mwotton / Hubris / arbre / maître

La question est maintenant de trouver quelqu'un pour pousser à travers le fait Erlang / Haskell Interop pour connaître les questions délicates.

Answer 2

Vous allez avoir un temps intéressant mélange entre GC Haskell et Erlang. Erlang utilise un tas et des copies de données entre les processus par processus - comme Haskell n'a même pas un concept de processus, je ne sais pas comment vous mapper ce GC « universel » entre les deux. De plus, pour une meilleure performance, Erlang utilise une variété de allocateurs, chacun des comportements légèrement retouchés que je suis sûr affecterait le sous-système de GC.

Comme toutes les choses dans le logiciel, l'abstraction a un coût. Dans ce cas, je pense plutôt que vous auriez à introduire tant de couches pour obtenir les deux langues sur leur différence d'impédance que vous auriez vent avec un pas très performant (ou utile) VM commun.

Bottom line - embrasser la différence! Il y a d'énormes avantages à ne pas courir tout dans le même processus, en particulier du point de vue de la fiabilité. En outre, je pense qu'il est un peu naïf d'attendre une langue / VM pour vous durer pour le reste de votre vie (sauf si vous prévoyez un.) Vivant un court laps de temps ou b.) Devenir une sorte de moine de code qui ne fonctionne que sur un seul projet). Le développement de logiciels est tout au sujet de l'agilité mentale et être prêt à utiliser les meilleurs outils disponibles pour établir le code rapide et fiable.

Answer 3

Bien que ce soit un fil assez vieux, si les lecteurs sont toujours intéressés alors il vaut la peine de jeter un oeil à Nuage Haskell , qui apporte et la distribution de la concurrence de style Erlang à l'écurie GHC.

La prochaine rel="nofollow"> bibliothèque ajoute le support pour OTP-esque constructions comme gen_servers, arbres de supervision et d'autres abstractions de "haskell aromatisés" empruntés et inspirés par Erlang / OTP.

Answer 4

1. Vous pouvez utiliser un processus de gen_supervisor OTP pour surveiller les cas Haskell que vous Spawn avec open_port (). Selon la façon dont le « port » est sorti, vous serez alors en mesure de le redémarrer ou décider qu'il est arrêté sur le but et laisser le processus Erlang correspondant mourir aussi.

2. Fugheddaboudit

   . Même ces machines virtuelles indépendant de la langue dont vous parlez ont du mal avec les données transmises entre les langues parfois. Vous devez juste sérialisation des données entre les deux en quelque sorte:. Base de données, XML-RPC, quelque chose comme ça

Par ailleurs, l'idée d'une plate-forme unique pour le reste de votre vie est probablement peu pratique, aussi. la technologie informatique et le changement de mode trop souvent attendre à ce que vous pouvez continuer à utiliser une seule langue pour toujours. Vos points très question ceci:. Aucune langue ne tout ce que nous pourrions souhaiter, même aujourd'hui

Answer 5

Comme dizzyd mentionné dans son commentaire ne sont pas toutes les données dans les messages sont copiées, les grands binaires existent en dehors des tas de processus et ne sont pas copiés.

En utilisant une structure de mémoire différente pour éviter d'avoir des tas séparés par processus est certainement possible et a été fait dans un certain nombre de réalisations antérieures. Tout en ayant un tas seul fait passer un message très rapide, il introduit un certain nombre d'autres problèmes, surtout que faire GC devient plus difficile car il doit être interactif et globalement non interruptif de sorte que vous ne pouvez pas utiliser mêmes algorithmes plus simples que le modèle de tas par processus.

Tant que nous utilisons ont des structures de données immuables il n'y a pas de problème de robustesse et de sécurité. Décider sur laquelle la mémoire et les modèles GC à utiliser est un gros compromis, et malheureusement il universellement meilleur modèle.

Alors que Haskell et Erlang sont les deux langages fonctionnels, ils sont à bien des égards des langues très différentes et mises en œuvre très différentes. Il serait difficile de trouver une machine « Erskell » (ou Haslang) qui pourrait gérer efficacement les deux langues. Personnellement, je pense qu'il est préférable de les garder séparés et assurez-vous que vous disposez d'une interface vraiment bien entre eux.

Answer 6

Le CLR prend en charge l'optimisation des appels de queue avec un explicite tail opcode (utilisé par F #), que la machine virtuelle Java n'a pas (encore) un équivalent, ce qui limite la mise en œuvre d'un tel style de langage. L'utilisation de AppDomains séparés ne permet le CLR au code échangeable à chaud (voir par exemple ce blog montrant comment il peut être fait).

Avec Simon Peyton Jones travaille juste dans le couloir de Don Syme et l'équipe F # chez Microsoft Research, ce serait une grande déception si nous ne l'avons pas à terme un IronHaskell avec une sorte de statut officiel. Un IronErlang serait un projet intéressant -. Le plus gros morceau de travail serait probablement le portage du planificateur vert de filetage sans obtenir que des poids lourds comme le moteur de workflow de Windows, ou d'avoir à exécuter une machine virtuelle BEAM sur le CLR