Warto dziś jeszcze uczyć się RoR?

Dyskusje
1

Witam całe forum!

Jestem tu nowy, aczkolwiek odwiedzam forum już od jakiegoś czasu.

Chciałem zadać dość trudne pytanie: Czy dziś warto jeszcze uczyć się RoR ?

Mam pewne doświadczenie z Pythonem (+Django i Flask). Zastanawiam się czy nie warto przeskoczyć na Railsy ze względu na większą liczbę ofert pracy w web dev (chociaż nie wiem jaki jest stosunek liczby “rąk do pracy” do ofert pracy) i też o czym nie można zapomnieć - wyższe stawki (z moich obserwacji wynika, że RoRowiec zarabia o 20-40% więcej niż Pythonowiec w PL).

O ile nauczenie się Ruby to nie jest duży problem, widziałem dokumentację i książki i nic tam trudnego nie ma. To same railsy już są chyba trudniejsze, podejście do programowania jest inne niż w Django czy ASP MVC czy starym PHP + Frameworks. Wdrożenie się w gemy (na pewno trochę trzeba ich poznać) i rozwiązania typowe dla RoR (np. widzę, że często korzystacie np. z CoffeScript) trochę czasu zajmie… I pytanie czy warto? Czy warto jeszcze inwestować czas w Railsy?

Przy tej okazji muszę też zapytać o pozycję RoR… Nikt nie jest wróżką, ale czytałem że RoR trochę traci na pozycji, szczególnie na rzecz Node.js. Także mówi się, że za n lat Elixir i Phoenix odbierze dużą część tortu.

Jak oceniacie przyszłość Railsów na najbliższe 10 lat - utrzyma się czy firmy/klienci będą wybierać inne, nowsze technologie? Wszystkie pytania są właściwie w tym kontekście - czy RoR ma przed sobą przyszłość?

Dziękuje za Wasze opinie,
CC

2

podobny post, pojawia się od czasu do czasu na tym forum. Powinieneś zadać sobie pytanie z jakiego powodu chcesz się nauczyć RoR. Na pytanie czy warto można różnie odpowiedzieć i to jeszcze zależy kogo zapytasz.

Wszystko zależy od tego w jakim okresie patrzysz na oferty i w jakim rejonie kraju, czy może poza granicami również

Takie gadanie związanane jest z zauroczeniem pewnych osób innymi technologiami - zależy z kim rozmawiasz, spotkałem ludzi którzy czasami naprawdę mają przeciwstawne opinie. Wszystko zależy od przypadku użycia. Najważniejsze jest dobranie technologii do projektu, a nie projektu do technologii. Dlatego warto znać kilka technologii.

Już od jakiegoś czasu można zaobserwować trend, który pokazuje, że niektóre firmy, które do tej pory miały developerów tylko Rubiowych, zaczeły rozszerzać swój zakres również na Node.js czy Elixira, wszystko zależy od firmy czy programistów w niej pracujących. Osoby które pracują większości czasu w RoR powiedzą ci że Railsy przetrwają. Osoby które mają trochę większe spektrum zainteresować, mogą, ale nie muszą, powiedzieć, że liczba projektów w RoR będzie spadać.

Podsumowując na twój post można odpowiedzieć poprostu: “To zależy”, zależy od bardzo wielu czynników. Na pewno nie warto swojej wiedzy opierać tylko i wyłącznie na Ruby on Rails.

3

Dziękuje za feedback, spodziewałem się takiej odpowiedzi :slight_smile: Wiem, że trudno przewidzieć czy dana technologia się utrzyma, pytałem się o to jak widzicie RoR z perspektywy pracy w rożnych firmach od małych kilkuosobowych do dużych korpo, obsługując bardzo zróżnicowanych klientów. Kto siedzi dłużej w railsach ma dobry obraz całości, zna lepiej trendy, itd. Ale tak jak piszesz, każdy pewnie będzie miał inne zdanie…

Co do ofert - porównywałem tylko te w Polsce. Zgadzam się w pełni, że nie ma co stawiać tylko na jedną technologię.

4

Generalnie - tak. Ogólnie rzecz biorąc, warto się uczyć programowania.

