Sama idea ruby on rails jest ogólnie fajna... Problem w tym że developerzy gemów czasami prześcigają się w głupich pomysłach. Przykłady:
- Do testów mamy wiele możliwości - nie ma standardu, ale powiedzmy że lubimy albo Test::Unit albo RSpec. chcemy sprawdzić czy wszystko ładnie pieknie działa, w końcu wszyscy w RoR kochają testy, no i mamy kwiatki: testy potwfią się sypnąć tylko dlatego że masz verbose output. Wyłączysz, to innych paczek się sypną o to że nie masz verbose output. sweet.
- Mamy sobie Ruby, JRuby, RubyEE. załóżmy że każde z nich w wersji 1.9, powinny być zgodne. Nie są. 60%gemów działa na Ruby, 35% na JRuby, a 5% specjalnie pisane pod EE sweet...
- Hipsterskie wersjonowanie: mamy sobie gem w wersji dumnej 1.2.3. Pełno w nim bugów, trochę twórca nie pomyślał (ach to agile) że z gema będzie korzystać ktoś jeszcze i trzeba by przebudować ciut gem żeby się do czegoś nadawał. Czyli zmieniamy nazwy, parametry wywołania itp itd, ogólnie psując wszystko po drodze. I nowa wersja: 1.2.4
- Hispterskie zależności: Oczywiście RoR to nie wynajdowanie koła od nowa, czyli jak coś już jest zrobione, to zależność ustawiamy i gotowe. Powiedzmy teraz tak: robimy sobie aplikacje na RoR, potrzebujemy jakiegoś sexy gema w najnowszej wersji. Nie ma problemu gem X v 1.2.4. Ma dependency na Y wersja 0.8.9 (Y teraz jest w wersji 2.7.10) i na Z w wersji 1.5 (a Z mamy teraz w wersji 1.9). Teraz lepsza bajka - Z >=1.6 jest zależne od Y >=2.5. Pięknie. Rozwiązanie - branch na githubie własny do gema X. Prośba do upstream o merge, odpowiedź (dosłowny cytat tego co dostałem): "I dn't car efork it yerself an maitain". Sweet.
- Chcemy sobie przeprowadzić test jednego gema. Wszystko cacy, dependency cacy itp itd... Ale! nie może być znów super: twórca testu wymaga pliku xyz.foo. plik ma w środku dane! gdzie jest plik xyz.foo? Na dysku twórcy i nigdzie indziej. Poszła prośba o ten plik, ale zero odpowiedzi. Zdarza się.
- Logowanie - o ile każdy sensowny webapp na innych językach loguje do error_log apache, o tyle w RoR nigdy mi się nie udało do tego doprowadzić. Może to ja jestem dziwny, ale logi w dziwnych miejscach to norma la railsów. I jeszcze pierdyliard gemów do custom logów...
- Gem vs systemowe pakiety: 0 kompatybilności i miliard problemów. W gentoo jest ok - da się przeżyć. W Debianie - jesteś 50 lat za gentoo, w Centos/RHEL - nie liczyłbym na systemowe paczki (w skrócie jeśli Twój provider miejsca używa centos/RHEL jako środowiska, na 99% aplikacja w RoR nie działa i nic się nie da z tym zrobić). Oczywiście jak masz odpowiedni dostęp to zainstalujesz co potrzebujesz z gemów (jak przeżyjesz) . Update systemu i paczek - problem.
- Maintaining aplikacji, czyli postawisz i powinno działać. Tak nie jest w przypadku RoR. Nigdy. Najdłuższy czas jaki mi działało cokolwiek zrobione w RoR bez ingerencji to redmine, głównie dzięki temu że wszystko co potrzebuje i zależności jakie ma ma zbundlowane ze sobą.
Osobiście cholernie podoba mi się podejście perla - tam jak coś postawisz to działa ślicznie, ale za to język jest tak cholernie nieczytelny (dla mnie) że aż boli. O pythonie się nie wypowiem, bo nie wiem, ale moi znajomi zarzekają się że świetny jest. PHP - jaki jest każdy widzi.
A co do samego RoR i Ruby: język i założenia świetne, jeszcze tylko było by miło jakby wszyscy postępowali zgodnie z założeniami, to by Ruby i Rail wyparły php z programowania webappowego (może kiedyś... lecz nie teraz)