Cuál es la respuesta de Haskell al Nodo.js?

Can Haskell proporciona algunos de los beneficios de Node.js, es decir, una solución limpia para evitar el bloqueo de E / S sin tener que recurrir a la programación multi-hilo?

Sí, de hecho los eventos y los hilos están unificados en Haskell.

• Puede programar en hilos ligeros explícitos (por ejemplo, millones de hilos en una sola computadora portátil).
• Or; puede programar en un estilo basado en eventos asíncronos, basado en notificaciones de eventos escalables.

Los hilos son en realidad se implementa en términos de eventos y se ejecuta en varios núcleos, con migración de subprocesos sin interrupciones, con rendimiento documentado y aplicaciones.

Por ejemplo, para

• masivamente orquestación concurrente de trabajos
• colecciones concurrentes escalado en 32 o 48 núcleos
• soporte de herramientas para perfilar y depurar programas multi-threaded/multi-event.
• alto rendimiento web basada en eventos servidores .
• usuarios interesantes: como el comercio de alta frecuencia.

Colecciones concurrentes nbody en 32 núcleos

En Haskell tienes tanto eventos como hilos, y como son todos los eventos bajo el capó.

Lea el documento que describe la implementación.

En primer lugar, no mantengo tu vista de ese nodo.js está haciendo lo correcto exponiendo todas esas devoluciones de llamada. Terminas escribiendo tu programa en CPS (continuation passing style) y creo que debería ser el trabajo del compilador hacer esa transformación.

Eventos: Sin manipulación de subprocesos, el programador solo proporciona devoluciones de llamada (como en Snap framework)

Así que con esto en mente, puedes escribir usando un estilo asíncrono si así lo deseas, pero al hacerlo te perderías escribir en un estilo síncrono eficiente, con un hilo por solicitud. Haskell es ridículamente eficiente en código síncrono, especialmente en comparación con otros lenguajes. Son todos eventos debajo.

Se garantiza que las devoluciones de llamada se ejecuten en un solo subproceso: no es posible ninguna condición de carrera.

Todavía podría tener una condición de carrera en el nodo.js, pero es más difícil.

Cada petición está en su propio hilo. Cuando escribes código que tiene que comunicarse con otros threads, es muy simple hacerlo threadsafe gracias a las primitivas de concurrencia de haskell.

API agradable y sencilla para UNIX. Bonus: Excelente soporte HTTP. DNS también disponible.

Echa un vistazo en hackage y compruébalo por ti mismo.

Cada E/S es por defecto asíncrona (esto puede ser molesto a veces, sin embargo). Esto hace que sea más fácil evitar las cerraduras. Sin embargo, demasiado procesamiento de CPU en una devolución de llamada afectará a otras conexiones (en este caso, la tarea debe dividirse en sub-tareas más pequeñas y re-programado).

Usted no tiene tales problemas, ghc distribuirá su trabajo entre los hilos del sistema operativo real.

El mismo lenguaje para el lado del cliente y el lado del servidor. (No veo demasiado valor en este, sin embargo. jQuery y Nodo.js comparte el modelo de programación de eventos, pero el resto es muy diferente. Simplemente no puedo ver cómo compartir código entre el lado del servidor y el lado del cliente podría ser útil en la práctica.)

Haskell no puede ganar aqui... ¿verdad? Piensa de nuevo, http://www.haskell.org/haskellwiki/Haskell_in_web_browser .

Todo esto empaquetado en un solo producto.

Descarga ghc, enciende la cábala. Hay un paquete para cada necesidad.

Personalmente veo Node.js y programación con callbacks como innecesariamente de bajo nivel y un poco antinatural cosa. ¿Por qué programar con callbacks cuando un buen tiempo de ejecución como el que se encuentra en GHC puede manejar callbacks para usted y hacerlo de manera bastante eficiente?

