Learning Erlang vs learning node.js [chiuso]

Vedo molte cazzate online su come Erlang prende a calci il culo di node.js in quasi ogni categoria immaginabile. Quindi mi piacerebbe imparare Erlang e dargli una possibilità, ma ecco il problema. Sto scoprendo che ho un tempo molto più difficile a raccogliere Erlang di quanto abbia fatto a raccogliere node.js. Con node.js, ho potuto scegliere un progetto relativamente complesso, e in un giorno ho avuto qualcosa che funzionava. Con Erlang, mi imbatto in barriere e non vado altrettanto veloce.

Quindi ... per quelli con più esperienza, Erlang è complicato da imparare o mi sto perdendo qualcosa? Node.js potrebbe non essere perfetto, ma mi sembra di riuscire a farcela.

Prima di tutto, sono d'accordo con SOLO LA MIA OPINIONE corretta sulla risposta all'apprendimento di Erlang. È un linguaggio prevalentemente funzionale (sebbene la concorrenza giochi un ruolo importante) e tutte le sue caratteristiche sono state aggiunte per andare verso la tolleranza agli errori e la robustezza, che non è esattamente gli stessi obiettivi di progettazione di Javascript in primo luogo.

In secondo luogo, lasciare Node.js per entrare in Erlang è un po 'fuori luogo. Node.js è un singolo server / framework che fa tutto il possibile per fare tutto in modo guidato dagli eventi con l'aiuto di callback. Erlang ha il suo framework (OTP), ma non è affatto allo stesso livello.

Se hai intenzione di imparare Erlang, suggerisco il mio post di blog Una lettera aperta al principiante di Erlang (o spettatore) come lettura introduttiva prima di immergersi nei tutorial.

L'unica cosa in cui puoi confrontare Erlang e Node.js, in termini di modelli e utilizzo è il modo in cui sono guidati dagli eventi. Tuttavia, ci sono due grandi differenze qui. Il modello di Node.js si basa sui callback associati agli eventi. Erlang si basa sulle code dei messaggi e sulla ricezione selettiva. Quali sono le implicazioni lì dentro?

Prima di tutto, se fai le cose in un modo basato sulla richiamata, l'unico modo per portare lo stato in giro è quello di averlo globale o entrare nella programmazione di stile di passaggio di continuazione. In secondo luogo, devi occuparti tu stesso della matrice completa degli eventi. Un esempio di ciò è che se immaginiamo una macchina a stati finiti molto semplice: un semaforo mutex, guidato da eventi.

Il semaforo mutex ha due stati: bloccato e libero. Ogni volta che una determinata unità di calcolo (lavoratore, processo, funzione o thread) desidera accedere al mutex, deve generare un evento che gli dice "Sono interessato". Ora devi occuparti dei seguenti tipi di eventi:

• Il mutex è gratuito e chiedi di ottenere il blocco
• Il mutex è bloccato da qualcun altro e si desidera ottenere il blocco
• Il mutex è bloccato da solo e si desidera liberare il mutex

Quindi hai altri eventi da considerare, come il timeout per evitare deadlock:

• Il mutex è stato bloccato e hai aspettato troppo a lungo, un timer per smettere di sparare
• Il mutex è stato bloccato e hai aspettato troppo a lungo, ottenuto il blocco, quindi il timeout è stato attivato

Quindi hai anche gli eventi fuori limite:

• hai appena bloccato il mutex mentre un lavoratore si aspettava che fosse libero. Ora la query di quel lavoratore deve essere messa in coda in modo che, quando è libera, venga gestita
• Devi rendere tutto il lavoro asincrono

La matrice degli eventi diventa complessa molto velocemente. Il nostro FSM qui ha solo 2 stati. Nel caso di Erlang (o di qualsiasi lingua con ricezione selettiva e asincrono con eventi potenzialmente sincroni), devi preoccuparti di alcuni casi:

• Il mutex è gratuito e chiedi di ottenere il blocco
• Il mutex è bloccato da qualcun altro e si desidera ottenere il blocco
• Il mutex è bloccato da solo e si desidera liberare il mutex

E questo è tutto. I timer vengono gestiti negli stessi casi in cui sono stati ricevuti e per tutto ciò che ha a che fare con "aspetta fino a quando è gratuito", i messaggi vengono automaticamente messi in coda: il lavoratore deve solo attendere una risposta. Il modello è molto, molto più semplice in questi casi.

Ciò significa che in casi generali, CPS e modelli basati su callback come quello in node.js o ti chiedono di essere molto intelligente nel modo in cui gestisci gli eventi, o ti chiedono di occuparti completamente di una matrice di eventi complessa, perché devi essere richiamato su ogni caso irrilevante che deriva da strani problemi di temporizzazione e cambiamenti di stato.

Le ricevute selettive di solito ti consentono di concentrarti solo in un sottogruppo di tutti i potenziali eventi e ti permettono di ragionare con molta più facilità sugli eventi in quel caso. Si noti che Erlang ha un comportamento (modello di progettazione / implementazione del framework) di qualcosa chiamato gen_event. L'implementazione gen_event ti consente di avere un meccanismo molto simile a quello che viene utilizzato in node.js se è quello che vuoi.

Ci saranno altri punti che li differenziano; Erlang ha una pianificazione preventiva mentre node.js lo rende cooperativo, Erlang è più adatto ad alcune applicazioni su larga scala (distribuzione e tutto), ma Node.js e la sua comunità sono di solito più adatti al web e ben informati sull'ultima tendenza web. Si tratta di scegliere lo strumento migliore e questo dipenderà dal tuo background, dal tuo tipo di problema e dalle tue preferenze. Nel mio caso, il modello di Erlang si adatta perfettamente al mio modo di pensare. Questo non è necessariamente il caso di tutti.

Spero che sia di aiuto.

Erlang non è complicato da imparare, è solo estraneo alla mentalità che i costanti di Chambers Constant (99,44%) hanno imparato come funziona la programmazione. Il problema che stai affrontando è probabilmente solo il disorientamento concettuale piuttosto che la complessità effettiva.

Ecco alcune delle caratteristiche aliene di Erlang che mordono un programmatore tipico:

