Qual è la risposta Haskell a Node.js?

Credo che la comunità Erlang non sia invidiosa di Node.js in quanto esegue l'I / O non bloccante in modo nativo e ha modi per ridimensionare facilmente le distribuzioni su più di un processore (qualcosa che non è nemmeno incorporato in Node.js). Maggiori dettagli su http://journal.dedasys.com/2010/04/29/erlang-vs-node-js e Node.js o Erlang

Che mi dici di Haskell? Haskell può offrire alcuni dei vantaggi di Node.js, ovvero una soluzione pulita per evitare il blocco dell'I / O senza ricorrere alla programmazione multi-thread?

Ci sono molte cose interessanti con Node.js

1. Eventi: nessuna manipolazione del thread, il programmatore fornisce solo callback (come nel framework Snap)
2. I callback sono garantiti per essere eseguiti in un singolo thread: nessuna condizione di competizione possibile.
3. API amichevole e semplice per UNIX. Bonus: eccellente supporto HTTP. DNS disponibile anche.
4. Ogni I / O è di default asincrono. Ciò rende più semplice evitare i blocchi. Tuttavia, un'eccessiva elaborazione della CPU in un callback influirà su altre connessioni (in questo caso, l'attività dovrebbe essere suddivisa in attività secondarie più piccole e riprogrammata).
5. Stessa lingua per lato client e lato server. (Non vedo troppo valore in questo, tuttavia. JQuery e Node.js condividono il modello di programmazione degli eventi, ma il resto è molto diverso. Non riesco proprio a vedere come la condivisione del codice tra lato server e lato client potrebbe essere utile in pratica.)
6. Tutto questo confezionato in un unico prodotto.

Ok, quindi dopo aver visto un po 'della presentazione node.js che @gawi mi ha indicato, posso dire qualcosa in più su come Haskell paragona a node.js. Nella presentazione, Ryan descrive alcuni dei vantaggi di Green Threads, ma continua dicendo che non trova la mancanza di un'astrazione di thread uno svantaggio. Non sarei d'accordo con la sua posizione, in particolare nel contesto di Haskell: penso che le astrazioni fornite dai thread siano essenziali per rendere il codice del server più facile da ottenere e più robusto. In particolare:

• l'utilizzo di un thread per connessione consente di scrivere codice che esprime la comunicazione con un singolo client, anziché quel codice di scrittura che si occupa tutti i client contemporaneamente. Pensala in questo modo: un server che gestisce più client con thread sembra quasi uguale a quello che gestisce un singolo client; la differenza principale è che c'è un forkposto nel primo. Se il protocollo che stai implementando è del tutto complesso, la gestione della macchina a stati per più client contemporaneamente diventa piuttosto complicata, mentre i thread ti consentono di creare script per la comunicazione con un singolo client. Il codice è più facile da ottenere e più facile da capire e mantenere.

• i callback su un singolo thread del sistema operativo sono il multitasking cooperativo, al contrario del multitasking preventivo, che è ciò che si ottiene con i thread. Il principale svantaggio del multitasking cooperativo è che il programmatore è responsabile di assicurarsi che non ci sia fame. Perde la modularità: commette un errore in un unico punto e può rovinare l'intero sistema. Questo è davvero qualcosa di cui non devi preoccuparti, e la prevenzione è la soluzione semplice. Inoltre, la comunicazione tra callback non è possibile (sarebbe deadlock).

• la concorrenza non è difficile in Haskell, perché la maggior parte del codice è pura e quindi è thread-safe per costruzione. Esistono semplici primitive di comunicazione. È molto più difficile spararsi ai piedi con la concorrenza in Haskell che in una lingua con effetti collaterali senza restrizioni.

Haskell può offrire alcuni dei vantaggi di Node.js, ovvero una soluzione pulita per evitare il blocco dell'I / O senza ricorrere alla programmazione multi-thread?

Sì, in effetti eventi e thread sono unificati in Haskell.

• È possibile programmare in thread espliciti e leggeri (ad esempio milioni di thread su un singolo laptop).
• O; puoi programmare in uno stile asincrono basato sugli eventi, basato su una notifica di eventi scalabile.

Le discussioni sono in realtà implementati in termini di eventi e vengono eseguiti su più core, con una migrazione senza interruzioni, con prestazioni documentate e applicazioni.

Ad esempio per

• massicciamente orchestrazione di lavoro concorrente
• raccolte simultanee ridimensionamento su 32 o 48 core
• supporto degli strumenti per la profilazione e il debug programmi multi-thread / multi-evento .
• alte prestazioni server Web ad basati su eventi .
• utenti interessanti: come il trading ad alta frequenza .

Collezioni simultanee nessuno su 32 core

In Haskell hai sia eventi che discussioni, e come lo sono tutti gli eventi sotto il cofano.

Leggi l'articolo che descrive l'implementazione.

Innanzitutto, non credo che node.js stia facendo la cosa giusta esponendo tutti quei callback. Finisci per scrivere il tuo programma in CPS (stile di passaggio di continuazione) e penso che dovrebbe essere il lavoro del compilatore fare quella trasformazione.

Eventi: nessuna manipolazione del thread, il programmatore fornisce solo callback (come nel framework Snap)

Quindi, con questo in mente, puoi scrivere usando uno stile asincrono, se lo desideri, ma così facendo perderesti di scrivere in uno stile sincrono efficiente, con un thread per richiesta. Haskell è incredibilmente efficiente nel codice sincrono, soprattutto se confrontato con altre lingue. Sono tutti gli eventi sottostanti.

I callback sono garantiti per essere eseguiti in un singolo thread: nessuna condizione di competizione possibile.

Potresti avere ancora una race condition in node.js, ma è più difficile.

