RoR - perspektywy

Dyskusje
21

@apohllo zgadzam się, moim zdaniem wszystkie zacytowane argumenty są kompletnie bez sensu

W linku który wkleiłem część zarzutów punktują sami phpowcy. Chciałem tylko pokazać Muirin, że w internecie jest masa opinii nie popartych żadnymi argumentami i pisana przez ‘ekspertów’ z bożej łaski. Nie ma się nimi co przejmować. Jeśli będziesz zastanawiać się czy warto się czegoś uczyć po przeczytaniu każdej opinii na nie, to nigdy się niczego nie nauczysz i cały czas stracisz na zastanawianie się “czy warto”.

22

Większość z tych rzeczy to albo bzdury, albo FUD, albo rzeczy, które w PHP nie są lepiej zrobione. Michał, wiem, że to nie Twoje argumenty, ale się do nich odniosę, żeby komuś kto jest nowy w railsach się nie wydawało, że jest tutaj zbyt dużo sensu :wink:

[quote=maykel]Niby wszystko fajnie, ale nie można też zapominać o minusach:

[quote]1a. Argumenty pehapowców przeciw Ruby on Rails.

  • Brak polskich książek (te obydwie na rynku są do wersji przestarzałych).[/quote]
    [/quote]
    Tutaj mogę się zgodzić, do RoR nie opłaca się kupować książek, szczególnie w polsce.

[quote]- Hostowanie to dodatkowa praca, dodatkowy czas, dodatkowe problemy.

  • Hostowanie to koszmar i drożyzna.[/quote]
    To już dawno nieaktualne. Oczywiście nie ma zbyt wielu rozwiązań takich jak “shared hosts” dla PHP, ale też nie jest to koszmar i drożyzna.

Jasne, wtedy można użyć Sinatry :wink:

Zed chyba nigdy nie był założycielem frameworka i zgodzę się, że było trochę kiepskich PRowo zagrań ze strony core teamu, ale nie wpływa to raczej za bardzo na jakość kodu.

Zdarza się przepisywanie gotowych już projektów z PHP na RoR.

LOL :smiley:

[quote]- Brak kompatybilności jakiejkolwiek wstecz. Pojawienie się nowej wersji RoR grozi powrotem do korzeni (może nie trzeba uczyć się od nowa wyświetlania “Hello World”, ale trzeba
douczyć się ogromnej ilości nowych rzeczy i zapomnieć o tych starych rozwiązaniach).[/quote]
Tutaj częściowo się można zgodzić, bywały z tym problemy, a przesiadka z Railsów 2 na 3 jest z reguły trudna. Ale nikt nie rezygnuje z komptaybilności wstecz ot tak sobie, bez powodu i między wersjami patch…

Straszna wada :frowning:

? O_o

Może i częściowo jest prawdą, że często projekty trzeba sobie samemu skonfigurować na serwerze (mówię oczywiście o samych railsach, serwer pod railsy może postawić każdy ogarnięty administrator), ale to też wynika z tego, że większość programistów rails używa capistrano i/lub innych niestandardowych narzędzi.

23

Pomyślałem sobie jeszcze, że skoro programuję już trochę w railsach, to mogę napisać kilka rzeczy, które dla mnie są minusami:

  • railsy są molochem i ciężko to będzie zmienić. Dużo się poprawiło po wejściu railsów 3, teraz widzę fajny ruch w stronę odchudzania, wyrzucania niepotrzebnych kawałków i większej modularyzacji, ale dalej to nie jest ideał
  • ze względu na kilka decyzji projektowych, które ciężko jest teraz odwrócić bez wyrzucenia dużej ilości kodu i zerwania z kompatybilnością wstecz, bardzo trudne jest zaimplementowanie montowania aplikacji w innych aplikacjach (między innymi dlatego w railsach 3.1 zostaliśmy tylko przy montowalnych engine’ach)
  • autoload nie jest threadsafe, dlatego nawet jeżeli w trybie development nie ładuje się calutki framework, to w production jest to konieczne, dlatego czas ładowania aplikacji produkcyjnej będzie zawsze sporo wydłużony
  • same railsy mają w niektórych miejscach problemy z wątkami. W 3.x jest już tych miejsc niewiele, ale jest kilka rzeczy, które zostały poprawione dopiero niedawno (takich, które nie zostały jeszcze poprawione, a o których wiemy już z tego co pamiętma nie ma)
  • asset-pipeline - tak jak już kilka razy się wypowiadałem, moim zdaniem jest to jeden z najgorzej zaimplementowanych feature’ów w ostatnich wersjach. Dużo problemów zostało już poprawionych, ale cały czas nie jest to moim zdaniem dobre wykonanie
  • activerecord ma dość dużo bugów (na obecną chwilę 243 issues na 470 otwartych, to właśnie AR). Są to najczęściej różnego rodzaju edgecase’y, więc nie jest oczywiście tak, że jak się pisze aplikację, to co chwila się natrafia na jakiegoś buga, ale mogłoby być lepiej

