Serwis Dice opublikował listę pięciu języków które prawdopodobnie przestaną być wykorzystywanie. Jedną z pozycji listy jest Ruby. Sądzicie że ten język zostanie porzucony a programiści przejdą np na Pythona?
Jak wygląda sytuacja z rynkiem pracy, z pozycji osób które mają doświadczenie z tym językiem?
dziwna jest motywacja czemu Ruby miałby przestać być wykorzystywany. Poza tym taki artykuł, że Ruby “umiera” pojawia się co jakiś czas, a jak na razie Ruby trzyma się dobrze.
Według tego artykułu, powodem rzekomego umierania Rubiego jest fakt że Twitter zmienił upodobania programistyczne. To jednak chyba za mało aby zabić jakiś język. Chyba to nie pierwszy i raczej nie ostatni raz, gdy któryś z dużych portali zmienił coś na coś innego. Aby mówić o umieraniu jakiegoś języka to raczej trzeba brać wiele rzeczy pod uwagę i to w skali globalnej, a nie to że Twitter zmienił “orientację”.
Wg tego zestawienia http://blog.codeeval.com/codeevalblog/2014#.VDrkrLCsXJk= w ciągu ostatnich kilku lat Ruby powolutku pnie się w górę.
Nie czytałem całego artykułu, ale ta część o Rubym jest strasznie słaba, w zasadzie jedynym argumentem za śmiercią Rubiego jest to, że Twitter przeniósł się na Scalę. Autor nie zwrócił uwagi na to, ile od tego momentu powstało kolejnych strony w Rubym i przy tym języku zostało.
Kilka argumentów za tym, że Ruby rośnie w siłę:
- od jakiegoś czasu nad CRuby (oryginalna implementacja) 2 osoby, Koichi i Nobu, pracują na pełen etat - zatrudnia ich Heroku; dzięki temu prace nad Rubym naprawdę nabrały tempa i począwszy od wersji 2.1 zapowiadane są regularne wydania
- powstają kolejne implementacje Rubiego; poza JRuby (tu znowu 2 osoby pracujące nad tym na pełen etat, zatrudnia ich RedHat) i Rubiniusem mamy Opal (ruby -> javascript), Rubymotion (Ruby -> Objective-C i ostatnio Ruby -> androidowa Java), a także mruby
- Railsy to jeden z najbardziej kompletnych frameworków webowych i sporo dzieje się w tym środowisku, kolejne wersje wprowadzają fajne feature’y
- Ruby świetnie nadaje się do wszelkiego rodzaju DSLi, co potwierdzają takie narzędzia jak Chef i Puppet; w momencie, gdy performance nie jest kluczowy, Ruby jest fantastycznym wyborem
Oczywiście Ruby nie nadaje się do wszystkiego i ostatnio część społeczności zaczyna korzystać z innych rozwiązań i kieruje się w stronę innych języków (Go, Rust, Elixir), ale to nie znaczy, że Ruby ma się coraz gorzej. Wg mnie jest wręcz przeciwnie, Ruby i Railsy przeszły już fazę tzw. hype’u i ludzie przestali używać tych narzędzi wszędzie, gdzie się da, a używają ich tam, gdzie ma to sens.
2 Likes
Zestawienie Ruby obok Perla, Flasha, Delphi i VB to nic innego jak kiepski troll.
2 Likes
Uuuu, to Twitter nie “chodzi” na JavaScript? To ja wieszczę rychłą śmierć JS 
Twitter zabił JS, koniec z tym językiem
@Arnvald bardzo rzeczowe wyjaśnienie zagadnienia. Masz rację, trudno przychylić się do argumentów autora artykułu, który oparł swoje domysły tylko na tym co zrobili programiści Twittera.
Ruby to świetny język. I może właśnie dlatego jego przyszłość jest niepewna.
Jesli nic sie nie zmieni w problemie konfliktow zaleznosci gemow, przy dowolnym update gema, to rowniez wroze mu taka przyszlosc.
Moze i uda zalac swiat milionami malych, dzialajacych, nierozwijalnych webapek - ale nic ponad to. Na salony enterprise nie wejdzie.
Ciezko ciagle tlumaczyc pracodawcy, ze jak sprobuje uaktualnic gemy lub zainstalowac nowe, to moze sie pozegnac ze stabilnoscia softu.
Zebym nie wiem na jak male serwisy dzielil apke, to ten problem lezy u podstaw calej platformy. Szkoda, ze w Ruby 2.x tego nie rozwiazali - ale pewnie nie widzieli potrzeby, a szkoda 
Możesz rozwinąć? Mam wrażenie, że dotykasz tematu, który dotyczy każdego dowolnego języka programowania i zwie się on: “długo technologiczny”.
1 Like
wydaje mi się, że można to stosunkowo łatwo rozwiązać ograniczając wersję gema i wsio.
Zapewne chodzi o problem, gdy dwa gemy wymagają tej samej biblioteki, ale w dwóch różnych wersjach. W Javie znane jako JAR Hell
@nthx
Ja bym powiedzial, ze Ruby nie wejdzie na salony enterprise jeszcze z paru innych powodow, jak chocby szybkosc dzialania, i brak statycznego typowania - np w javie duzo glupich bledow mozna wylapac na etapie kompilacji, a nie dzialania programu (i nie trzeba pisac tylu testow).
EDIT:
A tak jak pisali koledzy, konflikty fajnie mozna ograniczyc wpisujac w Gemfile versje gema.
W Ruby też nie trzeba pisać dużo testów (nie więcej niż w Javie), wystarczy pisać je mądrze.
1 Like
Oraz sorry za doubleposta, ale skoro już ktoś wyciągnął argument o enterprise oraz o javie, przypomnę co jest największą siłą javy i jednocześnie powodem dla którego nie lubią go ponadprzeciętnie bystrzy programiści:
Java is not used when you need a cutting edge powerful language to whip up a quick prototype, it is used when a piece of software might need to be maintained for the next decade.```
--- http://www.reddit.com/comments/9dzpu/ask_reddit_why_does_everyone_hate_java/
1 Like
No wlasnie, nie moge “rozwinac … aplikacji”, bo bardzo chcialbym uzyc gema A, ale nie jest kompatybilny z gemem B, ktory go wymaga w wersji A sprzed 2 lat. Moge zaryzykowac i uaktualnic gem B, tak, aby byl kompatybilny z A, ale najnowsza jego wersja nie jest kompatybilna z C, D i E 
… itp itd…
Tak i chodzi o gem hell i lock nie za wiele pomoze…
Co tu rozwijac - jest to fakt. To problem, ktory powinien byc rozwiazywalny. We wspomnianej Javie do pewnego stopnia, wydawalo sie, ze jest to praktycznie osiagalne przez osgi, ale to najwidoczniej zmarlo wczesniej niz pozniej
PS. Zalozylem nowy temat na pogadanki o gem hell - zapraszam
1 Like
Zdefiniuj co to znaczy trafić na salony enterprise. Moim zdaniem nie ma tu nic wspólnego z szybkością działania i brakiem statycznego typowania - patrz python, który jest używany często do aplikacji www oraz tzw. “kleju” pomiędzy aplikacjami.
Wiele osób mówi o salonach enterprise w kwestii języków programowania, ale jak już spytać co to znaczy to zapada niezręczna cisza…
Skąd się bierze sytuacja, że pewne języki jak np. C++ (na którego codziennie spływa w internetach fala krytyki) są enterprise, a inne jak ruby podobno nie są:
-
Ruszamy z nowym projektem, powiedzmy 10_000 man-daysów. Potrzeba nam 40 programistów. Możemy zatrudnić kontraktorów, albo zatrudnić sami tych 40 programistów. W pierwszym przypadku ile jest w Polsce firm “na wynajem”, które mają 40 programistów na wynajem. W drugim przypadku: ilu zgłosi Ci się programistów języka ruby, których będziesz chciał zatrudnić. W przypadku javy będziesz miał ich pewnie 10 razy więcej.
-
Studia chcą być jak najbliżej biznesu, więc często-gęsto obserwują to co się dzieje na rynku pracy (czyt. przeglądają pracuj.pl). A tam dużo ogłoszeń dla programistów java, C++, C#. Teraz spójrzmy jakich języków się uczy lub z jakich się korzysta na przedmiotach: podstawy programowania, programowanie obiektowe, systemy operacyjne, sieci komputerowe, algorytmy i struktury danych, itp. itd.
-
No dobrze, to uczmy rubego na studiach!
a) kto to ma robić? (ilu w chwili t=0 mamy dyplomowanych pedagogów?)
b) nawet jeśli by się znaleźli, to trzeba czasu, aby przygotować program nauczania
c) czy początkujących lepiej uczyć pętli w stylu:
for( int i = 0; i <= 10; i++)
printf("%d\n", i);
czy też może:
10.times { |n| puts n }
I nie mówię tutaj o “fajności”, tylko o połączeniu przedmiotu podstawy programowania z przedmiotem matematyka dyskretna. Kolejna rzecz, to mówimy tutaj o osobach, które przychodzą na studia i pierwszy raz w życiu mają styczność z programowaniem.
Support
Ile jest w Polsce firm doradczych, które pomogą nam w problemach związanych z rubym. W korporacjach support to bardzo kochana rzecz. Po co brać odpowiedzialność na siebie? Niech przyjdzie ekspert, firma mu zapłaci i się wypowie. Jak nie będzie działać to będzie na niego, a nie na mnie - smutne, ale prawdziwe…
Wszelkiego rodzaju rozszerzenia.
Mamy oprogramowanie X od firmy IBM/Oracle/HP. W 90% przypadków, jeśli do oprogramowania X można pisać wszelkiego rodzaju rozszerzenia w postaci customowych pluginów lub jakoś to oskryptować to padnie na:
- python
- C/C++
- C# lub ogólniej .NET (jeśli windowsy)
- Java, a teraz bardzo często Groovy
Kolejna rzecz, to że duże aplikacje, a raczej duża infrastruktura/projekt nie jest napisana w całości w jednym języku. To są aplikacje typu webservice, szyny esb, soa itp.Ludzi za przeproszeniem będzie walić to, czy to jest napisane w rubym, javie, czy C++. Byle by gadało z resztą świata.
Szybkość i statyczne typowanie nie ma tu nic do rzeczy. Ruby mógłby być z powodzeniem używany jako klej w infrastrukturze. Również jako oprogramowanie, które “stoi z przodu” - teraz wiele osób korzysta np. z javy lub pythona jako języka do “pisania www”. Również wszelkiego rodzaju webservice-y.
l tu nie trzeba się zastanawiać jaką przyszłość będzie miał ruby. Chcesz, aby ruby był w przyszłości popularniejszy?
- używaj go do pisania programów na studiach (często wykładowcy dają wolną rękę, jeśli chodzi o wybór języka podczas wykonywania projektów)
- pisz biblioteki, dbaj o kompatybilność wstecz
- wspieraj społeczność
- rób fajne rzeczy, które “gadają z resztą świata”
… wtedy ruby będzie miał fajniejszą przyszłość 
10 Likes