Learning Erlang vs learning node.js [cerrado]

Veo mucha basura en línea sobre cómo Erlang patea el culo de node.js en casi todas las categorías imaginables. Así que me gustaría aprender Erlang y probarlo, pero aquí está el problema. Estoy descubriendo que me resulta mucho más difícil recoger a Erlang que cuando recogí node.js. Con node.js, podría elegir un proyecto relativamente complejo, y en un día tenía algo funcionando. Con Erlang, me encuentro con barreras y no voy tan rápido.

Entonces, para aquellos con más experiencia, ¿es complicado aprender Erlang, o simplemente me estoy perdiendo algo? Puede que Node.js no sea perfecto, pero parece que puedo hacer las cosas con él.

En primer lugar, estoy de acuerdo con la respuesta de SÓLO MI OPINIÓN correcta sobre el aprendizaje de Erlang. Es un lenguaje principalmente funcional (aunque la simultaneidad juega un papel importante), y todas sus características se agregaron para ir hacia la tolerancia a fallas y la robustez, que no son exactamente los mismos objetivos de diseño que Javascript en primer lugar.

En segundo lugar, dejar Node.js para entrar en Erlang está un poco fuera de lugar. Node.js es un servidor / marco único que se encarga de hacer todo de una manera controlada por eventos con la ayuda de devoluciones de llamada. Erlang tiene su propio marco (OTP), pero no está en el mismo nivel en absoluto.

Si planeas aprender Erlang, te sugiero que ingreses a mi blog Una carta abierta para principiantes (o curiosos) de Erlang como lectura de introducción antes de sumergirte en los tutoriales.

Lo único en lo que puede comparar Erlang y Node.js, en términos de patrones y uso, es cómo están controlados por eventos. Sin embargo, hay dos grandes diferencias importantes aquí. El modelo de Node.js se basa en devoluciones de llamada vinculadas a eventos. Erlang se basa en colas de mensajes y recepciones selectivas. ¿Cuáles son las implicaciones allí?

En primer lugar, si hace las cosas de una manera basada en la devolución de llamada, la única forma de llevar el estado es tenerlo global o entrar en la programación de estilo de paso continuo. En segundo lugar, debe cuidar la matriz completa del evento usted mismo. Un ejemplo de esto es que si imaginamos una máquina de estados finitos muy simple: un semáforo mutex, controlado por eventos.

El semáforo mutex tiene dos estados: bloqueado y libre. Cada vez que una determinada unidad de cómputo (trabajador, proceso, función o subproceso) desea obtener acceso al mutex, tiene que activar un evento que le dice "Estoy interesado". Ahora debe preocuparse por los siguientes tipos de eventos:

• El mutex es gratis y usted solicita obtener la cerradura
• El mutex está bloqueado por otra persona y desea obtener el bloqueo
• El mutex está bloqueado por usted mismo y desea liberar el mutex

Luego, debe considerar eventos adicionales, como el tiempo de espera para evitar puntos muertos:

• El mutex ha sido bloqueado y esperó demasiado tiempo, un temporizador para abandonar los incendios
• El mutex se ha bloqueado y usted esperó demasiado tiempo, obtuvo el bloqueo y luego se activó el tiempo de espera

Entonces también tienes los eventos fuera de límite:

• acabas de bloquear el mutex mientras algún trabajador esperaba que fuera gratis. Ahora la consulta de ese trabajador tiene que estar en cola para que cuando esté libre se maneje
• Necesita hacer todo el trabajo asincrónico

La matriz de eventos se vuelve compleja muy rápido. Nuestro FSM aquí solo tiene 2 estados. En el caso de Erlang (o cualquier idioma con recepción selectiva y sincronización con eventos potencialmente sincrónicos), debe preocuparse por algunos casos:

• El mutex es gratis y usted solicita obtener la cerradura
• El mutex está bloqueado por otra persona y desea obtener el bloqueo
• El mutex está bloqueado por usted mismo y desea liberar el mutex

Y eso es. Los temporizadores se manejan en los mismos casos en que se reciben, y para todo lo que tenga que ver con 'esperar hasta que esté libre', los mensajes se ponen en cola automáticamente: el trabajador solo tiene que esperar una respuesta. El modelo es mucho, mucho más simple en estos casos.

Esto significa que, en casos generales, CPS y modelos basados ​​en devolución de llamada como el de node.js le piden que sea muy inteligente en la forma en que maneja los eventos, o le piden que se ocupe de una matriz de eventos completa completa, porque debe volver a llamar en cada caso intrascendente que resulte de problemas de tiempo extraños y cambios de estado.

Las recepciones selectivas generalmente le permiten concentrarse solo en un subgrupo de todos los eventos potenciales y le permiten razonar con mucha más facilidad sobre los eventos en ese caso. Tenga en cuenta que Erlang tiene un comportamiento (patrón de diseño / implementación de marco) de algo llamado gen_event. La implementación gen_event le permite tener un mecanismo muy similar al que se usa en node.js si eso es lo que desea.

Habrá otros puntos que los diferenciarán; Erlang tiene una programación preventiva, mientras que node.js lo hace cooperativo, Erlang es más apto para algunas aplicaciones a gran escala (distribución y todo), pero Node.js y su comunidad suelen ser más aptos y conocedores de la última tendencia web. Se trata de elegir la mejor herramienta, y esto dependerá de sus antecedentes, su tipo de problema y sus preferencias. En mi caso, el modelo de Erlang se ajusta muy bien a mi forma de pensar. Este no es necesariamente el caso para todos.

Espero que esto ayude.