Mientras tanto, GHC runtime ha mejorado mucho: ahora cuenta con un "nuevo administrador de E / s" llamado MIO donde "M" significa multinúcleo, creo. Se basa en la base de IO manager existente y su objetivo principal es superar la causa de la degradación del rendimiento de más de 4 núcleos. Las cifras de rendimiento proporcionadas en este documento son bastante impresionantes. Mírate a ti mismo:

Con Mio, los servidores HTTP realistas en Haskell escalan a 20 núcleos de CPU, logrando un rendimiento máximo de hasta 6,5 veces en comparación con los mismos servidores que usaban versiones anteriores de GHC. La latencia de los servidores Haskell también se mejora: [...] bajo una carga moderada, reduce el tiempo de respuesta esperado en 5.7 x en comparación con versiones anteriores de GHC

Y:

También mostramos que con Mio, McNettle (un controlador SDN escrito en Haskell) puede escalar efectivamente a más de 40 núcleos, alcanzar un purasangre de más de 20 millones de nuevas solicitudes por segundo en una sola máquina, y por lo tanto convertirse en el más rápido de todos los controladores SDN existentes.

Mio ha llegado a la versión GHC 7.8.1. Personalmente veo esto como un gran paso adelante en la actuación de Haskell. Sería muy interesante comparar las aplicaciones web existentes rendimiento compilado por la versión anterior de GHC y 7.8.1.

La pregunta es bastante ridícula porque 1) Haskell ya ha resuelto este problema de una manera mucho mejor y 2) aproximadamente de la misma manera que Erlang. Aquí está el punto de referencia contra el nodo: http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-benchmarks

Dale a Haskell 4 núcleos y puede hacer 100k peticiones (simples) por segundo en una sola aplicación. Node no puede hacer tantas y no puede escalar una sola aplicación entre núcleos. Y no tienes que hacer nada para coseche esto porque el tiempo de ejecución de Haskell no es de bloqueo. El único otro lenguaje (relativamente común) que tiene IO sin bloqueo integrado en el tiempo de ejecución es Erlang.

Los eventos de IMHO son buenos, pero la programación mediante callbacks no lo es.

La mayoría de los problemas que hace especial la codificación y depuración de aplicaciones web proviene de lo que las hace escalables y flexibles. El más importante, la naturaleza sin estado de HTTP. Esto mejora la navegabilidad, pero esto impone una inversión de control donde el elemento IO (el servidor web en este caso) llama a diferentes controladores en el código de la aplicación. Este modelo de evento-o modelo de devolución de llamada, dicho con mayor precisión- es una pesadilla, ya que las devoluciones de llamada no comparten alcances variables, y se pierde una vista intuitiva de la navegación. Es muy difícil evitar todos los posibles cambios de estado cuando el usuario navega de ida y vuelta, entre otros problemas.

Se puede decir que los problemas son similares a la programación GUI donde el modelo de eventos funciona bien, pero las GUI no tienen navegación ni botón atrás. Eso multiplica las transiciones de estado posibles en aplicaciones web. El resultado del intento de resolver estos problemas son marcos pesados con configuraciones complicadas con muchos identificadores mágicos penetrantes sin cuestionar la raíz del problema: el modelo de devolución de llamada y su falta inherente de intercambio de alcances variables, y sin secuenciación, por lo que la secuencia debe construirse vinculando identificadores.

Existen frameworks basados en secuencias como ocsigen (ocaml) seaside (smalltalk) WASH (discontinued, Haskell) y mflow (Haskell) que resuelven el problema de la gestión estatal mientras mantenimiento de la navegabilidad y el DESCANSO. dentro de estos marcos, el programador puede expresar la navegación como una secuencia imperativa donde el programa envía páginas y espera respuestas en un solo hilo, las variables están en el alcance y el botón atrás funciona automáticamente. Esto produce inherentemente un código más corto, más seguro y más legible donde la navegación es claramente visible para el programador. (advertencia justa: Soy el desarrollador de mflow)

Al igual que nodejs ha eliminado libev el Snap Haskell Web Framework también ha eliminado libev.