Newsgroup: it.lavoro.informatica
Titolo: Re: node.js is cancer

 
http://teddziuba.com/2011/10/node-js-is-cancer.html
 
 
Perche' posti questa cosa qui? (sidenote: e' bombata di inesattezze - 
lungi da me difendere node.js, ma quella roba non si puo' davvero 
leggere …)
Tra l'altro il fatto che non segue la Unix way e' una cagata incredibile ...
 
  ngw
 
-- 
http://stylej.am
 
 

 Per esempio, che inesattezze dice?
 
«It's Fucking JavaScript»
 
come non quotare... ma con node puoi usare coffeescript, che è 100 volte
meglio di javascript puro, per cui non è poi tanto male.
 

 dare spunto a discussioni
 
Lo e', lo e'.. node e' una delle cose relativamente nuove all'
orizzonte e fare una valutazione corretta dei nuovi strumenti che
vengono proposti e' sicuramente una delle chiavi di successo nel
nostro lavoro.. certo che pero' invece che andare per intuizione e
sentito dire sarebbe interessante sentire qualche opinione di chi ci
ha lavorato, o almeno smanettato per un po'...

 framework, a parte per fare test veloci?
 
Tutti quelli che hanno la necessita' di avere un event loop cagato 
anche dal server HTTP, perche' se io riempio il mio software di 
callback e errback basate sull'esecuzione di una istruzione mi serve un 
server che si integri con questo sistema di esecuzione, altrimenti non 
va una cippa.
Se esci dall'ottica del server "embedded" che vuol dire tutto e vuol 
dire niente ti accorgi che anche HTTP sta diventando un servizio 
custom, e che e' assolutamente normale avere un proxy come nginx, che 
il proxy lo fa meravigliosamente bene, e dei server di backend che 
fanno bene altro. Questa e' *esattamente* la Unix way, software 
moderatamente piccolo che si passa responsabilita' in base alla 
capacita', hanno solo sostituito le pipes con HTTP.
In Ruby abbiamo Unicorn (
http://unicorn.bogomips.org/
) e Goliath 
(
http://postrank-labs.github.com/goliath/
) che hanno caratteristiche 
praticamente opposte, e servono scopi praticamente opposti. In Erlang, 
che e' node.js per bambini grandi (:D) c'e' YAWS, che magari e' 
interessante proprio per la concorrenza che riesce ad ottenere 
(
http://www.sics.se/~joe/apachevsyaws.html
) e che non ottiene perche' 
Erlang e' piu' veloce di C (non lo e' di fatto) ma perche' Apache usa 
il modello di threading del sistema operativo mentre Erlang usa i suoi 
processi in un reactor pattern nello stesso modo in cui lo usa node.js, 
che pero' e' molto piu' giovane, e non sfrutta CPU multicore - il che 
e' il vero grande limite di node.js e quello su cui si dovrebbe basare 
ogni critica, altroche' i tempi di avvio del server.
 
Ora, se metti Erlang in mano al programmatore quadratico medio, se ti 
va bene ti sputa in faccia, basta dirgli che non puo' riattribuire un 
valore diverso ad una variabile perche' sta facendo "pattern matching" 
e non assegnazione (il simbolo =), se metti Javascript hai la 
spiegazione per cui node.js viene considerato "nuovo" e "figo", quando 
in realta' non lo e', la select per Unix c'e' da mille anni, e le GUI 
sono da sempre event driven (anche quelle di KDE, se non ricordo male).
 
Volevo anche dire che Teddy e' evidentemente un troll, visto che senza 
rant-mode non lo cagherebbe neppure sua mamma.
 
  ngw
 
-- 
http://stylej.am
 
 

 orizzonte
 
mooolto relativamente. il ssjs è stato in voga ben prima che molte
tecnologie server-side si affacciassero sulla scena.
 

 delle pipe.
 
A me pare che non capisca *perche'* node.js abbia un server a parte. 
Cioe' per carita, internet e' fatta perche' tutti possano dare un 
opinione su tutto, ma per me se studiava come funziona l'async prima di 
andare in rant-mode su un framework async brutta figura non faceva.
Magari vuole provare a scrivere un modulo nginx per gestire l'event 
loop interfacciandosi con v8, cosi' puo' scoprrie la ricorsione "#{ 
teddy } fuck fuck fuck #{ teddy }".
 
  ngw
 
