Quelle est la réponse à Haskell Node.js?

Question

Je crois que la communauté Erlang n'est pas jaloux de Node.js comme il le fait non-blocage I/S en mode natif et a les moyens de déploiements à grande échelle facilement à plus d'un processeur (quelque chose de pas encore intégré dans Node.js). Plus de détails à http://journal.dedasys.com/2010/04/29/erlang-vs-node-js et http://stackoverflow.com/questions/3011317/node-js-or-erlang

Qu'en Haskell? Peut Haskell fournir quelques-uns des avantages de Node.js, à savoir une solution propre pour éviter le blocage de I/O sans avoir recours à la multi-thread de programmation?

Mise à JOUR:

Il y a beaucoup de choses qui attirent avec Node.js

1. Événements: Pas de fil de manipulation, le programmeur fournit seulement des rappels (comme dans le composant logiciel Enfichable cadre)
2. Les rappels sont garantis pour être exécuté dans un thread unique: pas de condition de course possible.
3. Agréable et simple UNIX-amicale de l'API. Bonus: Excellente prise en charge de HTTP. DNS également disponibles.
4. Tous les I/O est en asynchrone par défaut (ce qui peut être gênant parfois, tout de même). De ce fait, il est plus facile d'éviter les verrous. Cependant, trop de traitement de l'UC dans un rappel aura un impact sur les autres connexions (dans ce cas, la tâche doit diviser en plus petits sous-tâches et re-programmée).
5. Même langage côté client et côté serveur. (Je ne vois pas trop la valeur de celui-ci, cependant. JQuery et Node.js partager l'événement de programmation de modèle, mais le reste est très différent. Je ne peux pas voir comment le partage de code entre côté serveur et côté client pourrait être utile dans la pratique.)
6. Tout cela emballé dans un seul produit.

Answer 1

Ok, donc après avoir vu un peu de la node.js la présentation que @gawi m'a indiqué, je peux dire un peu plus sur la façon dont Haskell compare à node.js. Dans la présentation, Ryan a décrit certaines des prestations de Fils Verts, mais continue ensuite en disant qu'il ne trouve pas le manque d'un fil d'abstraction pour être un inconvénient. Je serais en désaccord avec sa position, en particulier dans le contexte de Haskell: je pense que les abstractions que les threads sont indispensables pour faire serveur de code plus facile à obtenir le droit, et plus robuste. En particulier:

• en utilisant un thread par connexion vous permet d'écrire du code qui exprime la communication avec un client unique, plutôt que d'écrire du code qui traite de tous les clients en même temps. Pensez-y comme ça: un serveur qui gère plusieurs clients avec des fils ressemble presque le même que celui qui traite d'un seul client; la principale différence est qu'il y a un fork quelque part dans l'ancien. Si le protocole que vous êtes à la mise en œuvre est complexe, la gestion de l'état de la machine pour plusieurs clients simultanément devient assez difficile, alors que les threads laissez-vous juste un script pour la communication avec un client unique. Le code est plus facile à obtenir le droit, et plus facile à comprendre et à maintenir.

• rappels sur un OS unique thread est multitâche coopératif, par opposition à un mode multitâche préemptif, qui est ce que vous obtenez avec les threads. Le principal inconvénient avec le multitâche coopératif, c'est que le programmeur est responsable de s'assurer qu'il n'y a pas de famine. Il perd la modularité: faire une erreur dans un seul endroit, et il peut gâcher l'ensemble du système. C'est vraiment quelque chose que vous ne voulez pas avoir à vous soucier de, et de préemption est la solution la plus simple. De plus, la communication entre les rappels n'est pas possible (deadlock).

• la simultanéité n'est pas difficile en Haskell, parce que la plupart du code est pur et donc est thread-safe par construction. Il y a une communication simple et primitives. Il est beaucoup plus difficile de se tirer dans le pied avec de la simultanéité dans Haskell que dans une langue sans restriction d'effets secondaires.

Answer 2

Peut Haskell fournir quelques-uns des avantages de Node.js, à savoir une solution propre pour éviter le blocage de I/O sans avoir recours à la multi-thread de programmation?

Oui, en fait, les événements et les threads sont unifiés en Haskell.

• Vous pouvez programmer dans explicite léger threads (par exemple, des millions de threads sur un seul ordinateur portable).
• Ou, vous pouvez programmer dans un async event-driven style évolutif de notification d'événement.

Les Threads sont effectivement mises en œuvre en termes d'événements, et de courir sur plusieurs cœurs, sans fil la migration, à des performances et des applications.

E. g. pour

• massivement de travail simultanés orchestration
• les collections simultanées de mise à l'échelle sur 32 ou 48 cœurs
• le support de l'outil de profilage et de débogage multithread/multi-programmes des événements.
• haute performance event-driven web serveurs.
• intéressant utilisateurs: comme le trading à haute fréquence.

Les collections simultanées nbody sur 32 cœurs

En Haskell vous avez à la fois des événements et des fils, et comme il est de tous les événements sous le capot.

Lire le document décrivant la mise en œuvre.

Answer 3

Tout d'abord, je ne retenez pas votre point de vue que node.js est en train de faire la bonne chose exposant l'ensemble de ces rappels. Vous finissez par écrire votre programme de CPS (continuation passing style) et je pense qu'il devrait être le compilateur du travail à faire cette transformation.

Événements: Pas de fil de manipulation, le programmeur fournit seulement des rappels (comme dans le composant logiciel Enfichable cadre)

Donc, avec cela à l'esprit, vous pouvez écrire à l'aide d'un asynchrones style si vous le souhaitez, mais ce faisant, vous manquerez de l'écriture efficace synchrone de style, avec un thread par demande. Haskell est ridiculement efficace au code synchrone, surtout lorsqu'on les compare à d'autres langues. Il est de tous les événements en dessous.

Les rappels sont garantis pour être exécuté dans un thread unique: pas de condition de course possible.

Vous pourriez quand même avoir une condition de concurrence dans node.js mais c'est plus difficile.

Chaque demande est dans son propre thread. Lorsque vous écrivez du code qui doit communiquer avec d'autres threads, il est très simple de faire des threads grâce à haskell simultanéité de primitives.

Agréable et simple UNIX-amicale de l'API. Bonus: Excellente prise en charge de HTTP. DNS également disponibles.

Prendre un coup d'oeil dans le hackage et de voir par vous-même.

Tous les I/O est en asynchrone par défaut (ce qui peut être gênant parfois, tout de même). De ce fait, il est plus facile d'éviter les verrous. Cependant, trop de traitement de l'UC dans un rappel aura un impact sur les autres connexions (dans ce cas, la tâche doit diviser en plus petits sous-tâches et re-programmée).

Vous n'avez pas de tels problèmes, ghc allez distribuer votre travail parmi les vrais OS de threads.

Même langage côté client et côté serveur. (Je ne vois pas trop la valeur de celui-ci, cependant. JQuery et Node.js partager l'événement de programmation de modèle, mais le reste est très différent. Je ne peux pas voir comment le partage de code entre côté serveur et côté client pourrait être utile dans la pratique.)

Haskell ne peut pas gagner ici... droit? Détrompez-vous, http://www.haskell.org/haskellwiki/Haskell_in_web_browser .

Tout cela emballé dans un seul produit.

Télécharger ghc, feu de la cabale. Il y a un paquet pour chaque besoin.

Answer 4

Personnellement, je vois Node.js et de la programmation avec des rappels inutilement de bas niveau et un peu chose naturelle. Pourquoi le programme avec des rappels quand une bonne exécution tel que celui trouvé dans GHC peut gérer des rappels pour vous et le faire assez efficacement?

Dans l'intervalle, GHC exécution s'est grandement améliorée: il dispose désormais d'un "nouveau nouveau gestionnaire d'e / s" appelle MIO où "M" est synonyme de multicœur je crois. Il s'appuie sur la fondation de l'existant gestionnaire d'e / s et son principal objectif est de surmonter la cause de 4+ carottes de dégradation des performances. Les chiffres de la Performance fournis dans ce document sont assez impressionnants. Voyez vous-même:

Avec Mio, réaliste HTTP serveurs en Haskell échelle à 20 cœurs du PROCESSEUR, la réalisation de performances de pointe jusqu'à facteur de 6,5 x par rapport à la même serveurs à l'aide de versions antérieures de GHC. Le temps de latence de Haskell serveurs est également améliorée: sous une charge modérée, réduit prévu des temps de réponse de 5,7 x en comparaison avec les versions précédentes de GHC

Et:

Nous montrons également que Mio, McNettle (un contrôleur SDN écrit en Haskell) peut évoluer efficacement à 40+ carottes de, atteindre un thoroughput de plus de 20 millions de nouvelles requêtes par seconde sur une seule machine, et donc de devenir le plus rapide de tous les contrôleurs SDN.

Mio devrait le faire dans GHC 7.8.1 la libération. Personnellement, je vois cela comme une étape importante vers l'avant en Haskell performance. Il serait très intéressant de comparer les applications web existantes performances fonctionnant sur courant GHC et un nouveau.

Answer 5

À mon humble avis, les événements sont bonnes, mais la programmation par le biais de rappels n'est pas.

La plupart des problèmes qui le rend spécial, le codage et le débogage d'applications web vient de ce qui les rend souple et évolutive. Le plus important, les apatrides de la nature de HTTP. Cela améliore la navigabilité, mais cela impose une inversion de contrôle où l'OI élément (le serveur web, dans ce cas) appel des gestionnaires différents dans le code de l'application. Ce modèle d'événement -ou modèle de rappel, plus exactement, dit - est un cauchemar, car les rappels ne partagent pas variable étendues, et une vue intuitive de la navigation est perdu. Il est très difficile de prévenir tous les possibles modifications de l'état lorsque l'utilisateur de naviguer d'avant en arrière, parmi d'autres problèmes.

On peut dire que les problèmes sont similaires à la programmation GUI où l'événement est un modèle qui fonctionne très bien, mais les Interfaces graphiques ont pas de navigation et pas de bouton de retour. Qui multiplie les transitions d'état possible dans les applications web. Le résultat de la tentative de résoudre ces problème sont lourds cadres avec des configurations compliquées beaucoup de magie omniprésente identifiants sans remettre en cause la racine du problème: le modèle de rappel et de son manque inhérent de partage de variable étendues, et pas de séquençage, de sorte que la séquence doit être construit en reliant les identificateurs.

Il y a séquentielle en fonction des frameworks comme ocsigen (ocaml) bord de mer (smalltalk) LAVER (abandonnées, Haskell) et mflow (Haskell) qui permettent de résoudre le problème de la gestion de l'état, tandis que le maintien de la navigabilité de REPOS et de plénitude. dans ces cadres, le programmeur peut exprimer la navigation comme un impératif de la séquence où le programme de l'envoi des pages et d'attendre les réponses dans un seul thread, les variables sont dans le champ d'application et le bouton de retour fonctionne automatiquement. Ce produit intrinsèquement des plus courtes, plus fort, plus lisible le code où la navigation est clairement visible pour le programmeur. (avertissement: je suis le développeur de mflow)