Erlang no es complicado de aprender, es ajeno a la mentalidad que las cámaras constantes (99.44%) de los programadores han aprendido a medida que funciona la programación. El problema que enfrenta es probable que sea solo una desorientación conceptual en lugar de una complejidad real.

Estas son algunas de las características alienígenas de Erlang que van a morder a un programador típico:

• Erlang es un lenguaje de programación (en su mayoría) funcional. Los lenguajes de programación más comunes son casi militantemente imperativos.
• El modelo de concurrencia de Erlang es el modelo de actor. Los lenguajes de programación más comunes usan subprocesos basados ​​en bloqueos o alguna forma de enfoque de concurrencia basado en "reactores". (Creo que Node.js es lo último, pero no me llame, no tengo ningún interés en JavaScript en ningún lado de la relación cliente / servidor).
• Erlang tiene un enfoque de "dejar que se bloquee" para la codificación con potentes funciones de tiempo de ejecución disponibles para detectar estos bloqueos, diagnosticarlos y aplicar parches mientras el sistema está en funcionamiento. Los lenguajes de programación más comunes respaldan un estilo de programación fuertemente defensivo.
• Erlang está casi, pero no del todo, inextricablemente emparejado con una biblioteca grande y ligeramente retorcida de arquitecturas de uso común para servidores confiables y estables (OTP). (Hay una razón por la cual Erlang se conoce típicamente como Erlang / OTP). Además, esta biblioteca se basa en las características extrañas mencionadas anteriormente y, por lo tanto, es opaca para los recién llegados. La mayoría de los lenguajes de programación tienen menos bibliotecas que lo abarquen todo (a pesar de Java EE) para trabajar y dichas bibliotecas, naturalmente, se basan en conceptos que son más familiares para la mayoría de los programadores.

Por lo tanto, aprender Erlang será más difícil para la mayoría de los programadores que aprender Node.js, especialmente si el programador ya está familiarizado con JavaScript. Al final, sin embargo, una vez que supere la barrera conceptual, afirmo que la codificación de Erlang será menos compleja que la codificación equivalente de Node.js. Esto es por varias razones:

• El modelo de concurrencia de Erlang hace que la lógica fluya mucho más clara que la concurrencia típica de "reactor" y hace que la concurrencia sea mucho más estable y correcta que la concurrencia basada en bloqueo típica. Casi no hay ningún problema para que un programador de Erlang deje caer literalmente miles de procesos en un programa típico mientras deja caer miles de hilos en, digamos, Java sería una pesadilla de contención (sin mencionar la sobrecarga de memoria y CPU involucrada) y el equivalente a mantener miles de estados separados en una configuración basada en "reactor" sería una pesadilla de leer.
• Al ser un lenguaje funcional (en su mayoría), Erlang es en gran medida una configuración de "lo que ves es lo que obtienes". Las variables, una vez establecidas, no cambian. Siempre. No hay una "acción espeluznante a distancia" de OOP que lo confunda: cualquier cosa con la que trabaje se presenta explícitamente frente a usted. No hay variables heredadas de X y no hay variables de clase de Y y no hay variables globales de Z para preocuparse. (Este último punto no es 100% cierto, pero es cierto en un número tan abrumador de casos que es lo suficientemente bueno para su fase de aprendizaje).
• Las poderosas instalaciones que Erlang tiene para manejar errores significa que abarrota su código con una programación menos defensiva, manteniendo así la lógica más clara y manteniendo el código pequeño.
• La biblioteca OTP, una vez que la asimila, es una pila increíblemente poderosa de código común que mantiene su aplicación completa regularmente y cubre muchos de los problemas y casos de uso de servidores de larga duración que probablemente no pensará hasta que sea demasiado tarde. La biblioteca OTP en sí es, IM (ns) HO, una razón suficiente para aprender Erlang.

Si puedes, sigue trabajando en Erlang, y si aún no lo has hecho, visita Learn You Some Erlang for Great Good para una introducción suave y (sobre todo) divertida de los conceptos de Erlang.

Hay algunas diferencias significativas entre Erlang y Node

El primero es que ese nodo es Javascript, lo que significa que es un lenguaje muy común que comparte muchos rasgos con idiomas con los que más personas están familiarizadas, por lo que generalmente es mucho más fácil ponerlo en funcionamiento. Erlang tiene una sintaxis a menudo extraña y desconocida para la mayoría, y aunque el lenguaje es mucho más simple que JavaScript, lleva un poco más acostumbrarse debido a su singularidad.

La segunda es que Erlang tiene un modelo de concurrencia de nada compartido muy particular, requiere que pienses de una manera diferente para resolver problemas, lo cual es algo bueno (TM)

El último importante es que Erlang fue desarrollado por una empresa comercial y de código abierto después del hecho, fue solo hace 2 años más o menos para que las personas pudieran ver los compromisos individuales en el control de fuente e incluso ahora no creo que todos los desarrolladores de erlang se hayan movido al público github repo por su desarrollo. node.js se creó dentro de la comunidad desde el principio, esto significa que su soporte comunitario es mucho mejor, ya hay muchas más bibliotecas para el nodo, más documentación de la comunidad, más ejemplos en vivo, un administrador de paquetes ubicuo, etc. Erlang se está poniendo al día en este sentido, pero todavía es una rampa mucho más grande para levantarse.

Node te permitirá programar cosas divertidas bastante rápido y relativamente indoloro, todavía tiene dolores de crecimiento con respecto a las grandes aplicaciones que Erlang ha resuelto durante mucho tiempo. Erlang cambiará la forma en que programa y (imo) lo convertirá en un mejor programador, sin embargo, al principio no le facilitará la vida. Ambos son divertidos de diferentes maneras.