Node.js o Erlang

86

Realmente me gustan estas herramientas cuando se trata del nivel de concurrencia que puede manejar.

Erlang / OTP parece una solución mucho más estable, pero requiere mucho más aprendizaje y mucha inmersión en el paradigma del lenguaje funcional. Y parece que Erlang / OTP lo hace mucho mejor cuando se trata de CPU multinúcleo (corríjame si me equivoco).

¿Pero cuál debería elegir? ¿Cuál es mejor a corto y largo plazo?

Mi objetivo es aprender una herramienta que facilite el escalado de mis proyectos web con mucha carga que los lenguajes tradicionales.

concurrency  erlang  multicore  node.js 
— user80805
fuente
Puede usar JavaScript como lenguaje funcional con underscorejs.org
— Todd Moses
2
@ToddMoses, ¿estás seguro de haber comentado la pregunta correcta?
— Flavien Volken
Manzanas y naranjas. Node.JS (en su esencia) es libevent (C) + interoperabilidad Javascript. Erlang es una implementación de IO totalmente personalizada. Node.JS está hecho para aplicaciones de un solo hilo. Tu delema es si quieres un trabajo en Facebook / Google, o quieres hacer un software de kickass.
— Vans S

Respuestas:

87

Le daría una oportunidad a Erlang. Aunque será una curva de aprendizaje más pronunciada, sacará más provecho ya que aprenderá un lenguaje de programación funcional. Además, dado que Erlang está diseñado específicamente para crear sistemas confiables y altamente concurrentes, aprenderá mucho sobre cómo crear servicios altamente escalables al mismo tiempo.

— Justin Ethier
fuente
10
No creo que Erlang sea un poco más complejo que Javascript. No hay ningún tipo de herencia en Erlang, por lo que siempre está seguro de a qué función llama. No hay conversión de tipos implícita en Erlang, por lo que siempre está seguro de qué tipos de datos utiliza. No hay una asignación destructiva, por lo que siempre está seguro de que no se romperá algún código antiguo porque algún código nuevo en la devolución de llamada cambió su estado interno.
— Dmitry Belyaev
51

No puedo hablar por Erlang, pero algunas cosas que no se han mencionado sobre node:

  • Node utiliza el motor V8 de Google para compilar javascript en código de máquina. Entonces, el nodo es bastante rápido. Eso se suma a los beneficios de velocidad que ofrece la programación basada en eventos y io sin bloqueo.
  • Node tiene una comunidad bastante activa. Súbete a su grupo de IRC en freenode y verás lo que quiero decir
  • He notado que los comentarios anteriores empujan a Erlang sobre la base de que será útil aprender un lenguaje de programación funcional. Si bien estoy de acuerdo en que es importante expandir sus habilidades y obtener una de ellas en su haber, no debe basar un proyecto en el hecho de que desea aprender un nuevo estilo de programación.
  • Por otro lado, Javascript ya está en un paradigma en el que te sientes cómodo escribiendo. Además, es javascript, por lo que cuando escribe el código del lado del cliente, se verá y se sentirá consistente.
  • ¡La comunidad de node ya ha lanzado toneladas de módulos ! Hay módulos para redis, mongodb, couch y lo que tengas. Otro buen módulo a considerar es Express (piense en Sinatra para nodo)

Mira el video en el blog de yahoo de Ryan Dahl, el tipo que realmente escribió node. Creo que eso le ayudará a tener una mejor idea de dónde se encuentra el nodo y hacia dónde se dirige.

Tenga en cuenta que el nodo aún se encuentra en las últimas etapas de desarrollo y, por lo tanto, ha sufrido bastantes cambios, cambios que han roto el código anterior. Sin embargo, supuestamente está en un punto en el que puede esperar que la API no cambie mucho más. Entonces, si está buscando algo divertido, diría que node es una excelente opción.