Tobie - nie. Dla kogoś kto zna Pythona, uczenie się Ruby to strata czasu, bo te języki mają praktycznie to samo zastosowanie i są bardzo podobne. Lepiej ten czas poświęcić na coś co otworzy Ci nowe perspektywy i nauczy nowych paradygmatów, np. Clojure, Elixir, Elm (z tych praktycznych), lub Haskell, PureScript, czy Rust (z tych mniej praktycznych).

Jeśli chodzi Ci tylko i wyłącznie o kasę, to Clojure lub Elixir - tam odchodzą co bardziej doświadczeni programiści Rails i to tam będzie brakować programistów w następnej kolejności (tzn. płace dla kumatych pójdą w górę). Nie sądzę, żeby przerzucenie się z Rails na node.js dawało jakikolwiek wzrost finansowych perspekty.

5

Jeśli chodzi o Clojure, Haskell, Rust (o PureScript nawet nie słyszałem) to jest to straszna egzotyka moim zdaniem. Wolałbym poznać coś co ma na rynku jakąś pozycję (oferty pracy, community, itd.).

Zgadzam się, że dobrze zapoznać się z programowaniem funkcyjnym, ale jeśli już to wolałbym chyba Elixir czy Scalę, chociaż te technologie na dobrą sprawę też się nie przebiły (mimo, że Scalę trudno nazwać nowością).

Generalnie nie mam nic przeciwko temu samemu zastosowaniu, chcę działać po prostu w webdev.

6

To jeszcze ja dorzucę jedno pytanie: Czy warto uczyć się samego Elixira bez uprzedniej znajomości Ruby/RoR? Aktualnie pracuję w całkowicie innej technologii (SAP/ABAP), ale ostatnio zainteresowałem się językami funkcyjnymi i tak wpadłem na Elixir. Chcę się rozwijać w tym kierunku i kiedy przyjdzie czas zmienić też pracę, ale nie wiem, czy znajomość samego elixira wystarczy. Jest jeszcze inna opcja - nauka RoR, zmiana pracy/wejście w ten świat i dopiero wtedy nakierowywanie na Elixir.

7

Wiem, że Elixir+Phoenix są trochę wzorowane na Ruby on Rails, ale tylko wzorowane. Różnice są spore i w zasadzie RoR tak bardzo nie jest Ci potrzebny do szczęścia. Natomiast z Elixirem jest jeden duży problem - w obecnej chwili ofert pracy jest jak na lekarstwo. Trzeba poczekać aż się to wszystko rozkręci. Obecnie Elixir w 90-kilu procentach to jest tylko webdev i to w połączeniu z jednym frameworkiem PHOENIX. Do tego dobrze znać Elm, ale nie jest to już konieczne. Niektórzy coś tam próbują z IoT oraz machine learning, ale to jest w powijakach.

Więcej dopiszą koledzy

8

Prosta piłka.

Jak chcesz programować w Elixir, to ucz się Elixir.
Jak chcesz programować w Ruby, to ucz się Ruby.

9

To są zupełnie dwa różne języki. Zupełnie inna filozofia pisania aplikacji. Uczenie się pisania w Rubimy napewno nie pomoże w nauce Elixira per se*. To że składania z wierzchu może się wydawać podobna, wcale nie sprawia że języki są podobne. To tylko złudzenie. Języki funkcyjne to jest zupełnie inne zwierze niż języki obiektowe.

*Pomoże nauka programowania, która jest efektem ubocznym uczenia się rubiego :wink:

10

RoR przeżyje, ale… :slight_smile:
Jakiś czas temu, czyli kilka miesięcy temu zadawałem głównie sobie to samo pytanie. Zwłaszcza po przeczytaniu setek artykułów za i przeciw RoR. Doszedłem do wniosku, że warto poznać i zacząć używać.
jeśli chodzi o backend to jestem w pełni przekonany.