Tak na szybko tyle mi przychodzi do głowy. Nie są to oczywiście rzeczy, które powinny kogokolwiek zniechęcić do nauki, podobne listy można tworzyć do każdego języka czy frameworka, ale pomyślałem, że warto napisać kilka punktów dla zrównoważenia opinii :slight_smile:

24

@drogus dlatego do mniejszych projektów polecam Padrino - zbudowane na bazie Sinatry.
Mniej magii, ale za to dużo łatwiej się połapać co i jak.

A co do assets to się podpisuję pod Twoją opinią obiema rękami. Ostatnio walczę Railsami żeby mi wyświetliły favicone! WTF?!

25

Ja bym wrzucił do ./public - działało od lat. Przynajmniej favicon.ico - jeśli ktoś chce być miły dla IE. A favicon.png wrzucam do <link rel="icon" type="image/png" sizes="16x16" href="/assets/favicon.png" /> i działa. Przynajmniej u mnie…

26

[quote=apohllo]@drogus dlatego do mniejszych projektów polecam Padrino - zbudowane na bazie Sinatry.
Mniej magii, ale za to dużo łatwiej się połapać co i jak.[/quote]
Padrino do mnie za bardzo nie przemawia. Do małych projektów wystarczy mi z reguły sinatra. Jeżeli mam korzystać z czegoś, co jest na tyle duże, że potrzebuje reloadera i ogólnie funkcjonalnością podchodzi pod railsy, to musiałbym mieć naprawdę mocne powody, żeby się przerzucić z railsów.

27

Ja bym wrzucił do ./public - działało od lat. Przynajmniej favicon.ico - jeśli ktoś chce być miły dla IE. A favicon.png wrzucam do <link rel="icon" type="image/png" sizes="16x16" href="/assets/favicon.png" /> i działa. Przynajmniej u mnie…[/quote]
No działało, działało, ale nie dział (RoR 3.2.2 - może porawili coś w której z nowszych wersji?)

EDIT

Najwyraźniej poprawili to w czymś pomiędzy 3.2.2 a 3.2.6. EOT

28

Od trzech lat popularność wg. google utrzymuje się na stałym poziomie. http://www.google.com/trends/?q=Ruby+on+Rails&ctab=0&geo=all&date=all&sort=0

29

Złapiesz też bardzo złe. Globale i kod, który nie jest thread safe.

30

na to pytanie niestety nikt Ci nie udzieli odpowiedzi… o Twojej wartości tak naprawdę świadczy jak co zrobisz a nie w czym (Czekam na gromy xd) ja po przeprowadzce w okolice berlina “odkurzam” RoRa :slight_smile:

31

no jesli kots sie przeprowadza do Berlina to podejrzewam, ze duzo ciezej jest byc bezrobotnym programista Railsow niz miec dobra robote :wink:

32

Złapiesz też bardzo złe. Globale i kod, który nie jest thread safe.[/quote]
A teraz pokaż mi język, w którym wszyscy od początku wpajają jak pisać kod, który będzie thread safe. Co do “globali”, to nie do końca rozumiem.

33

jak tak dalej pójdzie to w Europie będzie się studiować tylko zarządzanie a całe programowanie outsorcing w Indiach :wink:

34

Widać, że z Hindusami nie pracowałeś.

35

jak tak dalej pójdzie to w Europie będzie się studiować tylko zarządzanie a całe programowanie outsorcing w Indiach ;)[/quote]
Czy G dzieli wynik przez ilość mieszkańców kraju? Nie sądzę, a taki wynik pokazywałby inny obraz. Jeśli popatrzeć na języki, to widać, że Polska ma dosyć silną pozycję - podobnie jak Szwecja, Holandia oraz Finlandia, które do dużych krajów nie należą. Dobrze widać to jeśli porówna się wyniki dla japońskiego i Japonii.