— Jarsen
fuente
26
Creo que el motor V8 compila JavaScript en código de máquina y no en ensamblaje.
— Jonas
10
Tener tanto trabajo realizado en torno a JavaScript no hace que el lenguaje sea ni siquiera un poco adecuado para resolver problemas complejos. El lenguaje en sí es terrible con todos esos casos especiales en la conversión de tipos. Y estilo de devolución de llamada donde las variables se cambian en cientos de lugares diferentes y al diablo con buscar el lugar donde se ha producido alguna asignación.
— Dmitry Belyaev
15

Soy un programador de Erlang desde hace mucho tiempo, y esta pregunta me llevó a echar un vistazo a node.js. Se ve muy bien.

Parece que necesita generar múltiples procesos para aprovechar múltiples núcleos. Sin embargo, no veo nada sobre la configuración de la afinidad del procesador. Puede usar el conjunto de tareas en Linux, pero probablemente debería estar parametrizado y configurado en el programa.

También noté que el soporte de la plataforma podría ser un poco más débil. Específicamente, parece que necesitaría ejecutar Cygwin para el soporte de Windows.

Aunque luce bien.

Editar

Node.js ahora tiene soporte nativo para Windows.

— dsmith
fuente
5
Esta respuesta es un poco antigua. En este momento, Node es multiplataforma, no es necesario tener Cygwin para Windows. Y Node tiene soporte integrado para la agrupación en clústeres en una máquina, compartiendo los sockets TCP.
— Farid Nouri Neshat
9

Estoy viendo las mismas dos alternativas que tienes, gotts, para múltiples proyectos.

Hasta ahora, la mejor maquinilla de afeitar que se me ocurrió para decidir entre ellas para un proyecto determinado es si necesito usar Javascript. Un sistema existente que estoy buscando migrar ya está escrito en Javascript, por lo que es probable que su próxima versión se realice en node.js. Otros proyectos se realizarán en algún marco web de Erlang porque no hay una base de código existente para migrar.

Otra consideración es que Erlang se escala mucho más allá de varios núcleos, se puede escalar a un centro de datos completo. No veo un mecanismo incorporado en node.js que me permita enviar un mensaje a otro proceso JS sin importar en qué máquina se encuentra, pero eso está integrado en Erlang en los niveles más bajos. Si su problema no es lo suficientemente grande como para necesitar varias máquinas o si no requiere varios procesos cooperativos, es probable que esta ventaja no importe, por lo que debe ignorarla.