Moje założenie nie było takie, że chce szukać potem pracy jako programista. Lubię programować w ograniczonym zakresie, ale nie był to mój główny cel, ja głownie zarządzałem i tworzyłem projekty. Dla mnie ważne było to, aby szybko rozwiązać problem, chciałem poznać ideę i jak to działa, aby móc potem z programistami rozwiązywać problemy. Aby nie słuchać potem “nie da się”, ale to zajmie wiele miesięcy lub poprawki będą sporo kosztować. A w rezultacie okazywało się, że problem da się rozwiązać nawet w jeden dzień, dlatego dla mnie to była konieczność zapoznać się z filozofią RoR.

Ale zacząłem się uczyć języka Ruby (wcześniej też Python i napisałem wiele użytecznych skryptów), potem przeszedłem do Sinatry, a na koniec do RoR.

Jakie są moje odczucia po tych wielomiesięcznych doświadczeniach. Każdy wie, że RoR jest dojrzały, co wszędzie piszą i naprawdę można szybciej i nawet znacznie szybciej stworzyć aplikacje webowe niż w innych frameworkach. Ale teraz dochodzimy do sedna, do czego nam jest potrzebny RoR? Co chcemy osiągnąć?

Bez javascript jest trudno!
Ja miałem łatwiej, bo wiedziałem czego chcę, a mianowicie chodziło mi o kursy językowe, szkolenia itp.
Samo programowanie backendu było i jest przyjemne, ale frontend to inna sprawa, jakby osobna, okazało się, że tu bez javascript niestety nie da się dalej nic zrobić w moim przypadku. Potem, gdy zacząłem dalej drążyć, to przy wielu użytkownikach i działaniach sprawdzających wyniki na bieżąco w czasie rzeczywistym zadania/naukę szybkość działania ma znaczenie.

W moim wypadku okazało się, że javascript jest ważniejsza z uwagi na interaktywność. Backend niestety też musiał być szybszy i tu niestety wnioski były następujące RoR do mojego zadania mniej się nadawał niż Elixir/Phoenix (po zrobionych testach), gdzie czas reakcji jednak się liczy, gdzie oczekiwanie 1,2 sekundy to za długo, gdzie odpowiedź musi być natychmiastowa, przykładem są gry działające w czasie rzeczywistym lub np. serwery aplikacji czy gier, w Phoenix/Elixir działa to rewelacyjnie. Ale ido RoR można dołączyć podobne mechanizmy działania w czasie rzeczywistym.

Natomiast dobrze RoR się sprawił do zarządzania użytkownikami i postępami, wyszukiwaniem, tu jest masa gotowych rozwiązań. Więc do pewnych zastosowań RoR nadal jest najlepszy.

Alternatywy
Pomimo, że przeczytałem blog Piotra Solnicy, o jego wycofaniu się z RoR, poznałem argumenty za i przeciw innych, to moim zdaniem RoR przetrwa jak PHP.

Co do szybkości, jeśli powiodą się testy np z Ruby+Truffle lub z jruby lub innym kompilatorem, i np. w wersji np RoR 6.X uda się zoptymalizować szybkość działania, to wtedy RoR może być jeszcze mocniejsze i uniwersalniejsze. Są już obiecujące przesłanki: http://jruby.org/bench9000/ Szybkość poprawiona nawet 30 razy!

Ale jedno jest pewne trudno uciec od javascript, ale node,js dla mnie osobiście jest jeszcze nie do końca dojrzałe, samo pisanie w js też nie sprawia przyjemności jak w ruby. Co prawda patrzę na rozwiązania typu Meteor i to wygląda coraz lepiej.

Ale to co mógłbym polecić i widzę rozwiązania RoR z vue.js, Samo vue,js jest godne poznania.

A może GO?
I jeszcze na koniec, Elixir/Phoenix to podobno ma być przyszłość, ale czy na 100%? Tego nikt nie jest w stanie obecnie przewidzieć. Moim zdaniem jest silniejszy konkurent, który może być znaczącym graczem, który ma ogromne wsparcie techniczne i finansowe. A jest nim GO. Właśnie nad nim siedzę już od pewnego czasu i sądzę, że ma naprawdę szansę stać się silnym graczem. Jest już na 15 pozycji jeśli chodzi chodzi o popularność. ale idea mi odpowiada. Dla programistów RoR to też może być alternatywa.

