Btw. Event loop osiąga swoją elastyczność kosztem opóźnień(latency). W pętli wystarczy JEDNO przypadkowe blokujące wywołanie żeby doprowadzić do gigantycznych kolejek. Dlatego pisanie w pętli i systemie callbackowym było zwykle zalecane dla EKSPERTÓW.
A teraz wiecie co jest najlepsze ? KAŻDA funkcja javascript jest wywołaniem blokującym!
Myślicie że to nie problem? Każda dłuższa pętla w funkcji JS jest potencjalna blokadą działania serwera!
każde for(i; i<n; i++){ #synchroniczna trwająca powiedzmy 10ms } dla n = 100 blokuje CAŁY SERWER na sekundę, i gdzie wasze rpmy?
Teraz za każdym razem jak piszesz coś na node.js TWOIM PIEPRZONYM OBOWIĄZKIEM jest upewnienie się że każda pętla w funkcji wykonuje się poniżej 100ms albo woła next_tick. Każdy sensowny język programowania i platforma (i system operacyjny) robi ci to sam, w node.js musisz się z tym pieprzyć osobiście.
Myślicie że dlaczego systemy czasu rzeczywistego nie są powszechnie wykorzystywane? Bo pozwalają jednemu źle napisanemu programowi wykończyć cały system! Tak samo jest z node.js!
Zdarza się wam że czasami firefox(i nie tylko on) cały zamarza jak jakiś skrypt na którejś z zakładek wpada w nieskończoną pętlę i trzeba czekać X minut aż zabezpieczenia FF zdecydują się go ubić?
To teraz wyobraźcie sobie że jedna taka pętla wykańcza ci cały serwer aplikacji, żaden request nie jest obsługiwany, nie można ubić wątku, trzeba położyć cały serwer.
Jak dotąd node.js mimo zapewnień że umożliwia pisanie programów w tym stylu nowiciuszom nie zrobił absolutnie NIC żeby wyeliminować problemy które spowodowały ze tego typu styl programowania praktycznie nie występuje w innych językach poza wyspecjalizowanymi systemami nastawionymi na wysoką wydajność.
Zasadniczo rzadko poświęcam czas na jakiekolwiek benchmarki pomiędzy językami/frameworkami, bo mnie to mało obchodzi i tak jak napisałem taki benchmark dużo nie powie, bo to nie jest realna aplikacja, chciałem tylko zauważyć, że różnica między node’em a ruby 1.9.3 nie jest taka jak między ruby a javą czy C, więc rozsądne jest sprawdzenie rubiego niż lecenie po node’a.
Co do reszty całkowicie się zgadzam. Też jestem wielkim fanem rubiniusa i staram się śledzić co się dzieje wokół tematów, o których wspomniałeś.
@mleszcz
Oczywiście, wiemy dlaczego node się ładnie skaluje. Dlatego też są problemy z backtrace’em i callback driven development. function() {} w javascripcie to jedna ramka na stosie, więc trudno by było, żeby się dało obsłużyć tyle samo klientów używając wątków (czy nawet fibers, to dalej 4KB). Tylko pamiętaj, że node nie ma wątków więc jak coś zablokujesz przez przypadek, to masz duży problem. Przy prostych aplikacjach nie ma problemu, ale przy większych można się walnąć
[quote=Świstak]Teraz za każdym razem jak piszesz coś na node.js TWOIM PIEPRZONYM OBOWIĄZKIEM jest upewnienie się że każda pętla w funkcji wykonuje się poniżej 100ms albo woła next_tick. Każdy sensowny język programowania i platforma (i system operacyjny) robi ci to sam, w node.js musisz się z tym pieprzyć osobiście.
Myślicie że dlaczego systemy czasu rzeczywistego nie są powszechnie wykorzystywane? Bo pozwalają jednemu źle napisanemu programowi wykończyć cały system! Tak samo jest z node.js![/quote] +10k
Zasadniczo rzadko poświęcam czas na jakiekolwiek benchmarki pomiędzy językami/frameworkami, bo mnie to mało obchodzi i tak jak napisałem taki benchmark dużo nie powie, bo to nie jest realna aplikacja, chciałem tylko zauważyć, że różnica między node’em a ruby 1.9.3 nie jest taka jak między ruby a javą czy C, więc rozsądne jest sprawdzenie rubiego niż lecenie po node’a.[/quote]
Pewnie, nie miałem na myśli akurat Twojego “hello world” tylko całej serii benchmarków tego typu, na których cały hype się opiera. Dobrze wiedzieć, że 1.9.3 daje radę (fibonacciego tak pięknie nie policzy ale coż - nie można mieć wszystkiego w życiu ) Hello world to pikuś w porównaniu do tego pomysłu. Tutaj Ruby nie ma szans.
Świstak. Ja Cię już nie proszę. Ja Ci nakazuję.
Załóż wreszcie blogaska.
Albo poskładaj te ranty w nocię i pozwól mi opublikować na moim. Szkoda żeby takie piękne pałowanie hajpu skończyło swój żywot na forum
[quote=Tomash]Świstak. Ja Cię już nie proszę. Ja Ci nakazuję.
Załóż wreszcie blogaska.
Albo poskładaj te ranty w nocię i pozwól mi opublikować na moim. Szkoda żeby takie piękne pałowanie hajpu skończyło swój żywot na forum :D[/quote]
LOL
Eventowe podejście sprawdza się na pewno dobrze w jednej klasie problemów: proxy, gdzie przerzuca się klientów z jednego socketa do drugiego (dużo I/O). I na pewno poleganie na jednym eventloopie/workerze w tym modelu to jest zły pomysł.
Ponownie żeby nie było nieporozumień, systemy eventowe się sprawdzają! Mają one swoje zastosowania i miejsce.
Jednak połączenie systemu eventowego z jednym wątkiem wraz z językiem programowania który nie oferuje żadnego praktycznego wspracia do synchronizacji (node.js nie oferuje także nic takiego jako platforma), w oprogramowaniu webowym jest niestety nieporozumieniem.
Jeżeli chodzi o node.js jako platformę do czegokolwiek dyskwalifikuje jak dla mnie niestety nie model programowania, czy sam język javascript ale:
niestabilność (częste pady nie do zdebugowania)
wczesna wersja platformy oraz częste zmiany niszczące kompatybilność wsteczną
Brak przekonywujących argumentów za zmianą (nie widziałem jeszcze ani jednego sensownego studium porównawczego Python/Ruby vs Node dla większych aplikacji).
Brak bibliotek
Niestabilność i błędy
Brak dokumentacji
pokopana i cąłkowicie nieintuicyjna obsługa błędów.
Jak ktoś chce wskoczyć wcześnie na hype train, proszę bardzo, ale wiąże się to z ryzykiem o czym przekonali się wszyscy (w tym ja) którzy zapowiadali świetlana przyszłość Scali.
PS. Spodziewalibyście się na przykład że:
try{
foo(function(){ throw(CosPoszloZle) });
} catch(e) {
console.log(“jestem bezpieczny”);
}
uchroni was przed wszelkim złem prawda? niestety w node.js może się okazać że funkcja foo ma treść:
function(a){ next_tick(a) };
specjalnie po to żeby upewnić się że funkcja a nie zablokuje pętli. Wiecie co się wtedy dzieje?
a) Wyjątek jest łapany przez catch(e)
b) Aplikacja kończy działanie bez żadnego komunikatu o błędzie, backtraca, czy coredumpa
W każdej sensownej platformie i języku (nawet JS w przeglądarkach!) odpowiedzią jest a. w node.js jak się zapewne już domyśleliście odpowiedzią jest b
O widzę ładnie żeście naspamowali, całkiem nieźle spodziewałem się “połowicznych” postów.
Offtop
Ale co jest złego w Scali wg Ciebie? Ten składniowy miszmasz czy też wyższa bariera wejścia niż w Ruby?
Imho Scala się przebije do mainstreamu. Nie będzie to trwało szybko, ale jest to nieuniknione w ciągu najbliższych lat.
@Matthias tak z 2 lata temu podobnie jak dzisiaj na node.js był hype na scale. Scala to był The Next Big Thing™. Każdy (w tym ja) podzielał przekonanie że scala jest kolejnym logicznym krokiem ewolucji.
Okazało się że nie tylko bariera wejścia jest zbyt duża ale składnia na tyle udziwniona że systemy zbudowane już w scali stają się ciężkie do utrzymania.
Ostatnio nawet dosyć głośno omawiane były dwa przypadki gdzie dosyć duże firmy wycofywały się z systemów napisanych w scali wracjąc do Javy właśnie ze względu na trudności w utrzymaniu (i związane z tym koszty, programiści Scali nie są tani).
Scala miała ten problem że żeby ją w ogóle uruchomić trzeba było jednocześnie czytać 3 poradniki, były też problemy z kompilacją, a głośno wychwalana integracja z javą była wcale nie taka prosta. Co więcej do dziś dzień nie dorobiła się wsparcia od żadnego sensownego IDE (coś tam jest w Eclipse zdaje się, ale też z tym krucho).
Jak dla mnie node.js ma szanse, ale raczej niewielkie. A moim zdaniem zaważy nad tym nic innego jak czynniki społeczne.
Profesjonalni programiści będą unikać platformy jako niestabilnej, a języka jako delikatnie mówiąc niespójnego (kiedyś napiszę esej jak działa operator ==. wiecie np. że w javascript [] == 0, i “0” == 0 ale [] != “0”. albo że (true == “true”) == false ale też (false == “true”) == false, albo “0” == false, “1” == true, ale “2” == false )
Efektem będzie że platformą zajmą się ludzie skrzywieni myśleniem JavaScriptowym, i ledwo znający teorię programowania, tworząc babole i spaghetti. I fascynaci którzy zafascynują się nowością, napiszą tysięczny framework webowy albo setny framework do synchronizacji(co patrząc na listę modułów node.js wydaje się głównym sportem programistów node.js), po czym przeniosą się do TNBT.
platforma zostanie z kiepskimi bibliotekami i jeszcze gorszą opinią.
dobra koniec bashowania node.js.
NIE UŻYWAĆ node.js HOWGH!*
chyba że klient płaci, a wy tego nie będziecie potem utrzymywać.
Poradniki kojarzą mi się z KS Ekspert, ale raczej o scali tam nic nie było… Aby porządnie postawić railsy też trzeba się namęczyć.
Uruchomienie scali sprowadza się do ściągnięcia binarki. A używanie sbt (scalowy odpowiednik mavena, dla kompletnych niejavowców odpowiednik bundlera) też nie jest większym problemem. Dodam więcej, postawienie aplikacji we frameworku Play2 (beta) jest o wiele milsze niż postawianie aplikacji Rails 3.1.
Co do wycofywania się z używania scali, to jakie firmy masz na myśli?
[code]>>> if (“2”) console.log(“true”); else console.log(“false”);
true
“2” == false
false
“2” == true
false[/code]
… bardzo ciekawe (i dlatego pamiętać - zawsze “===”, nigdy “==”).
Nie zmienia to faktu, że duża część JS-a to śmietnik i używać nigdy, przenigdy nie należy (o czym pisze Crockford). Jak się ograniczy zasób języka do “good parts” to jest w porządku (tak, mam świadomość, że to kiepski argument na obronę języka).
It’s vital to database and search engine like software. So please release a fix or 64bit version or whatever. It would make V8 and things like NodeJS more a useful tool instead of just a toy (I’m not talking about browsers. We need to make the next step.).
.
.
.
And kitchen sink because every next step must be step into the right direction.
Ale dobra, nie będe się pastwił wkońcu jest oznaczone jako fixed.
$ ab -c 100 -n 100 http://127.0.0.1:9292/
...
Time taken for tests: 0.256 seconds
For a perspective, this operation took 33 seconds without this extension in thin.[/quote]
@sebcioz Co tylko potwierdza że programowanie eventowe sprawdza się do pisania proxy, niekoniecznie do czegokolwiek innego.
@nagl: well. to jest platforma do zarządzania chmurą, więc jedna wyhajpowana technologia napędzana inną.
Po krótkim przeskanowaniu posta na blogu, wychodzi na to że projekt został skopany, więc postanowili zmienić platformę.
i callback driven development. function() {} w javascripcie to jedna ramka na stosie, więc trudno by było, żeby się dało obsłużyć tyle samo klientów używając wątków (czy nawet fibers, to dalej 4KB). Tylko pamiętaj, że node nie ma wątków więc jak coś zablokujesz przez przypadek, to masz duży problem. Przy prostych aplikacjach nie ma problemu, ale przy większych można się walnąć 
(tak, mam świadomość, że to kiepski argument na obronę języka).