• Erlang è un linguaggio di programmazione (principalmente) funzionale. I linguaggi di programmazione più comuni sono quasi militanti.
• Il modello di concorrenza di Erlang è il modello di attore. I linguaggi di programmazione più comuni usano il threading basato su lock o una qualche forma di approccio alla concorrenza basato sul "reattore". (Penso che Node.js sia il secondo, ma non chiamarmi su di esso: non ho alcun interesse per JavaScript su nessun lato della relazione client / server.)
• Erlang ha un approccio "let it crash" alla codifica con potenti funzionalità di runtime disponibili per catturare questi arresti anomali, diagnosticare e hot patch mentre il sistema è in esecuzione. I linguaggi di programmazione più comuni approvano uno stile di programmazione fortemente difensivo.
• Erlang è quasi, ma non del tutto, indissolubilmente accoppiato con una grande e leggermente distorta libreria di architetture di uso comune per server affidabili e stabili (OTP). (C'è una ragione per cui Erlang viene in genere indicato come Erlang / OTP.) Inoltre questa libreria è costruita sulle caratteristiche aliene menzionate in precedenza ed è quindi opaca per i nuovi arrivati. La maggior parte dei linguaggi di programmazione ha meno librerie onnicomprensive (nonostante Java EE) con cui lavorare e le librerie sono, naturalmente, costruite su concetti più familiari alla maggior parte dei programmatori.

Quindi, imparare Erlang rappresenterà una sfida maggiore per la maggior parte dei programmatori rispetto all'apprendimento di Node.js, specialmente se il programmatore ha già familiarità con JavaScript. Alla fine, tuttavia, una volta superata la barriera concettuale, sostengo che la codifica Erlang sarà meno complessa della codifica Node.js equivalente. Questo è per molte ragioni:

• Il modello di concorrenza di Erlang rende il flusso logico molto più chiaro della tipica concorrenza in stile "reattore" e rende la concorrenza molto più stabile e corretta della concorrenza basata su lock tipica. Non è quasi un problema per un programmatore Erlang far cadere letteralmente migliaia di processi in un programma tipico mentre rilasciare migliaia di thread, diciamo, Java sarebbe un incubo di contesa (per non parlare della memoria e dell'overhead della CPU in questione) e il equivalente a mantenere migliaia di stati separati in una configurazione basata su "reattore" sarebbe un incubo da leggere.
• Essendo un linguaggio (principalmente) funzionale, Erlang è molto una configurazione "ciò che vedi è ciò che ottieni". Le variabili, una volta impostate, non cambiano. Mai. Non vi è alcuna "azione spettrale a distanza" OOP per confonderti: tutto ciò con cui lavori viene esplicitamente esposto di fronte a te. Non ci sono variabili ereditate da X e nessuna variabile di classe da Y e nessuna variabile globale da Z di cui preoccuparsi. (Quest'ultimo punto non è vero al 100%, ma è vero in un numero così schiacciante di casi che è abbastanza buono per la tua fase di apprendimento.)
• Le potenti funzionalità di Erlang per la gestione degli errori consentono di ingombrare il codice con una programmazione meno difensiva, mantenendo così la logica più chiara e mantenendo piccolo il codice.
• La libreria OTP, una volta eseguita la ricerca, è una pila di codice comune follemente potente che mantiene regolare l'intera applicazione e copre molti dei problemi e casi d'uso di server di lunga durata a cui probabilmente non penserai fino a quando non è troppo tardi. La stessa libreria OTP è, IM (ns) HO un motivo sufficiente per imparare Erlang.

Se puoi, continua a scappare via da Erlang e, se non l'hai ancora fatto, vai a Per saperne di più su Erlang per il Grande Bene per un'introduzione dolce e (soprattutto) divertente ai concetti di Erlang.

Ci sono alcune differenze significative tra Erlang e Node

Il primo è che il nodo è Javascript, il che significa che è un linguaggio molto comune che condivide molti tratti con lingue a cui più persone hanno familiarità, quindi di solito è molto più facile iniziare a funzionare. Erlang ha una sintassi spesso strana e non familiare per la maggior parte, e sebbene una lingua sia molto più semplice di javascript, ci vuole un po 'più di tempo per abituarsi a causa della sua unicità

Il secondo è che Erlang ha un modello di concorrenza nulla molto particolare condiviso, richiede di pensare in un modo diverso per risolvere i problemi, il che è una buona cosa (TM)

L'ultima importante è che Erlang è stato sviluppato da una società commerciale e open source dopo il fatto, è stato solo 2 anni fa o così che le persone potevano effettivamente vedere i singoli impegni nel controllo del codice sorgente e anche ora non penso che tutti gli sviluppatori di Erlang si siano spostati al repository github pubblico per il loro sviluppo. node.js è stato creato all'interno della community sin dall'inizio, questo significa che il supporto della community è molto migliore, ci sono già molte più librerie per il nodo, più documentazione della community, più esempi dal vivo, un gestore di pacchetti onnipresente ecc. ecc. Erlang sta recuperando terreno a questo proposito, ma è ancora una rampa molto più grande per alzarsi.

Node ti permetterà di programmare cose divertenti abbastanza rapidamente e relativamente indolore, ha ancora dolori crescenti per quanto riguarda le grandi applicazioni che erlang hanno risolto da molto tempo. Erlang cambierà il modo di programmare e (imo) ti renderà un programmatore migliore, tuttavia all'inizio non ti renderà la vita facile. Entrambi sono divertenti in diversi modi.