Na koniec
Podsumowując, RoR jest nadal wspaniały i moim zdaniem przetrwa, ale na rynku jest też duża konkurencja i bardzo dobrze. Co ciekawe ta konkurencja powstała z inspiracji RoR. Trzeba sobie odpowiedzieć na pytanie czy che się być od backendu, czy full stack? Jeśli full to javascript jest w zasadzie niezbędna, a jesli jest niezbędna to jedna frameworki js jak vue lub Meteor są do rozważenia, pomijam kobyły typu Angular 2 (niekomptybilny z Angular), React itp. Jednak jak to w życiu nic nie jest do końca pewne, poza jednym … :slight_smile:

Więc trzeba się rozwijać i doskonalić poznając alternatywne rozwiązania.

5 Likes
11

Czy warto - to zalezy od tego co chcesz robic. 5-6 lat temu, Railsy (poza Django) byly oczywistym wyborem, dla kogos, kto tworzyl aplikacje webowe. Dzisiaj, wybor jest o wiele trudniejszy i wiele osob wybierze jakis framework MVC: angular, react, ember + cos do tworzenia API. Railsy sa nadal dobre do API, ale juz nie bezkonkurencyjne jak kilka lat temu.
Oczywiscie nadal powstaja nowe apki w Railsach - w koncu jest pelno doswiadczonych programistow na rynku.

Golang
Oczywiscie, nie bylbym soba, jesli bym nie wykorzystal okazji do promocji Go - jezyka, ktory nie tylko moim zdaniem bedzie za pare lat lingua franca IT. Naprawde warto sie go uczyc. Elixir, Rust, Clojure sa bardzo ciekawymi jezykami, ale moga miec problem przebic sie do mainstreamu - programisci tych jezykow to glownie programisci-pasjonaci, a ich niestety jest za malo by rynek zaadoptowal te jezyki. W go juz obecnie powstaje bardzo duzo nowych projektow, open & closed source.

13

Zgadzam się z kolegą., właśnie co do GO mam swoje przemyślenia, bardzo pozytywne, dlatego teraz nad nim siedzę. Ma sporą szansę stać się jednym z głównych, już obecnie staje się coraz ważniejszy. RoR jest i długo będzie obecny, ale będą mu deptać po piętach nowsze frameworki i języki.

14

Co do GOlang, to interesowałem się nim krótko jakieś pół roku temu. I większość opinii była typu “kolejny język, który nie wnosi nic nowego”. Raczej przyjęty na wielu forach i blogach bez entuzjazmu.

Inna sprawa to, że stoi za tym Google i ostatnio GOlang idzie mocno w górę w rankingu TIOBE: http://www.tiobe.com/tiobe-index/

W ciągu roku GO skoczył z 48-mej pozycji na 13 :slight_smile: Dla porównania Elixir skoczył z 86 na 64 w ciągu jednego miesiąca (ale czy wskoczy do TOP20 w najbliższym czasie - wątpliwe). Ruby w ciągu roku spadło z 9. na 14-stą pozycję.

15

Język jest bardzo przyjemny, można dostać 30EUR/h. Warto!

16

Ja myślę, że Elixir może się zbliżyć w okolice TOP20, wystarczy, że otrzyma jakieś większe wsparcie finansowe od zainteresowanej dużej firmy. Nie do końca bym przekreślał jego rozwój.

Co do GO to też sądzę, że dojdzie do TOP10 i to już niedługo. Obserwuję trendy od dłuższego czasu i zainteresowanie.
Ktoś na jednym z forum napisał, że Go osiąga teraz szczyty popularności, a Elixir dopiero ma to przed sobą.

Ale wracając do tematu. RoR będzie się trzymał czołówki i TOP20 jeszcze długo, wszystko będzie zależało od jego dalszego rozwoju. Roboty jest mnóstwo, ze względy na wcześniejsze wdrożenia. Ale byłbym otwarty jednak na nowe rzeczy.

Ci, którzy są doświadczeni w RoR nie muszą jeszcze panikować, mają sporo lat przed sobą. Ci, którzy zaczynają “zabawę” z RoR mają twardszy orzech do zgryzienia, bo na dojście do mistrzostwa trzeba czasem lat.