Erlang es de hecho una piscina profunda en la que sumergirse. Sugeriría escribir un programa funcional independiente primero antes de comenzar a crear aplicaciones web. Un primer paso aún más fácil, ya que parece cómodo con Javascript, es intentar programar JS en un estilo más funcional. Si usa jQuery o Prototype, ya ha comenzado por este camino. Intente saltar entre programación funcional pura en Erlang o uno de sus parientes (Haskell, F #, Scala ...) y JS funcional.

Una vez que se sienta cómodo con la programación funcional, busque uno de los muchos marcos web de Erlang; probablemente no debería escribir su aplicación directamente en algo de bajo nivel como inetsen esta etapa tardía. Mire algo como el nitrógeno , por ejemplo.

— Warren Young
fuente
A menudo no se menciona que el punto "Erlang escala a un centro de datos completo" tiene algunas capturas muy importantes a considerar (la seguridad es una de las grandes). Consulte el capítulo sobre esto aquí: learnyousomeerlang.com/distribunomicon
— jocull
9

Aunque personalmente me decantaría por Erlang, admitiré que soy un poco parcial en contra de JavaScript. Mi consejo es que evalúes algunos puntos:

  1. ¿Está reutilizando código existente en cualquiera de esos lenguajes (tanto en términos de código fuente como de experiencia del programador?)
  2. ¿Necesita / desea actualizaciones sobre la marcha sin detener la aplicación? (Aquí es donde Erlang gana de forma predeterminada: su tiempo de ejecución fue diseñado para ese caso y OTP contiene todas las herramientas necesarias)
  3. ¿Qué tan grande es el tráfico esperado, en términos de operaciones simultáneas separadas, no de ancho de banda?
  4. ¿Qué tan "paralelas" son las operaciones que realiza para cada solicitud?

Erlang tiene un sistema distribuido paralelo transparente de red y simultaneidad realmente afinado. Dependiendo de qué es exactamente el proyecto, la disponibilidad de una implementación madura de dicho sistema podría superar cualquier problema relacionado con el aprendizaje de un nuevo idioma. También hay otros dos lenguajes que funcionan en Erlang VM y que puede utilizar, el Ruby / Python-like Reia y Lisp-Flavored Erlang .

Otra opción más es usar ambos, especialmente con Erlang que se usa como una especie de "hub". No estoy seguro de si Node.js tiene un sistema de interfaz de función externa, pero si lo tiene, Erlang tiene una biblioteca C para que los procesos externos interactúen con el sistema como cualquier otro proceso de Erlang.

— p_l
fuente
Según los documentos, Node.js puede aprovechar C y C ++ para complementos externos. nodejs.org/docs/v0.3.1/api/addons.html
— Evan Plaice
Parece que Reia ha muerto, pero en su lugar está el elixir ... me recuerda a Groovy y Java; aquí serían Elixir y Erlang.
— stommepoes
@EvanPlaice - Eso no me impresiona mucho. La cuestión es que, básicamente, estás codificando algo problemático en C ++ y lo agregas como elementos integrados. No es mucho de un FFI lo que está haciendo en realidad es extender el emulador. (Está bien, preferencia personal;)) La biblioteca externa mencionada en el caso de erlang es hacer procesos asíncronos en otros lenguajes que se muestran como nodos O que hablan sobre un puerto abierto (piense en una tubería bidireccional, con datos estructurados). Todo eso encaja muy bien en el modo de funcionamiento asincrónico. También hay NIF, que es esencialmente lo que tiene Node.js, pero no se recomiendan.
— p_l
1
@p_l Por lo que entiendo, el enfoque del nodo es ligeramente diferente. Si bien el nodo es muy bueno para manejar llamadas IO asincrónicas (es decir, solicitudes web), se ejecuta en un entorno de un solo subproceso. Por lo tanto, es excelente para despachar, pero no tan bueno para el procesamiento intensivo de CPU. Para cubrir ese terreno, puede bifurcar otro proceso / subproceso que ejecute código nativo C / C ++. Si todo lo que está haciendo son llamadas IO asíncronas (por ejemplo, IPC | tuberías bidireccionales), node.js debería poder manejar la carga. Siempre que no esté codificado para pasar mucho tiempo esperando llamadas sincrónicas.
— Evan Plaice
5

Parece que Erlang funciona mejor para la implementación en un servidor de gama relativamente baja (VM AMD de 512 MB y 4 núcleos a 2,4 GHz). Esto es de la experiencia de SyncPad al comparar las implementaciones de Erlang vs Node.js de su aplicación de servidor de pizarra virtual.

— adib
fuente
2
Sí, node.js parece estar teniendo un desagradable problema de pérdida de memoria. Node es bastante nuevo y experimental y ni JavaScript ni el motor V8 fueron diseñados para tales escenarios de servidor. Erlang, por otro lado, fue diseñado solo para eso de abajo hacia arriba y tuvo muchos años para refinarse y madurar.
— Rolf
2
Ese enlace parece muerto, pero aquí está en WayBackMachine web.archive.org/web/20120902014555/http://blog.mysyncpad.com/…
— jocull
4

Hay un idioma más en la misma VM que erlang -> Elixir

Es una alternativa muy interesante a Erlang, mira esta.

También tiene un marco web de rápido crecimiento basado en él-> Phoenix Framework

— NoDisplayName
fuente
0

Preferiré Erlang sobre Node. Si desea concurrencia, Node puede ser sustituido por Erlang o Golang debido a sus procesos livianos.

Erlang no es fácil de aprender, por lo que requiere mucho esfuerzo, pero su comunidad es activa, por lo que puede obtener ayuda de eso, esta es solo la razón por la que la gente prefiere Node.

— Sumit Pugalia
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.