-- 
http://stylej.am
 
 

 Fibonacci e' bloccante, qualunque cosa lo e'
 
Beh, il "bloccare" usando la CPU e facendo I/O sono due cose molto diverse. 
Il concetto è che se stai usando la CPU non è molto importante che tu lasci 
il controllo perché sarebbe meno efficiente fare dei context-swap, se invece 
stai aspettando dell'I/O è bene lasciare la CPU perché la possa usare 
qualcun altro.
 
Si può discutere se operazioni ad alta intensità di CPU possano creare dei 
problemi di *latenza* in un modello asincrono/event-based ma quanto a 
efficienza non conviene metterle in background.
 
Ovviamente quando hai più CPU da far lavorare il problema si complica per 
ovvi motivi...
 
Ma immagino di star ribadendo cose che ben conosci,
 
Ciao,
 
-- 
  Daniele "Vihai" Orlandi
  Bieco Illuminista #184213

 CUT
 
Oh signore, vendendo la sua risposta successiva credo di aver capito il 
suo punto. Non scrivere roba CPU intensive con node.js, che e' un po' 
come dire di non spostare calamite per scrivere su un disco fisso.
Beh, se questo e' il punto, si, che nessuno faccia un encoder video in 
javascript, lol :D
Uno da anche scontato che quando uno legge "non blocking IO" pensi 
all'IO e non alla CPU, ma con Dziuba non si sa mai. Del resto sai 
quanti server e quante web app sono CPU intensive, a mazzi, credo solo 
il 99,9% abbia problemi con l'IO e il restante con la CPU. Ma pensa 
te...
 
  ngw
 
-- 
http://stylej.am
 
 

 Ma immagino di star ribadendo cose che ben conosci,
 
Guarda, sono sincero, non ho badato alla parte del blocco della CPU. 
Proprio non ci ho pensato, perche' mi sembra da deficienti basare un 
rant pieno di offese sul fatto che un framework che "dovrebbe" 
risolvere il problema dell'IO si basi sul fatto che invece blocca la 
CPU su operazioni CPU bound, mi sembra evidente ed e' un'altro 
problema, e mi sembra da matti credere che Javascript (o Python, o 
Ruby) possano portare ottimizzazioni concrete ad operazioni CPU bound, 
hanno tutti un GIL, e' naturalmente impossibile.
Sinceramente mi sembra come prendersela con C perche' e' difficile 
usarlo per fare web app, sarebbe dachiedersi perche' hai scelto C, 
visto che evidentemente e' poco adatto.
 
Erlang permette di scrivere software che usa il modello asincrono su 
CPU multicore o macchine multiprocessore sfruttandole come si conviene. 
Clojure e Haskell, con diversi modelli, anche. Ma sicuramente Erlang e' 
il piu' interessante.
 
Mi sembra pero' un appunto altamente irrilevante, node.js fa altro, non 
si e' mai proposto come un software che risolve problemi CPU bound, ma 
IO bound. E quello lo fa ragionevolmente bene.
 
  ngw
 
-- 
http://stylej.am
 
 

 scalano vista l'inefficenza di JavaScript.
 
JavaScript non c'entra nulla, node.js usa un modello event-based (che IMHO è 
il modello migliore per scrivere applicazioni network-bound) ed è un 
presupposto implicito, quando usi quel modello, quello di gestire gli eventi 
velocemente, ovvero in un tempo paragonabile alla latenza attesa del 
sistema.
 
Qualunque elaborazione che impieghi un tempo superiore è da mettersi in 
un'altra categoria delle elaborazioni da gestire in background. E allora 
spawni un processo, un thread, una fiber, un sarcazzo che la gestisce con 
comodo.
 
È come lamentarsi che un sistema realtime non funziona se in un interrupt 
handler mi metto a cacolare fibonacci....