Jeśli wiele z tych nowych frameworków inspirowało się RoR i się ulepszyło, to może RoR powinien się zainspirować tym co ma największe szanse na wzrost. Rynek zrobi swoje i warto będzie obserwować trendy i zmiany.

17

Jeśli chodzi o GOlang - szybko wspiął się w górę, ale jakbyście mieli wymienić pięć jego cech których nie ma konkurencja, to pewnie byłoby to niełatwe zadanie. Ja poza ułatwionym concurrency (go routines) nie widzę specjalnie wielkich zalet GO. No jeszcze to, że jest szybki, głównie dzięki temu, że jest kompilowany.

Poza tym pozycja w TIOBE nie przekłada się na liczbę ofert pracy w Polsce. Na 4p jest > 70 ofert dla ROR i kilka dla GOlang ( i jedna dla ROR ze znajomością Elixir).

Jak już wątek trochę zszedł na konkurencję dla ROR. To znacie jakieś interesujące frameworki webowe dla GO? Co jest na topie? Często wymieniana jest Gorilla, Iris (podobno bardzo szybki), Beego. Ale żadnego z nich nie znam. Martini jest wymieniane jako odpowiednik Sinatry (ze świata Ruby) oraz Flaska (python).

Zagadką w GO jest dla mnie użycie pointerów bez możliwości użycia arytmetyki na wskaźnikach (jak w C++). Po co więc wprowadzili pointery?

18

Podobają mi się powątpiewania co poniektórych czy warto uczyć się Rubiego/Railsów podczas gdy na forum jest sporo ofert pracy za kwoty rzędu 10.000-20.000zł. Oczywiście płaca nie jest jedynym wyznacznikiem decydującym o tym czy warto się uczyć danej technologii, ale napewno ma spore znaczenie.

Dziwię się także osobom, które przewidują, że w niedalekiej przyszłości technologia X będzie hitem (tutaj Elixir i Golang). To są bardzo fajne języki, ale za dużo mam lat i wiem, że nie ma już czegoś takiego jak technologiczne switche. Jasne, jakiś tam kawałek tortu zostanie uszczknięty przez nie i tyle (inna sprawa, że ten tort przez ostatnie lata cały czas rośnie).

Co do rankingu Tiobe. Warto od czasu do czasu rzucić na niego okiem, ale to nie jest żadna wyrocznia. No chyba, że ktoś chce mnie przekonać do Visual Basic (6 miejsce), PHP (7 miejsce) czy Perla (10 miejsce).

Wracają jednak do Rubiego. Siedzę w nim blisko 10 lat i patrząc perspektywistycznie mamy wspaniały język o dosyć sporej renomie. 10 lat temu byłeś wybrańcem jak mogłeś zarabiać jako programista Rubiego. Dzisiaj w pewnym sensie firmy się o nich biją. Nie wiem jak to wygląda w innych miastach, ale na KRUG przychodzi ponad setka osób i to tylko dlatego, że jest zakładany limit (nierzadko liczba chętnych dochodzi do 200 osób).

Z mojej perspektywy warto się uczyć Rubiego, aczkolwiek w pewni zgadzam się z @sharnik, że warto w ogóle uczyć się programowania ;).

19

Masz rację oferty pracy są tutaj niezłe :slight_smile: Jeśli chodzi o web dev to jedne z najlepiej opłacanych ofert w Polsce się tu pojawiają.

Wątek zacząłem wybiegając nieco w przyszłość. Nie pytam o obecną sytuację, tylko pytałem się o przyszłość RoR, jak ją widzicie, śledząc od lat co się dzieje w ekosystemie Rubyego i Railsów.

Jasne, że TIOBE to nie wyrocznia. A VB i VBA to jakaś kpina (ale to chyba ze względu na użytkowników Office-a - makra, itp.). PHP jest może “starociem” i mało ciekawą technologią, ale pozycję swoją ma nadal wysoką. Perl to kolejne zaskoczenie.

