source software open mfs funds haskell erlang

software - Haskell por un servidor?



wiki open source (8)

Es mucho más fácil introducir fugas de memoria en su aplicación Haskell debido a la pereza. Los servidores de larga ejecución son precisamente el tipo de programas en los que realmente no desea tener pérdidas de memoria.

Aunque estoy de acuerdo en que Haskell es un lenguaje más sólido y más agradable para programar, Erlang es mucho más fácil y tiene muchas bibliotecas específicamente diseñadas para este tipo de aplicaciones.

No creo que haya un equivalente de Haskell para, digamos, Mnesia, y escribir será difícil. Puede escribir las versiones de Haskell de gen_server , gen_event , etc., pero no se habrán optimizado ni ajustado durante más de una década.

Con respecto a la creación de un servidor de juegos, parece que Erlang siempre aparece como un lenguaje "creado para este tipo de cosas" con sus características de escalabilidad y simultaneidad. No tengo experiencia ni en Haskell ni en Erlang, pero en la superficie parecen lo mismo. Al examinar los documentos de Haskell, parece que tiene soporte para la escalabilidad y concurrencia de multiprocesadores, y se dice que Haskell es un lenguaje más sólido y tiene una comunidad visiblemente mejor. Mi pregunta es, entonces, ¿Haskell es una solución tan buena para la construcción de servidores como supuestamente es Erlang?

Estoy seguro de que puedes encontrar personas que piensen así, pero creo que te equivocas acerca de la capacidad de Erlang para admitir este tipo de uso; es ampliamente utilizado en aplicaciones de telefonía, y en realidad es bastante robusto. Erlang está muy optimizado para servidores de concurrencia altamente confiables y altos.

La última vez que miré, las bibliotecas y los marcos para construir servidores escalables en Erlang parecían un poco más maduros que los de Haskell. Sugiero consultar Programming Erlang: Software for a Concurrent World para obtener información sobre ellos.

La cuestión de si Haskell es tan bueno como Erlang depende de lo que las personas quieran de un idioma. Creo que a ambos les iría bastante bien como servidor de juegos, pero depende principalmente de lo que desee o espere de un lenguaje de programación. Una de las diferencias más fáciles de notar es que Haskell es un lenguaje estáticamente tipado con inferencia de tipo, y Erlang es un lenguaje de tipado dinámico. En general, diría que Haskell requiere un poco más de "sofisticación" para aquellos que no están acostumbrados a la programación funcional.

No tengo experiencia ni en Haskell ni en Erlang, pero en la superficie parecen lo mismo.

Hay algunas diferencias bastante marcadas entre Haskell y Erlang. Erlang está específicamente diseñado para sistemas concurrentes. El lenguaje y la máquina virtual están diseñados para admitir muchos, muchos procesos, y Erlang usa un sistema estilo actor para administrar la comunicación entre todos ellos. Haskell también admite la concurrencia con bastante facilidad, debido a su naturaleza funcional, pero aún es un poco más difícil hacer una programación concurrente en Haskell, y el lenguaje no está específicamente configurado para facilitar esto.

Al igual que Haskell, Erlang no comparte estado entre procesos, por lo que es fácil escribir software multiproceso. Pero el estilo de programación entre Haskell y Erlang es un poco diferente, ya que Erlang enfatiza el uso de procesos pequeños para realizar un procesamiento simultáneo.

Me encanta Haskell, es uno de mis idiomas favoritos, pero si fuera a escribir software de servidor, probablemente usaría Erlang. Pero ciertamente es posible escribir un servidor en Haskell, si conoces mejor a Haskell o si encuentras que el soporte de la biblioteca es superior.

Depende de lo que quieras hacer con tu servidor. Como podría esperarse de una aplicación de telecomunicaciones, Erlang se destaca en tareas simples con concurrencia muy alta . Si su servidor necesita miles de conexiones por segundo, o inmediatamente, Erlang es su amigo. Erlang también ofrece un mejor soporte para la distribución de carga en múltiples servidores.

Haskell se destaca en computación simbólica compleja y, a partir de abril de 2009, también puede manejar una gran cantidad de hilos (ver la actualización a continuación). Además, Haskell tiene más herramientas para obtener código complicado correctamente : cosas como QuickCheck , SmallCheck y el sistema de tipo estático. Entonces, si su servidor está haciendo cosas complicadas e interesantes y puede funcionar con un solo servidor, probablemente esté mejor con Haskell.

Actualización 13 de abril de 2009 : Don Stewart, una fuente confiable, informa que "el último error de escala de subprocesos en el compilador Haskell de Glasgow fue eliminado hace unos meses", y que algunos usuarios informan haber usado un millón de subprocesos Haskell sin problemas. A partir de enero de 2009, hay un nuevo documento inédito de los implementadores que puede describir cómo se logra esto.

Actualización 21 de febrero de 2012 : la empresa de John Hughes, QuviQ , ahora hace QuickCheck para Erlang. Han encontrado una serie de errores muy interesantes. Puede descargar "QuickCheck Mini" de forma gratuita; es comparable al Haskell QuickCheck. También hay una versión comercial más poderosa.