Aprendendo Erlang vs aprendendo node.js [closed]

Primeiro de tudo, eu concordo com a resposta de Just my correct OPINION sobre a aprendizagem de Erlang. É uma linguagem predominantemente funcional (embora a simultaneidade desempenhe um grande papel), e todos os seus recursos foram adicionados para ir para tolerância a falhas e robustez, o que não é exatamente o mesmo objetivo de design do Javascript em primeiro lugar.

Em segundo lugar, deixar o Node.js entrar em Erlang é um pouco fora de lugar. O Node.js é um único servidor / framework que faz tudo de maneira orientada a eventos com a ajuda de retornos de chamada. Erlang tem seu próprio framework (OTP), mas não está no mesmo nível.

Se você planeja aprender Erlang, sugiro que meu blog An Carta Aberta para o Erlang Beginner (ou espectador) como introdução antes de mergulhar em tutoriais.

A única coisa que você pode comparar Erlang e Node.js, em termos de padrões e uso, é como eles são orientados a eventos. No entanto, existem duas grandes diferenças principais aqui. O modelo do Node.js é baseado em retornos de chamada associados a eventos. Erlang é baseado em filas de mensagens e recebimentos seletivos. Quais são as implicações aí?

Primeiro de tudo, se você fizer as coisas de uma maneira baseada em retorno de chamada, a única maneira de levar o estado em volta é torná-lo global ou entrar em programação de estilo de continuação. Em segundo lugar, você tem que cuidar da matriz completa do evento. Um exemplo disso é que, se imaginarmos uma máquina de estados finita muito simples: um semáforo mutex, orientado a eventos.

O semáforo mutex tem dois estados: bloqueado e livre. Sempre que uma determinada unidade de cálculo (trabalhador, processo, função ou thread) deseja obter acesso ao mutex, ele precisa disparar um evento que diz "Estou interessado". Agora você precisa cuidar dos seguintes tipos de eventos:

• O mutex é gratuito e você pede para obter o bloqueio
• O mutex é bloqueado por outra pessoa e você deseja obter o bloqueio
• O mutex está bloqueado por você e você quer liberar o mutex

Depois, você tem outros eventos a serem considerados, como tempo limite para evitar conflitos:

• O mutex foi bloqueado e você esperou por muito tempo, um timer para desistir de incêndios
• O mutex foi bloqueado e você esperou por muito tempo, obteve o bloqueio e, em seguida, o tempo limite foi desativado

Então você também tem os eventos fora do limite:

• você acabou de bloquear o mutex enquanto algum trabalhador esperava que ele fosse gratuito. Agora, a consulta desse trabalhador precisa ser enfileirada para que, quando estiver livre, ele seja tratado
• Você precisa tornar todo o trabalho assíncrono

A matriz de eventos se torna complexa muito rapidamente. Nosso FSM aqui tem apenas 2 estados. No caso de Erlang (ou qualquer idioma com recebimento seletivo e assíncrono com eventos potencialmente sincronizados), você precisa se preocupar com alguns casos:

• O mutex é gratuito e você pede para obter o bloqueio
• O mutex é bloqueado por outra pessoa e você deseja obter o bloqueio
• O mutex está bloqueado por você e você quer liberar o mutex

E é isso. Os cronômetros são manipulados nos mesmos casos em que os recebimentos são feitos, e para qualquer coisa que tenha a ver com 'espera até que esteja livre', as mensagens são automaticamente enfileiradas: o trabalhador só precisa esperar por uma resposta. O modelo é muito, muito mais simples nesses casos.

Isso significa que, em casos gerais, o CPS e os modelos baseados em retorno de chamada, como o do node.js, solicitam que você seja muito inteligente em como lidar com eventos ou peça a você que cuide de toda uma matriz complexa de eventos. cheio, porque você tem que ser chamado de volta em cada caso inconseqüente que resulta de problemas de tempo estranhos e mudanças de estado.

Recebimentos seletivos geralmente permitem que você se concentre apenas em um subgrupo de todos os possíveis eventos e permita que você raciocine com muito mais facilidade sobre os eventos nesse caso. Note que o Erlang tem um comportamento (design pattern / framework implementation) de algo chamado gen_event . A implementação gen_event permite que você tenha um mecanismo muito semelhante ao que está sendo usado em node.js, se é isso que você quer.

Haverá outros pontos que os diferenciam; Erlang tem agendamento preventivo, enquanto node.js torna cooperativo, Erlang é mais apto a alguns aplicativos de grande escala (distribuição e todos), mas o Node.js e sua comunidade geralmente são mais aptos à web e conhecedores da última tendência da web. É uma questão de escolher a melhor ferramenta, e isso dependerá do seu histórico, do tipo de problema e das suas preferências. No meu caso, o modelo de Erlang se encaixa muito bem na minha maneira de pensar. Isso não é necessariamente o caso de todos.

Espero que isso ajude.

    

Erlang não é complicado de aprender, é apenas estranho à mentalidade que o Chambers Constant (99.44%) dos codificadores aprendeu como funciona a programação. O problema que você está enfrentando provavelmente é apenas uma desorientação conceitual, e não uma complexidade real.

Aqui estão algumas das características alienígenas do Erlang que vão morder um programador típico:

• Erlang é uma linguagem de programação (principalmente) funcional. As linguagens de programação mais comuns são quase militantemente imperativas.
• O modelo de concorrência de Erlang é o modelo de ator. As linguagens de programação mais comuns usam o encadeamento baseado em bloqueio ou alguma forma de abordagem baseada em reatores para a simultaneidade. (Eu acho que o Node.js é o último, mas não me chame - eu tenho zero interesse em JavaScript em qualquer lado do relacionamento cliente / servidor.)
• A Erlang tem uma abordagem de "deixar funcionar" para codificação com poderosos recursos de tempo de execução disponíveis para detectar essas falhas, diagnosticá-las e atualizá-las enquanto o sistema está em execução. As linguagens de programação mais comuns endossam um estilo de programação altamente defensivo.
• O Erlang é quase, mas não completamente, associado ininterruptamente a uma grande biblioteca de arquiteturas comumente usadas para servidores estáveis e confiáveis (OTP). (Existe uma razão pela qual o Erlang é tipicamente referido como Erlang / OTP). Além disso, esta biblioteca é construída sobre as características alienígenas mencionadas anteriormente e é, portanto, opaca para os recém-chegados. A maioria das linguagens de programação tem bibliotecas menos abrangentes (não obstante o Java EE) para trabalhar e as ditas bibliotecas são, naturalmente, construídas em conceitos que são mais familiares para a maioria dos programadores.

Assim, aprender Erlang será mais um desafio para a maioria dos programadores do que aprender Node.js - especialmente se o programador já estiver familiarizado com JavaScript. No final, no entanto, depois de ultrapassar a barreira conceitual, afirmo que a codificação Erlang será menos complexa do que a codificação Node.js equivalente. Isto é por várias razões:

O modelo de simultaneidade de Erlang torna o fluxo lógico muito mais claro do que a concorrência típica de "reator" e torna a simultaneidade muito mais estável e correta do que a concorrência típica baseada em bloqueio. Não é quase nenhum problema para um programador Erlang derrubar literalmente milhares de processos em um programa típico enquanto o uso de milhares de threads em Java, digamos, seria um pesadelo de contenção (para não mencionar a memória e sobrecarga de CPU envolvida) e o equivalente de manter milhares de estados separados em uma configuração baseada em "reatores" seria um pesadelo para se ler.
• Sendo uma linguagem (principalmente) funcional, Erlang é uma configuração "o que você vê é o que obtém". Variáveis, uma vez definidas, não mudam. Sempre. Não há nenhum OOP "ação assustadora à distância" para confundir você: qualquer coisa com a qual você trabalha é explicitamente colocada à sua frente. Não há variáveis herdadas de X e nenhuma variável de classe de Y e nenhuma variável global de Z para se preocupar. (Este último ponto não é 100% verdadeiro, mas é verdade em um número tão grande de casos que é bom o suficiente para a sua fase de aprendizado.)
• As poderosas instalações que a Erlang tem para lidar com erros significa que você sobrecarrega seu código com uma programação menos defensiva, mantendo assim a lógica mais clara e mantendo o código pequeno.
• A biblioteca OTP, uma vez que você a grava, é uma pilha insanamente poderosa de código comum que mantém todo o seu aplicativo regular e cobre muitos dos problemas e casos de uso de servidores antigos que você provavelmente não pensará até que seja muito tarde. A biblioteca OTP em si é, IM (ns) HO uma razão boa o suficiente para aprender Erlang.

Continue se arrastando em Erlang se puder, e se ainda não o fez, visite Aprenda um pouco de Erlang para o bem para uma introdução gentil e (principalmente-) engraçada aos conceitos de Erlang.

    

Existem algumas diferenças significativas entre Erlang e Node

O primeiro é que o nó é Javascript, o que significa que é uma linguagem muito comum que compartilha muitas características com idiomas com os quais mais pessoas estão familiarizadas, por isso geralmente é muito mais fácil colocá-las em funcionamento. Erlang tem uma sintaxe muitas vezes estranha e desconhecida para a maioria, e embora como uma linguagem é muito mais simples que o javascript, demora um pouco mais para se acostumar devido à sua singularidade

A segunda é que Erlang tem um modelo muito particular de compartilhamento de concorrência, requer que você pense de uma maneira diferente para resolver problemas, o que é uma coisa boa (TM)

O último importante é que o Erlang foi desenvolvido por uma empresa comercial e aberto após o fato, foi há apenas 2 anos atrás que as pessoas puderam realmente ver commits individuais no controle de origem e até agora eu não acho que todos os erlang os desenvolvedores mudaram para o repositório público do github para seu desenvolvimento. node.js foi construído dentro da comunidade desde o início, isso significa que seu suporte à comunidade é muito melhor, já existem muito mais bibliotecas para nó, mais documentação da comunidade, mais exemplos vivos, um gerenciador de pacotes onipresente etc. Erlang está recuperando a este respeito, mas ainda é uma rampa muito maior para se levantar.

O Node permitirá que você programe coisas divertidas com rapidez e relativamente sem problemas, mas ainda tem dificuldades em relação a aplicativos grandes que foram solucionados por um longo tempo. Erlang vai mudar a maneira de programar e (imo) torná-lo um programador melhor, no entanto, não vai facilitar a vida para você no começo. Ambos são divertidos de maneiras diferentes.