Aprendendo Erlang vs learning node.js [fechado]

Eu vejo muita porcaria on-line sobre como Erlang chuta a bunda do node.js. em quase todas as categorias possíveis. Então, eu gostaria de aprender Erlang e tentar, mas aqui está o problema. Estou descobrindo que tenho mais dificuldade em pegar Erlang do que em node.js. Com o node.js, eu podia escolher um projeto relativamente complexo e em um dia tinha algo funcionando. Com Erlang, estou enfrentando barreiras e não indo tão rápido.

Então .. para aqueles com mais experiência, Erlang é complicado de aprender, ou estou apenas perdendo alguma coisa? O Node.js pode não ser perfeito, mas parece que sou capaz de fazer as coisas com ele.

Antes de mais nada, concordo com a resposta de APENAS MINHA OPINIÃO correta sobre o aprendizado de Erlang. É uma linguagem principalmente funcional (embora a simultaneidade tenha um grande papel), e todos os seus recursos foram adicionados para oferecer tolerância a falhas e robustez, que não são exatamente os mesmos objetivos de design do Javascript.

Segundo, deixar o Node.js para entrar no Erlang é um pouco equivocado. O Node.js é um único servidor / estrutura que faz o possível para fazer tudo de maneira orientada a eventos com a ajuda de retornos de chamada. Erlang tem sua própria estrutura (OTP), mas não está no mesmo nível.

Se você planeja aprender Erlang, sugiro minha entrada no blog Uma carta aberta ao Erlang Beginner (ou espectador) como introdução à leitura antes de mergulhar nos tutoriais.

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

Primeiro de tudo, se você faz as coisas de uma maneira baseada em retorno de chamada, a única maneira de transmitir o estado é tê-lo global ou entrar na programação de estilo de passagem contínua. Em segundo lugar, você deve cuidar de toda a matriz de eventos. Um exemplo disso é que, se imaginarmos uma máquina de estados finitos muito simples: um semáforo mutex, orientado a eventos.

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

• O mutex é gratuito e você solicita a obtenção do bloqueio
• O mutex está bloqueado por outra pessoa e você deseja obter o bloqueio
• O mutex está bloqueado por si mesmo e você deseja liberar o mutex

Então você tem outros eventos a considerar, como tempo limite para evitar conflitos:

• O mutex foi bloqueado e você esperou por muito tempo, um cronômetro para desistir de disparar
• O mutex foi bloqueado e você esperou por muito tempo, obteve o bloqueio e o tempo limite disparou

Então você também tem os eventos fora dos limites:

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

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

• O mutex é gratuito e você solicita a obtenção do bloqueio
• O mutex está bloqueado por outra pessoa e você deseja obter o bloqueio
• O mutex está bloqueado por si mesmo e você deseja 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 'aguardar até que esteja livre', as mensagens são automaticamente enfileiradas: o trabalhador precisa aguardar 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, pedem que você seja muito inteligente na maneira como lida com eventos ou solicitam que você cuide de toda uma matriz de eventos complexa por completo, porque você precisa ser chamado de volta em cada caso inconseqüente resultante de problemas estranhos de tempo e alterações de estado.

Os recebimentos seletivos geralmente permitem que você se concentre apenas em um subgrupo de todos os eventos em potencial e que você raciocine com muito mais facilidade sobre os eventos nesse caso. Observe que Erlang tem um comportamento (padrão de design / implementação de estrutura) de algo chamado gen_event. A implementação gen_event permite que você tenha um mecanismo muito semelhante ao que está sendo usado no node.js, se é isso que você deseja.

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

Espero que isto ajude.

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

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