Ogni richiesta è nel proprio thread. Quando scrivi codice che deve comunicare con altri thread, è molto semplice renderlo sicuro grazie alle primitive di concorrenza di haskell.

API amichevole e semplice per UNIX. Bonus: eccellente supporto HTTP. DNS disponibile anche.

Dai un'occhiata all'hackage e vedi di persona.

Per impostazione predefinita, ogni I / O è asincrono (a volte può essere fastidioso). Ciò rende più semplice evitare i blocchi. Tuttavia, un'eccessiva elaborazione della CPU in un callback influirà su altre connessioni (in questo caso, l'attività dovrebbe essere suddivisa in attività secondarie più piccole e riprogrammata).

Non hai questi problemi, ghc distribuirà il tuo lavoro tra thread del sistema operativo reale.

Stessa lingua per lato client e lato server. (Non vedo troppo valore in questo, tuttavia. JQuery e Node.js condividono il modello di programmazione degli eventi, ma il resto è molto diverso. Non riesco proprio a vedere come la condivisione del codice tra lato server e lato client potrebbe essere utile in pratica.)

Haskell non può assolutamente vincere qui ... giusto? Ripensaci, http://www.haskell.org/haskellwiki/Haskell_in_web_browser .

Tutto questo confezionato in un unico prodotto.

Scarica ghc, accendi la cabala. C'è un pacchetto per ogni esigenza.

Personalmente vedo Node.js e la programmazione con callback come inutilmente di basso livello e un po 'innaturale. Perché programmare con i callback quando un buon runtime come quello trovato in GHC può gestire i callback per te e farlo in modo abbastanza efficiente?

Nel frattempo, il runtime di GHC è notevolmente migliorato: ora presenta un "nuovo nuovo IO manager" chiamato MIO in cui "M" sta per multicore credo. Si basa sulle fondamenta dell'IO Manager esistente e il suo obiettivo principale è superare la causa del degrado delle prestazioni di oltre 4 core. I numeri delle prestazioni forniti in questo documento sono piuttosto impressionanti. Vedi te stesso:

Con Mio, i server HTTP realistici in Haskell scalano a 20 core della CPU, raggiungendo prestazioni di picco fino a un fattore di 6,5x rispetto agli stessi server che utilizzano le versioni precedenti di GHC. Anche la latenza dei server Haskell è migliorata: [...] con un carico moderato, riduce i tempi di risposta previsti di 5,7x rispetto alle versioni precedenti di GHC

E:

Mostriamo anche che con Mio, McNettle (un controller SDN scritto in Haskell) può scalare in modo efficace a oltre 40 core, raggiungere una trasmissione di oltre 20 milioni di nuove richieste al secondo su una singola macchina e quindi diventare il più veloce di tutti i controller SDN esistenti .

Mio è diventato GHC 7.8.1. Personalmente vedo questo come un importante passo avanti nella performance di Haskell. Sarebbe molto interessante confrontare le prestazioni delle applicazioni Web esistenti compilate dalla versione precedente di GHC e 7.8.1.

Gli eventi IMHO sono buoni, ma la programmazione tramite callback non lo è.

La maggior parte dei problemi che rendono speciali la codifica e il debug delle applicazioni Web deriva da ciò che le rende scalabili e flessibili. La più importante, la natura apolide di HTTP. Ciò migliora la navigabilità, ma impone un'inversione del controllo in cui l'elemento IO (il server Web in questo caso) chiama gestori diversi nel codice dell'applicazione. Questo modello di eventi - o il modello di callback, detto più accuratamente - è un incubo, poiché i callback non condividono ambiti variabili e si perde una vista intuitiva della navigazione. È molto difficile prevenire tutti i possibili cambiamenti di stato quando l'utente naviga avanti e indietro, tra gli altri problemi.

Si può dire che i problemi sono simili alla programmazione della GUI in cui il modello di eventi funziona correttamente, ma le GUI non hanno navigazione e nessun pulsante Indietro. Ciò moltiplica le transizioni di stato possibili nelle applicazioni Web. Il risultato del tentativo di risolvere questi problemi sono quadri pesanti con configurazioni complicate, un sacco di pervasivi identificatori magici senza mettere in discussione la radice del problema: il modello di callback e la sua intrinseca mancanza di condivisione di ambiti variabili e nessun sequenziamento, quindi la sequenza deve essere costruito collegando identificatori.

Esistono framework basati sequenziali come ocsigen (ocaml) seaside (smalltalk) WASH (fuori produzione, Haskell) e mflow (Haskell) che risolvono il problema della gestione dello stato mantenendo la navigabilità e la completezza REST. all'interno di questi framework, il programmatore può esprimere la navigazione come una sequenza imperativa in cui il programma invia pagine e attende risposte in un singolo thread, le variabili rientrano nell'ambito e il pulsante Indietro funziona automaticamente. Ciò produce intrinsecamente un codice più breve, più sicuro e più leggibile in cui la navigazione è chiaramente visibile al programmatore. (discreto avvertimento: sono lo sviluppatore di mflow)

La domanda è piuttosto ridicola perché 1) Haskell ha già risolto questo problema in modo molto migliore e 2) più o meno allo stesso modo di Erlang. Ecco il benchmark rispetto al nodo: http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-benchmarks

Dai a Haskell 4 core e può fare 100k (semplici) richieste al secondo in una singola applicazione. Il nodo non può fare altrettanto, e non può ridimensionare una singola applicazione tra i core. E non devi fare nulla per raccoglierlo perché il runtime di Haskell non è bloccante. L'unico altro linguaggio (relativamente comune) che ha IO non bloccante integrato nel runtime è Erlang.

Proprio come nodejs è sceso libev la Haskell Web Framework Snap è sceso libev troppo.