Jak masz 10 lat doświadczenia to inaczej na to patrzysz. Senior zawsze znajdzie pracę, choćby przy utrzymaniu kodu, jak zabraknie nowych projektów. Ja pytałem o co innego, ale generalnie odpowiedź w tym wątku uzyskałem.

Podstawy ROR-a można pewnie “złapać” w 2 miesiące (ale to raczej nie wystarczy nawet do pracy jako junior), a żeby być dobrym to już - tak jak ktoś tu pisał - potrzeba kilku lat.

20

Elixir i Phoenix to teraźniejszość, nie przyszłość. Co do Rubiego- jeszcze rok temu napisałbym, że warto się go uczyć- dzisiaj nie zachęcam, a zwłaszcza nie w Twoim przypadku.
Elixir i Ruby to dwie różne historie, bo Elixir to Erlang z ładną składnią, a nie funkcyjny Ruby. Aby w nim kodzić dobrze znać trochę o OTP- monitorowaniu, nadzorowaniu i zarządzaniu procesami. Do tego dochodzi zmiana, jaką jest programowanie funkcyjne. Imo: Phoenix jest dużo dojrzalszy niż railsy, w których zbyt wielką rolę odgrywa magia.

21

Miałem okazję popisać trochę w GO.w pracy, a hobbystycznie piszę w Elixirze. Zasadnicza różnica jest taka, że go jest szalenie imperatywny, a Elixir szalenie deklaratywny.

Ile się trzeba nadziobać w Go żeby napisać proste rzeczy to jest dla mnie nie do pojęcia. Zupełnie nie “leży” mi ten język przez to, pisząc aplikację wielowątkową trzeba nadal bardzo uważać, żeby przypadkiem różne wątki nie pracowały wzajemnie na tym samym obszarze pamięci i dbać o blokowanie dostępu, drobny błąd w kodzie, albo brak lub niepoprawne obsłużenie tego co dostajemy z zewnątrz może nam wywalić całą aplikację.

W Elixirze natomiast nie ma takiej opcji że którykolwiek z procesów (chodzi o te erlangowe/elixirowe procesy, nie systemowe) będzie współdzielił pamięć z innymi. Każdy z procesów też sam dba o pamięć i jej zwalnianie więc nie ma mowy o stop-the-world garbage collection znanym z GO. Jeżeli jakiś proces z różnych powodów walnie errorem to nikt się tym nie przejmuje, supervisor podniesie nowy proces w jego miejsce. Żeby doprowadzić do sytuacji, że aplikacja się wywali to trzeba naprawdę chcieć. Skalowalność aplikacji na wiele maszyn nie stanowi tu żadnych, naprawdę najmniejszych problemów.

Nie znam za dobrze frameworków w GO, bo pracowałem tylko z Gin, ale nie widziałem w GO niczego na skalę Railsów, Django czy tym podobnych, Z kolei elixirowy Phoenix wiele wyniósł dobrym rzeczy z railsów, ale jest tu ogromny nacisk kładziony na modularność. Phoenix ma być webowym frameworkiem dla twojej aplikacji, a nie wielkim railsowym monolitem w którym po roku czasu człowiek boi się coś refaktoryzować :wink: Duży nacisk jest kładziony na to, żeby rządzania HTTP przekształcać w jasny i klarowny sposób z requesta na response. Nie ma tutaj miejsca na magię znaną z Railsów. Wydajność jeżeli chodzi o ilość połączeń można obsłużyć na konkretnej maszynie jest tez niebagatelnie większa niż railsy na to pozwalają. Można zapomnieć o redisie sidekiqu i resque, bo if funkcjonalność mamy na dzień dobry i wynika to z tego jak język został zaprojektowany.

Nie twierdzę że Elixir i Phoenix wyprą Rubiego i Railsy, tylko, że w Rubym i Railsach problemy wydajnościowe zaczynają się dużo, dużo wcześniej niż w Elixirze a sam Phoenix zamiast dokładać się do tego, daje nam proste rozwiązania tych problemów. A w Go… po prostu nie wyobrażam sobie jakiejś naprawdę dużej aplikacji, ale tak jak pisałem język mnie szybko zniechęcił.