Liczby nie kłamią, ale statystyki trzeba umieć interpretować.

36

Złapiesz też bardzo złe. Globale i kod, który nie jest thread safe.[/quote]
A teraz pokaż mi język, w którym wszyscy od początku wpajają jak pisać kod, który będzie thread safe.[/quote]
erlang

37

Miałem tam jeszcze dopisać język obiektowy, ale gdzieś mi umknęło :slight_smile: Zdaję sobie sprawę, że jest grupa języków, która została stworzona po części do rozwiązania problemów związanych ze współbieżnością. Ada, erlang, w jakimś stopniu pewnie Go (chociaż nie za bardzo się interesowałem tym językiem). Tylko że większość języków, które można trochę łatwiej zrównać z ruby (python, php, java itp) ma moim zdaniem podobny problem. Podejrzewam, że ucząc się scali może być z tym trochę lepiej, bo istnieje tam koncept aktorów znany z erlanga, ale szczerze mówiąc jak trochę się uczyłem scali, to nie zauważyłem dużego nacisku na współbieżność w tutorialach/książkach (ale być może nie doszedłem odpowiednio daleko).

Pewnie trochę kiepsko wyraziłem myśli tym krótkim pytaniem, ale chodzi mi o to, że nie znam języka, od którego powinno się zacząć przygodę z programowaniem i w którym od początku kładzie się nacisk na pisanie współbieżnego kodu. Mam nadzieję, że to się będzie zmieniać, szczególnie w środowisku rubiego, ale wydaje mi się, że to jest bardziej kwestia podejścia do programowania w ogóle - współbieżność od stosunkowo niedługiego czasu zaczyna być traktowana poważniej.

38

Miałem tam jeszcze dopisać język obiektowy, ale gdzieś mi umknęło :slight_smile: Zdaję sobie sprawę, że jest grupa języków, która została stworzona po części do rozwiązania problemów związanych ze współbieżnością. Ada, erlang, w jakimś stopniu pewnie Go (chociaż nie za bardzo się interesowałem tym językiem). Tylko że większość języków, które można trochę łatwiej zrównać z ruby (python, php, java itp) ma moim zdaniem podobny problem. Podejrzewam, że ucząc się scali może być z tym trochę lepiej, bo istnieje tam koncept aktorów znany z erlanga, ale szczerze mówiąc jak trochę się uczyłem scali, to nie zauważyłem dużego nacisku na współbieżność w tutorialach/książkach (ale być może nie doszedłem odpowiednio daleko).

Pewnie trochę kiepsko wyraziłem myśli tym krótkim pytaniem, ale chodzi mi o to, że nie znam języka, od którego powinno się zacząć przygodę z programowaniem i w którym od początku kładzie się nacisk na pisanie współbieżnego kodu. Mam nadzieję, że to się będzie zmieniać, szczególnie w środowisku rubiego, ale wydaje mi się, że to jest bardziej kwestia podejścia do programowania w ogóle - współbieżność od stosunkowo niedługiego czasu zaczyna być traktowana poważniej.[/quote]
Erlang ma też zupełnie inne zastosowania niż Ruby i nie wiem, czy współbieżność na poziomie wątków jest aż tak potrzebna, w szczególności w architekturze serwisowj. Oczywiście miło jest mieć serwery takie jak np. Goliath, który potrafi obsłużyć 3000 req/s (on akurat bazuje na fibersach) ale przeniesienie problemów współbieżności na middleware jest dość wygodnym rozwiązaniem. Ciekawe co w tym zakresie (za)oferuje Dart.

39

Widać, że z Hindusami nie pracowałeś.[/quote]
This. W Indiach jest mnóstwo przeciętnych czy kiepskich programistów, bo rzucili się na programowanie jako zawód pozwalający zarobić odjechane względem lokalnego rynku pieniądze.

40

Ciekawa dyskusja na ten temat jest w jednym z pull requestów: https://github.com/rails/rails/pull/6685

UPDATE:

TL;DR: wielowątkowość przydaje się nawet jak możemy łatwo odpalić wiele procesów. Zmniejsza to zużycie pamięci i pomaga w sytuacji gdy mamy akcje, które mogą długo “wisieć” na IO, szczególnie wszelkiego rodzaju requesty do innych serwisów.