• Erlang é uma linguagem de programação funcional (principalmente). As linguagens de programação mais comuns são quase militantemente imperativas.
• O modelo de simultaneidade de Erlang é o modelo de ator. As linguagens de programação mais comuns usam threading baseado em bloqueio ou alguma forma de abordagem baseada em "reator" para simultaneidade. (Eu acho que o Node.js é o último, mas não me chame por ele - não tenho interesse em JavaScript em nenhum lado do relacionamento cliente / servidor.)
• O Erlang tem uma abordagem "deixe travar" para codificar com recursos de tempo de execução poderosos disponíveis para capturar essas falhas, diagnosticá-las e corrigi-las com o hotfix enquanto o sistema está sendo executado. As linguagens de programação mais comuns endossam um estilo de programação altamente defensivo.
• Erlang é quase, mas não completamente, indissociavelmente associado a uma biblioteca grande e levemente cerebral de arquiteturas comumente usadas para servidores confiáveis ​​e estáveis ​​(OTP). (Há uma razão pela qual Erlang é geralmente chamado de Erlang / OTP.) Além disso, essa biblioteca é construída sobre os recursos alienígenas mencionados anteriormente e, portanto, é opaca para os recém-chegados. A maioria das linguagens de programação possui bibliotecas menos abrangentes (apesar do Java EE) para trabalhar e as bibliotecas são, naturalmente, criadas com base em conceitos mais familiares à maioria dos programadores.

Portanto, 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, quando você ultrapassa a barreira conceitual, afirmo que a codificação Erlang será menos complexa do que a codificação equivalente do Node.js. Isto é por várias razões:

• O modelo de concorrência de Erlang torna o fluxo lógico muito mais claro do que a concorrência típica no estilo "reator" e torna a concorrência muito mais estável e correta do que a concorrência comum baseada em bloqueio. Não é quase nenhum problema para um programador Erlang descartar literalmente milhares de processos em um programa típico, ao mesmo tempo em que despeja milhares de encadeamentos, digamos, Java seria um pesadelo de contenção (sem mencionar a sobrecarga de memória e CPU envolvida) e o O equivalente a manter milhares de estados separados em uma configuração baseada em "reator" seria um pesadelo para ler.
• Sendo uma linguagem (principalmente) funcional, Erlang é muito uma configuração "o que você vê é o que obtém". As variáveis, uma vez definidas, não mudam. Sempre. Não há nenhuma "ação assustadora à distância" para confundir você: tudo o que você trabalha é explicitamente apresentado à 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 facilidades que Erlang possui para lidar com erros significa que você confunde seu código com uma programação menos defensiva, mantendo a lógica mais clara e o código pequeno.
• A biblioteca OTP, depois que você o grava, é uma pilha incrivelmente poderosa de código comum que mantém todo o aplicativo regular e cobre muitos dos problemas e casos de uso de servidores de longa duração que você provavelmente não pensará até que seja tarde demais. A biblioteca OTP em si é, IM (ns) HO, um motivo suficientemente bom para aprender Erlang.

Continue andando devagar em Erlang, se puder, e se ainda não o fez, visite Learn You Some Erlang for Great Good para uma introdução suave 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 muitos traços com idiomas com os quais mais pessoas estão familiarizadas, portanto, geralmente é muito mais fácil começar a trabalhar. Erlang tem uma sintaxe muitas vezes estranha e desconhecida para a maioria e, embora como uma linguagem seja muito mais simples que o javascript, é preciso um pouco mais para se acostumar devido à sua singularidade.

A segunda é que Erlang tem um modelo de simultaneidade de nada compartilhado muito particular, 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 de código aberto após o fato, há apenas 2 anos ou mais, para que as pessoas pudessem realmente ver commits individuais no controle de origem e, mesmo agora, não acho que todos os desenvolvedores do erlang tenham se mudado. ao repositório público do github por seu desenvolvimento. O node.js foi criado dentro da comunidade desde o início, isso significa que o suporte à comunidade é muito melhor, já há muito mais bibliotecas para o nó, mais documentação da comunidade, mais exemplos ao vivo, um onipresente gerenciador de pacotes etc. etc. Erlang está atualizando a este respeito, mas ainda é uma rampa muito maior para se levantar.

O Node permitirá que você programe rapidamente coisas divertidas e relativamente simples, mas ainda tem dores crescentes no que diz respeito a grandes aplicativos que erlang resolveram por um longo tempo. Erlang mudará a maneira como você programa e (imo) fará de você um programador melhor, no entanto, isso não facilitará sua vida no começo. Ambos são divertidos de maneiras diferentes.