Dlaczego Ruby on Rails jest wyjątkowy?
Posted by Jarosław Zabiełło Sun, 14 May 2006 04:22:00 GMT
Niektórym osobom stykającym się z po raz pierwszy z Railsami wydaje się, że jest to tylko jakieś kolejne, tradycyjne środowisko developerskie pracujące wg wzorca projektowego MVC (model-widok-kontroler). Przywiązani do swoich języków i frameworków czasami się dziwią, dlaczego temat Railsów wywołuje od jakiegoś czasu tyle emocji i komentarzy. Na pewno po częsci jest tak pewnie dlatego, że RoR jest bardzo dobrze wypromowany. Dobra strona główna, dobra dokumentacja, książki, filmy, bardzo aktywna społeczność – nic tylko naśladować. Z drugiej strony, trzeba też przyznać, że jest to środowisko świetnie zaprojektowane – w Railsach sie pracuje po prostu komfortowo.
Nie dziwią więc ciągłe próby naśladowania Railsów w innych językach (PHP, Python, Java, C# itp) Jednakże między nimi a Railsami będzie ciągle pewna, trudna do osiągnięcia, jeśli nie w ogóle niemożliwa – bariera. Railsy posiadają nie tylko wszystko, co potrzeba do bardzo produktywnego tworzenia aplikacji internetowych, ale są przy tym równocześnie bardzo eleganckie i czytelne. Eleganckie i czytelne czyli łatwe do nauki. Tak, nauka Rubiego nie jest przeszkodą. Przekona się o tym każdy, kto trochę bliżej przyjrzy się jak działa RoR.
Miałem okazję porównywać ze sobą kilka różnych frameworków. Gdy chciałem przekonać się do któregoś z nich, zawsze ostatecznie wracałem z powrotem do RoR. Po prostu żaden z nich nie jest jak elegancki i prosty w użyciu1. Co jest główną przyczyną takiego wrażenia? Twórca Railsów, David Heinemeier Hansson powiedział kiedyś, że gdyby nie Ruby to nie powstałby Ruby on Rails. Powiedział także, że uważa iż w żadnym innym języku nie da się napisać tak eleganckiego i pięknego kodu. Zatem można powiedzieć, że prawdziwą siłą Railsów jest Ruby. Razem tworzą nierozłączną parę i ta łączność nie dotyczy bynajmniej tylko nazwy. ;) Ruby posiada bowiem pewne unikalne cechy, które pozwoliły stworzyć RoR w postaci, która jest raczej mało nieosiągalna dla innych języków. Już to wyjaśniam.
Panuje powszechnie mniemanie, że Ruby to połączenie cech Pythona i Perla. Ruby (podobnie jak Perl) posiada np. wbudowaną w składnię obsługe wyrażeń regularnych. Posiada także (podobnie jak Python) pełną obiektowość i bardzo elegancką, czytelną (choć nie taką samą) składnię. Pewnym odkryciem było dla mnie to, że językie, do którego Ruby ma najwięcej podobieństw to innego języka – Smalltalk. Lektura cech, filozofii (i nawet do pewnego stopnia składni) Smalltalka pokazuje zdumiewające podobieństwo do Rubiego. Można wręcz odnieść wrażenie, że Ruby to swego rodzaju przeróbka Smalltalka2. Podobieństw jest bardzo wiele. Od słów kluczowych po symbole, sposób tworzenia instancji klas, bloki kodu (ang. closures), kontynuacje3 itp. Jak ktoś jeszcze nie rozumie filozofii Rubiego, jego modelu obiektowego i powodu istnienia otwartych klas, powinien poczytać sobie trochę o Smalltalku.
Ruby jak i Smalltalk posiadają bardzo podobny model obiektowy. Wszystkie obiekty (na drodze dziedziczenia) wywodzą się z jednej, ostateczniej klasy Object. Oba języki mają zaimplementowaną pełną obiektowość. Nie ma (tak ja w Javie) podziału na prymitywy i typy referencyjne. Wszystko jest obiektem i wszystko posiada metody. Dotyczy to nie tylko liczb i napisów ale także obiektu nil, true czy false. Każdy obiekt można przeciążyć i/lub zmodyfikować wewnetrznie (dynamicznie dodając lub usuwając jego metody w trakcie pracy programu)
Z tego wynika, że właściwie to można modyfikować sam język. Daje to możliwości zupełnie nieosiągalne nawet dla tak dobrego i obiektowego języka jakim jest Python. Ruby pozwala na łatwe dodawanie nowych metod do liczb czy napisów. Pozwala na taką modyfikację samego siebie, aby optymalnie nadawał się do realizacji pewnych, specyficznych zadań. Ruby umożliwia zatem tworzenie tego, co się określa mianem języków domenowych (Domain-specific Programming Languages). Są to języki, które w przeciwieństwie do języków ogólnego zastostosowania, zostały zaprojektowane do wykonywania specyficznego zadania/zadań. Zarówno Smalltalk jak i Ruby pozwalają na tworzenie języków domenowych.
Ruby on Rails to nic innego jak framework napisany za pomocą Rubiego zmodyfikowanego w celu uzyskania wysoce produktywnego środowiska do tworzenia nowoczesnych aplikacji internetowych.
Przykładowe helpery dostępne w Rails, które korzystają z nowych metod nie będących standardową częścią Rubiego. Poniższe przykłady pochodzą z 1-g wydania książki Agile Web Development in Rails.
puts 20.bytes #=> 20
puts 20.kilobytes #=> 20480
puts 20.megabytes #=> 20971520
puts 20.gigabytes #=> 21474836480
puts 20.terabytes #=> 21990232555520
puts 20.minutes.ago #=> Tue May 10 16:43:43 CDT 2005
puts 20.hours.from_now #=> Wed May 11 13:03:43 CDT 2005
puts 20.weeks.from_now #=> Tue Sep 27 17:03:43 CDT 2005
puts 20.months.ago #=> Thu Sep 18 17:03:43 CDT 2003
now = Time.now
puts now #=> Tue May 10 17:15:59 CDT 2005
puts now.ago(3600) #=> Tue May 10 16:15:59 CDT 2005
puts now.at_beginning_of_day #=> Tue May 10 00:00:00 CDT 2005
puts now.at_beginning_of_month #=> Sun May 01 00:00:00 CDT 2005
puts now.at_beginning_of_week #=> Mon May 09 00:00:00 CDT 2005
puts now.at_beginning_of_year #=> Sat Jan 01 00:00:00 CST 2005
puts now.at_midnight #=> Tue May 10 00:00:00 CDT 2005
puts now.change(:hour => 13) #=> Tue May 10 13:00:00 CDT 2005
puts now.last_month #=> Sun Apr 10 17:15:59 CDT 2005
puts now.last_year #=> Mon May 10 17:15:59 CDT 2004
puts now.midnight #=> Tue May 10 00:00:00 CDT 2005
puts now.monday #=> Mon May 09 00:00:00 CDT 2005
puts now.months_ago(2) #=> Thu Mar 10 17:15:59 CST 2005
puts now.months_since(2) #=> Sun Jul 10 17:15:59 CDT 2005
puts now.next_week #=> Mon May 16 00:00:00 CDT 2005
puts now.next_year #=> Wed May 10 17:15:59 CDT 2006
puts now.seconds_since_midnight #=> 62159.215938
puts now.since(7200) #=> Tue May 10 19:15:59 CDT 2005
puts now.tomorrow #=> Wed May 11 17:15:59 CDT 2005
puts now.years_ago(2) #=> Sat May 10 17:15:59 CDT 2003
puts now.years_since(2) #=> Thu May 10 17:15:59 CDT 2007
puts now.yesterday #=> Mon May 09 17:15:59 CDT 2005
puts "cat".pluralize #=> cats
puts "cats".pluralize #=> cats
puts "erratum".pluralize #=> errata
puts "cats".singularize #=> cat
puts "errata".singularize #=> erratumZ racji tego, że Railsy zmodyfikowały Rubiego do realizacji swoich zadań, uważam, że próba sklonowania tego środowiska w jakimś innym języku (poza Smalltalkiem), jest z góry skazana na niepowodzenie. Po prostu nigdy to nie będzie tak piękny kod jak Ruby dla Railsów. Na otarcie łez dla pythonistas, mogę powiedzieć, że przy wszystkich zaletach Rubiego, nadal uważam że Python (jako język) jest nie tylko łatwiejszy do opanowania ale także bardziej produktywny. Ale jeśli chodzi o frameworki, to Rails jest nie do pobicia jeśli chodzi o komfort, możliwości i DRY[4].
—
1 Zupełnie identyczne wrażenia prostoty jak z Railsami miałem w przypadku szukania dobrego systemu CMS’a. Taki np. pythonowy Plone w porównaniu do ezPublish i całej masy innych, pehapowych rozwiązań jest nie tylko poteżniejszy ale także niezrównanie prostszy i wygodny (po 5 minutach od instalacji, praktycznie bez czytania dokumentacji i bez znajomości Pythona, można stworzyć prosty serwis o całkiem przyzwoitej, podstawowej funkcjonalności)
2 Smalltalk posiada tylko 5 słów kluczowych i proste zasady: wszystko jest obiektem, wszystkie operacje polegają na przesyłaniu metod (nazywanych tu: wiadomościami) między obiektami. Moim zdaniem Smalltalk trochę przesadził z tą zasadą, bo nawet bo zamiast do sterowania kontrolą kodu używane są także wiadomości. Może jest jest spójne, ale trochę dziwnie wygląda. Osobiście bardziej podobają mi się możliwości Smalltalka ale wyrażone w składni …Rubiego. :) Zobacz też Ruby Instead of Smalltalk
3 Kontynuacje są jedną z wbudowanych cech Rubiego o której może być za jakiś czas głośno. Umożliwiają bowiem budowanie tzw. internetowych serwerów kontynuacyjnych, które w pełni zachowują stan pomiędzy requestami i ogromnie upraszczają prace programistów. W tej chwili najlepiej opracowanym frameworkiem tego typu jest smalltalkowy Seaside.
4 DRY to skrót od ang. Dont’t Repeat Yourself. Railsy zostały napisane z wręcz obsesyjną ;) cechą unikania powtarzania kodu. Mniej powtórzeń to nie tylko mniej niepotrzebnej, dodatkowej pracy ale także mniejsze ryzyko popełniania błędu.
Subskrypcja kanału RSS
Kanały IRC![[Dilber w Onecie]](/images/larry.png)
“wszystkie operacje polegają na przesyłaniu metod (nazywanych tu: wiadomościami) między obiektami.”
Boże, jakim “przesyłaniu metod”?? Jak już to “wołanie metod” chyba. Nigdzie ich przecież nie przesyłasz :P
I tak dla informacji: wiadomość to standardowa nazwa na wywołanie metody w UML. Można więc mówić o wiadomościach zarówno w Smalltalku, Javie czy Ruby.
Co do artykułu – strasznie dużo gadania, strasznie mało konkretów. Nie dowiedziałem się na przykład jakie są zalety Ruby’ego w porównaniu do javowego SpringFramework…
Celem artykułu nie było drobiazgowe porównywanie Railsów z resztą świata, ale zwrócenie uwagi na niezwykle silne powiązania Rubiego ze Smalltalkiem i możliwości przekształcania języka, co tłumaczy dlaczego Rails nie może żyć bez Rubiego. I to tłumaczy dlaczego próby sklonowania Railsów w innych językach to porażka.
W terminologii Smalltalka nie mówi się o wywoływaniu metod, ale raczej o wysyłaniu wiadomości do obiektu:
Spring to nie język, więc nie ma sensu porównywać go z Rubym (jeśli już, to raczej z Railsami). Zalet Railsów jest sporo. M.in. znacznie szybsza pętla sprzężenia zwrotnego, mniej kodu bez szkody dla czytelności (jak w Perlu), mniej plików konfiguracyjnych, DRY i konwencje ponad konfiguracjami dające razem znacznie większą produktywność w tym środowisku. Railsy realizują (znacznie lepiej niż inne frameworki) prosty cel: stworzenie frontona współpracującego z relacyjną bazą danych. Nic więcej, nic mniej. Naginianie Javy do zastosowań do których nie została dobrze zaprojektowana jest ślepą uliczką. Zachęcam do przeczytania książki Więcej niż Java. Jest bardzo interesująca. Zobacz też Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite
A jeśli chcesz porównać hybrydową Javę z rzeczywiście w pełni obiektowym językiem to zajrzyj np. do tych porównań Smalltalka z Javą. zobacz też Smalltalk w pigułce.
Jeśli chodzi o samego Rubiego, to przejrzyj 10 Things Every Java Programmer Should Know About Ruby. Polecam też blog Martina Fowlera (tego od wzorców projektowych i metodyk adaptacyjnych (agile))
Zobacz też artykuł Technologies to Watch: A Look at Four That May Challenge Java’s Development Dominance na onjava.com.
Musze przyznac, ze to bardzo ciekawy artykul. Mialem przyjemnosc poznac SmallTalka i faktycznie ma mnostwo wspolnego z Rubym – najwazniejsza wspolna cecha: Wszystko jest obiektem.
Swoja droga marzy mi sie CMS o mozliwosciach eZpublish/Plone napisany w Railsach (chocby w Django:))
Jeśli chodzi o CMS, to nie spotkałem na razie nic lepszego od Plone. Bardzo prosty aby zacząć i ma bardzo potężne możliwości jak ktoś chce zaszaleć.
Istotnie Plone posiada imponującą funkcjonalność prosto z pudełka.
Do jego wad można zaliczyć zasobożerność, sporą liczbę dodatków (products) w wersjach 0.x alpha – czyli praktycznie bezużytecznych, kłopoty z interfejsem, choćby z menu po dodaniu do niego nowych elementów.
Zgodnie z tym co pisal Paul Graham wiele lat temu, jezyki programowania staja sie coraz bardziej podobne do Lispa i Ruby jest po prostu kolejnym stadium ewolucji :)
Wiec podniecanie sie tym co Lisp potrafi od jakichs 20 lat dla mnie wyglada dosc smiesznie :>
Lisp sux i hoi
lisp od grubo ponad 40u ;)
Tomku.. dlaczego zatem nie programujesz w Lispie (chyba, ze programujesz:))? Wszystko co potrafi Ruby mozna osiagnac za pomoca prawie kazdego obiektowego jezyka zaryzykuje nawet, ze da sie tego dokonac za pomoca prawie kazdego jezyka programowania – wszystko rozbija sie o forme. Dlaczego ludzie przesiadaja sie z jednych jezykow na inne? Oczywiscie powodow jest wiele ale zazwyczaj chodzi o to, ze forma danego bardziej pasuje do tego co akurat chca w nim zrobic.
Jesli chodzi o Plone to troche o nim czytalem ale studiowac Zope tylko dla tego systemu – nie wierze w to, ze kiedykolwiek mialbym mozliwosc uzycia tej wiedzy w innym kontekscie. Poki co czekam na Rails/Django-based CMS.
Twórcy Django stworzyli swój CMS. Nazywa się Ellington. Niestety, ta aplikacja jest płatna. I co gorsze, nie ma żadnej wersji demo ani nawet filmu aby zobaczyć jak to działa i wygląda. :(
W RoR już napisano kilka CMS: Eribium, RailFrog, RCMS czy TrivialCMS. Niestety są cienkie gdy się porówna z przykładowo pehapowymi: ezPublish czy Drupalem. Twórca RailFroga to wręcz się reklamuje że nie jest programistą…
Może powstanie coś mocniejszego, jednak wątpię aby komukolwiek udało zbliżyć się do Plone. Sama idea, na której oparty jest Plone jest doskonała: system jest w pełni obiektowy i zbudowany z obiektowych klocków. Za pomocą archetypów można błyskawicznie dodać kolejny obiekt/komponent i włączyć go do systemu. Oczywiście, Plone to tak naprawdę “produkt” (czy moduł) do Zope. Aktualna wersja jest oparta na starym, Zope2. Ale jak wyjdzie Plone oparty Zope3 to może być to rzeczywisty pythonowy “killer application”. Zope3 jest szybszy i znacznie lepiej zaprojektowany niż Zope2. Jest oczywiście trudniejszy niż RoR czy Django, ale jeśli chodzi o CMS, to może być nie do pobicia. Nie sądzę też aby w RoR szybko udało się stworzyć serwer aplikacyjny który mógłby nawiązać walkę z Zope3. To inna klasa aplikacji.
(BTW, aktualna wersja Plone pożera tyle samo pamięci co pythonowy Mambo, jest więc dużo lepiej niż kiedyś)
PHPowy Mambo jak mniemam:)
Znam te projekty CMSow w Railsach i poki co nie ma o czym mowic (szansa w Eribium ale potrzeba duzo wiecej rozmachu). Railfrog obserwuje od czasu zalozenia projektu i poki co widze rozmowy i nie sadze by kiedykolwiek powstal z tego projektu gotowy system. Django w porownaniu z Railsami ma dwa wielkie plusy – wydajnosc i tworzenie “admin area” (swoja droga dzialajaca genialnie funkcjonalnosc). Dlatego do wydajnego Enterprise CMSa Django wychodzi na prowadzenie. Wiem, ze istnieje Ellington i na tym wiedza o tym systemie sie konczy (do tego zniechecily mnie ceny: miedzy $10k a $15k).
Sam preferuje eZpublisha niz Plone’a – w sumie sama idea jest bardzo podobna: umieszczanie w odpowiednich miejscach odpowiednich obiektow. eZ jesli chodzi o interfejs jest moim zdaniem duzo bardziej przejrzysty – fakt, ze w Plone’a nie wgryzalem sie tak bardzo jak w eZ.
Jesli chodzi o Zope to moim zdaniem nigdy nie zyska takiej popularnosci jaka zyska Rails czy Django – glownie dlatego, ze do nauczenia sie tego frameworka potrzeba ogromna ilosc czasu i stopien jego skomplikowania jest o wiele wiekszy (zgadzam sie oczywiscie, ze tworzony byl dla zupelnie innej “publiki”)
Zawsze pozostaje stworzenie tego czego brakuje… mysle, ze rozsadnie zaprojektowany Rails/Django CMS moglby byc w pewien sposob przelomowy.
Adamh – programuje w Lispie kiedy tylko moge… Ale pisze programy dla duzych klientow, gdzie technologia musi byc “enterprise” (nie wnikam co to dokladnie oznacza) i Ruby, Lisp czy Python nie maja szans na akceptacje.
Co do formy, to masz oczywiscie racje, bo wszystko sprawadza sie do kodu maszynowego. Ale roznica pomiedzy Lispem a innymi jezykami jest taka ze Lisp ma forme odpowiednia do wszystkiego – po prostu bardzo latwo mozesz ja stworzyc – jesz ciastko (dostajesz odpowiednia forme) i nadal masz ciastko (elastycznosc Lispa).
Ja nie mowie ze Ruby jest be, pewnie (nie programuje w Ruby chociaz planuje sie nauczyc – przynajmniej dla praktyki i poszerzenia horyzontow) jest super :) Ale zauwazam tylko ze ludzie przesiadaja sie na jezyki coraz blizsze do Lispa i Ruby wydaje mi sie kolejnym przystankiem.
Czy nie wydaje wam się że rozpoczęła się pewna nowa epoka? Wszyscy piszą nagle frameworki, Cms-y. Powracają do starych języków i odkrywają kolejną amerykę. Php ma zadyszkę, Ror świetny start. Java rozrosła się do tego poziomu, że zaczyna wypluwać jak karabiny maszynowy z siebie coraz to nowsze “wynalazki koła”. A to wszystko pod szyldem “Dont Repeat YOURSELF!!!” – brakuje już tylko do tego Magbeta. Kiedyś sprawa była prosta… teraz trudno jest zaplanować sobie czego i w jakim stopniu należy się uczyć, aby nie zostać w tyle… jedno rozwiązanie lepsze od drugiego… szkoda tylko, że aby się o tym przekonać – potrzebny jest czas…
Frameworki tworzone sa od samego poczatku (zbiory funkcji, zbiory klas itp – klarujace sie w polaczone wieksze twory).
PHP nie ma zadyszki a duze problemy poniewaz pojawiaja sie rozwiazania, ktore wrecz deklasuja uzywanie PHP (bez rozsadnego frameworka), CMSy byly od bardzo dawna – zarzadzanie trescia jest zazwyczaj konsekwencja powstania tresci. Potrzeba bylo tylko naglosnienia tego tematu i wielu projektow darmowych i komercyjnych by management poczul, ze temat musi byc traktowany powaznie.
Co do wynajdywania kola to chyba nie do konca tak… powiedzialbym raczej, ze zmienia sie forma i wszystko idzie w strone postepu. Kazdy web-framework sluzy do tego samego… wazne jak pozwala cel zrealizowac.
Aby przekonac sie o trafnosci kazdego wyboru potrzebny jest czas… wczesniej mozna stawiac na przeczucie to dokladnie tak jak z graniem na gieldzie (poniekad to jest piekne w zyciu, prawda?:)).
Tomku… Ruby i Rails czy Python (choc tu nie do konca sie zgodze) i Django to jeszcze nie rozwiazania klasy “enterprise” ale tak jak PHP trafilo do tej klasy tak duzo szybciej i one trafia. Jak wiadomo na poczatku ery tej nobilitacji jest duze zapotrzebowanie na nowe technologie i rozwiazania poniewaz wiekszosc firm chcialaby byc uznawana za rewolucyjne lub chociaz podazajace za najnowszymi trendami. Pomijajac przyczyny takich zmian… uwazam je za dobre (nie wierze w zasade: lepsze wrogiem dobrego).
Co do Lispa… nie twierdze, ze to zly jezyk – nawet go nie znam – nie spotkalem sie jednak z dobrym fameworkiem do tworzenia aplikacji WWW a tym sie zajmuje (chodzi o konkretne zastosowania).
Tomek, nie zgodzę się. Pythonowy Zope to już jest zdecydowanie klasa enterprise. Używają tego rządy, duże firmy, organizacje pozarządowe. Poza tym, Zope Corporation oferuje także płatne rozwiązania oparte na Zope dla firm i przedsiębiorstw. Zobacz ich Zope Enterprise CMS czy Zope4Intranets.
A ja nie znalazłem w tym tekście jednej istotnej (moim zdaniem) kwestii – kwestii wydajności RoR. A może to przysłowiowa “pięta achillesowa”, o której nikt nie chce mówić/pisać? ;)
Z tą niską wydajnością Railsów to ja bym nie przesadzał. Zobacz mój artykuł: “Skalowanie RoR” który przed chwilą napisałem (zainspirowała mnie do tego Twoja wypowiedź :)
Ciekawy tekst, ale nie porusza on kwestii wydajności RoR, a jedynie przedstawia możliwości skalowania aplikacji napisanych z jego użyciem. Nie mówię, że to nie ma znaczenia – ma, i to spore. Natomiast ja miałem na myśli co innego. ;)
Średnio trafione (moim zdaniem) jest również porównanie RoR i Symphony. Dlaczego akurat Symphony? ;)
Na koniec (żeby nie było niejasności) – nie jestem jakimś przeciwnikiem RoR. Wręcz przeciwnie – uważam, że to świetny framework. Przez swój pierwszy komentarz chciałem jedynie zaznaczyć, że wydajność jest sprawą istotną, a RoR (podobnie zresztą jak większość frameworków opartych o model MVC) nie jest demonem prędkości. ;) Zresztą prawda jest taka, że każdy “pudełkowy” (czy raczej “uniwersalny”) framework spowalnia aplikację (w porównaniu z aplikacją napisaną w “czystym języku”). Ale to już temat na dłuższą dyskusję. ;)
Dlatego Symphony, bo to dosyć zaawansowany framework naśladujący Rails. Chodzi o porównanie mniej więcej podobnych aplikacji.
Co do szybkości, to jeszcze parę lat temu nikt nie brałby na poważnie języków interpretowanych jako alternatywy dla kompilowanych. Popularność interpreterów rośnie bo zostałą przekroczona masa krytyczna wydajności sprzętu. To, że Rails jest wolniejszy nie ma aż takiego znaczenia (1) dla firm, które moga łatwo dostawić kolejny serwer, oraz (2) dla tych, gdzie liczy się bardziej produktywność niż czasowo większa wydajność aplikacji. Tą można przyśpieszyć za pomocą hardware’u. Produktywności zaś nie da się tak łatwo przyśpieszać.
Przyznam szczerze, że nie znam zbyt dobrze Symphony (czytaj: nigdy nic nie zrobiłem przy użyciu tego frameworka), ale bardziej mi tutaj by pasował CakePHP. ;) Ale mogę się mylić.
Z drugą częścią wypowiedzi zgadzam się w prawie 100%. :) Prawie, bo nie jesteś w stanie namówić np. Onetu (to tylko przykład – chodzi o skalę) do korzystania z RoR czy jakiegokolwiek innego tego typu frameworka – oni stawiają głównie na wydajność i taka przesiadka spowodowałaby konieczność dostawienia nie jednej czy dwóch, ale (jak mniemam) kilkunastu nowych maszyn. ;)
CakePHP wygląda na bardziej niedopracowany w porównaniu z Symphony. Ale być może to i tak nie ma znaczenia i byłoby podobnie z wynikami wydajności.
Co do Onetu, to być może baliby się RoR, ale już Django na pewno by zadowoliło ich wymagania wydajnościowe, bo jest nie tylko znacznie lepszy od rozwiązań PHP ale także znacznie od nich szybszy i zdolny do obsługi bardzo złożonych witryn (co widać na przykładach portali jakie używają Django).
RoR dopiero wchodzi w fazę optymalizacji wydajnościowej. Django od początku to brał pod uwagę.
Dużo jednak może zmienić ukończenie YARP’a czyli wirtualnej maszyny Rubiego (tak jak dla Javy) z natywną obsługą wątków. Z tego, co czytałem, to już teraz daje przyśpieszenie kodu Rubiego nawet 10x.
Na jakiej podstawie twierdzisz, że Django jest “znacznie szybszy” od PHP?