Nie twierdzę że nie masz racji. Twierdzę tylko, że przy średnim natężenia ruchu tego typu railsy też sobie poradzą. Co do zaś facebookowego czatu, to do mnie wiadomości nie przychodziły synchronicznie na wszystkie urządzenia, i nie wiem jak duże były opóźnienia pomiędzy wysłaniem wiadomości a dostarczenie do pierwszego urządzenia i czy powodem był erlang czy coś zupełnie innego. A z twitterem nie miałem nigdy tego problemu. Nie chodzi o to, że ja koniecznie potrzebuję korzystać z kilku urządzeń z twitterem naraz. Chodzi o to, że brak synchronizacji czatu facebookowego sugeruje problemy albo z infrastrukturą, albo z technologią. Ale to temat na zupełnie inny wątek.
Chodziło mi głównie o to, że railsy nawet przy sporym ruchu dobrze sobie radzą.
rack-jruby czy sinatra-jruby wypadają całkiem dobrze. go w ostatnim roku pozamiatało jeśli chodzi o wydajność serwera www/serializacje json A railsy na MRI jak to railsy na MRI - na samym dole tabelki
W informatyce nikogo nie obchodzi, że technologia X jest szybsze od Y. W informatyce liczy się odpowiedź DLACZEO X jest szybsze od Y.
… a teksty w stylu, że postawisz sobie aplikacje na czymś tam i będziesz mieć 3000req/s można pomiędzy bajki wstawić
Kolejna rzecz, że technologię wybiera się do rozwiązywania problemów. Są obszary, gdzie lepiej się sprawdzi ruby, a i są takie, gdzie lepsze będzie C. Duże systemy są “wielo-techologicznie” i nikogo to nie boli.
a ‘Twitter’ to duzo wiecej, niz tylko robienie prostych insertow.