Do czego lepiej użyć Ruby, a do czego Elixir? Devdebata

Elixir jest przedstawiany jako “następca” Ruby’ego, m.in. dlatego, że lepiej obsługuje współbieżność. Z drugiej strony, na rynku jest jeszcze zbyt mało developerów znających Elixira, by technologia stała się częściej wykorzystywana przez biznes. Mimo wszystko, zarówno Ruby i Elixir cieszą się sporym zainteresowaniem, dlatego postanowiliśmy poprosić senior developerów, by opowiedzieli o swoich wrażeniach z używania tych dwóch języków.

Razem z Netguru przygotowaliśmy pytania, na które odpowiedzieli:

Bartosz Pranczke. RoR Department Manager w Netguru, firmie oferującej usługi z zakresu doradztwa, tworzenia oprogramowania oraz product designu. Odpowiada za zarządzanie działem Ruby on Rails/Elixir, pracując nad tym aby jakość dostarczanych klientom usług szła w parze z profesjonalnym rozwojem i komfortem pracy developerów.

Paweł Świątkowski. Ruby developer z siedmioletnim doświadczeniem komercyjnym. Obecnie team leader w Boostcom, w zespole odpowiedzialnym za przetwarzanie danych. W Elixirze pisze głównie po godzinach. Oprócz tego gra w curling.

Michał Buszkiewicz. Współzałożyciel i CTO w Curiosum, ze szczególnym zamiłowaniem do zaglądania w mało znane zakamarki stosowanych języków, jak również do przekazywania wiedzy chętnym do wejścia w świat programowania. Po godzinach odreagowuje fotografowaniem lub graniem na gitarze.

Pytanie 1. Czym Ruby różni się od Elixira?

Odpowiada Bartosz Pranczke, Engineering Manager w Netguru:

Główną różnicą są paradygmaty programowania, które te języki wspierają. Ruby to język obiektowy, Elixir natomiast to język funkcyjny. Jest to fundamentalna różnica, bo wymaga innego sposobu myślenia podczas programowania. Kolejną bardzo istotną różnicą jest inne środowisko uruchomieniowe. Elixir jest wykonywany na Erlang VM. Pozwala to na zupełnie inny model wykonywania programu, który wpływa na to jak pisze się programy wykorzystujące więcej niż jeden procesor naraz.

Odpowiada Paweł Świątkowski, Team Leader w Boostcom:

Ruby i Elixir to zupełnie różne języki. Pierwszy jest ogólnego przeznaczenia, z nastawieniem na programowanie obiektowe. Elixir natomiast, jako zbudowany na maszynie wirtualnej Erlanga, to przede wszystkim actor-model i współbieżność.

Odpowiada Michał Buszkiewicz, Współzałożyciel i CTO w Curiosum:

Są to języki z dwóch różnych (aczkolwiek przenikających się) światów i być może najodpowiedniejszą odpowiedzią byłoby: „wszystkim”. Fundamentalna różnica zaczyna się już od samej idei przyświecającej ich twórcom: w przypadku Ruby na każdym kroku podkreśla się, że jest on „zoptymalizowany pod kątem radości z programowania” i akceptuje się fakt, że pewne zastosowane w nim rozwiązania nie będą stawać w szranki z językami z czołówki rankingów wydajności. Elixir natomiast — jako swego rodzaju nadbudowa nad język Erlang — dziedziczy po nim nastawienie na programowanie aplikacji o wysokiej niezawodności, długotrwale przetwarzających dane w sposób wielowątkowy.

Paradygmaty tych języków (funkcyjny w Elixir, obiektowy w Ruby) są z natury całkiem odmienne; w pewnym sensie służą one realizacji wspomnianych nadrzędnych idei, za którymi podążają. Ruby ułatwia osiągnięcie wysokiej produktywności programowania dzięki swojej niepodrabialnej interpretacji programowania obiektowego, Elixir zaś zapewnia platformę do tworzenia niezawodnych aplikacji promując paradygmat funkcyjny i mechanizmy współbieżności oparte na modelu aktorów.

Pytanie 2. Co Ruby i Elixir mają ze sobą wspólnego?

Odpowiada Bartosz Pranczke, Engineering Manager w Netguru:

Nieco mniej technichnicznie odpowiadając, języki te są trochę jak kuzyni. Jeśli zadamy sobie pytanie, jakby mógłby wyglądać Ruby, który wykorzystuje maszynę wirtualną Erlanga wraz z jej wszystkimi możliwościami to wyszedłby nam pewnie Elixir. Wiele narzędzi znanych w świecie Rubiego ma bezpośredni odpowiednik w świecie Elixira (np. Pry w Ruby to IEx.pry w Elixirze, bundler to mix itd.). Autorem Elixira jest José Valim, który także bardzo aktywnie działał przy rozwoju ekosystemu Rubiego, także jak można się spodziewać, większość tego co dobrego w Ruby było inspiracją przy tworzeniu języka jak i narzędzi w Elixirze.

Odpowiada Paweł Świątkowski, Team Leader w Boostcom:

Przede wszystkim składnię. Od początku składnia Elixira miała przypominać tę z Ruby, ponieważ jest ona uznawana przez wielu jako bardzo przyjazna dla programisty. Jose Valim, twórca Elixira, był przez wiele lat programistą Ruby.

Poza tym oba języki cieszą się zainteresowaniem w podobnych środowiskach. W obu wypadkach mamy również koncentrację na web developmencie oraz zdecydowaną dominację jednego frameworka w tej kwestii.

Zobacz też

Backend Scala – fakty i mity. Prześwietlamy popularny język programowania

Odpowiada Michał Buszkiewicz, Współzałożyciel i CTO w Curiosum:

Czasem tłumaczę to mówiąc, że Elixir to język z gramatyką Erlanga i ortografią Ruby – to duże uproszczenie, ale — z uwagi na wieloletnie związki twórców języka Elixir ze społecznością Ruby — można się o nie pokusić. Podobieństwo to jak najbardziej zachęca programistów Ruby do zainteresowania językiem Elixir i z pewnością ułatwia stawianie pierwszych kroków. Przyzwyczajenia dotyczące architektury aplikacji należy odłożyć na bok, ale powierzchowne podobieństwo składni i nazewnictwa w bibliotece standardowej pomaga czuć się bardziej jak w domu.

Na pewno oba języki charakteryzuje wysoka elastyczność dzięki rozbudowanym mechanizmom metaprogramowania, z której autorzy bibliotek i aplikacji chętnie korzystają, by tworzyć „mini-języki” (DSL – Domain-specific languages) służące deklaratywnemu, czytelnemu opisowi zachowania pewnego elementu aplikacji.

Pytanie 3. W czym Ruby’ jest lepszy od Elixira? W jakich przypadkach sprawdzi się lepiej?

Odpowiada Bartosz Pranczke, Engineering Manager w Netguru:

Przewagą Rubiego jest wielkość ekosystemu. Bez problemu znajdziemy biblioteki, które nie tylko wspomogą nas przy rozwiązaniu najczęstszych problemów, ale także i tych znacznie bardziej egzotycznych. No i przede wszystkim Ruby on Rails to dalej pewnie framework, w którym szybciej (bo z więcej gotowych klocków i utartych szlaków) zbudujemy większość typowych aplikacji webowych.

Odpowiada Paweł Świątkowski, Team Leader w Boostcom:

Jeśli ktoś jest przyzwyczajony do programowania obiektowego bazującego na klasach, Ruby będzie tutaj naturalnym wyborem. Z pewnością też mocną przewagą jest znacznie większy ekosystem, choć tu trzeba przyznać, że Elixir zapełnia tę różnicę bardzo szybko. Ruby wykorzystałbym też do wszelkiej maści skryptów (deploymenty, backupy).

Wiele narzędzi z ekosystemu Ruby cechuje się niezwykłą wręcz stabilnością (np. Sidekiq). Warto więc go rozważyć kiedy jest to dla nas istotny czynnik.

Odpowiada Michał Buszkiewicz, Współzałożyciel i CTO w Curiosum:

Chcąc porównywać same języki trudno będzie użyć całkiem obiektywnych kryteriów, więc skupię się na tych subiektywnych: w moim odczuciu nie ma języka, w którym wcielenie w życie jakiejś koncepcji (najczęściej o charakterze proceduralnym) jest łatwiejsze, a efekt czytelniejszy i bardziej zrozumiały, niż w Ruby. Biblioteka standardowa i zastosowane w niej konwencje nazewnicze powodują, że czytając napisany kod przetwarzamy go myślowo niczym język naturalny. To, wraz z elastycznością osiągniętą dzięki rozbudowanym możliwościom metaprogramowania, w dużej mierze przyczyniło się do sukcesu czerpiących z tych zalet bibliotek z Ruby on Rails na czele.

Ostatecznie oceniając Ruby nie tylko jako sam język, ale i cały ekosystem, Ruby jest dojrzały i szeroko zaadaptowany, choć praktyczne zastosowania języka poza aplikacjami internetowymi nie są aż tak rozpowszechnione jak np. w języku Python. Istotną zaletą bywa fakt, że wiele serwisów wystawiających swoje API udostępnia konsumujące je biblioteki w Ruby — nie zawsze tak łatwo znaleźć jest gotową bibliotekę pod Elixir. Trzeba jednak przyznać, że świat Elixira również już od dawna nie jest pustynią i bardzo wiele problemów ma już swoje sprawdzone, „de-facto-standardowe” rozwiązania.

Pytanie 4. Do czego lepiej wykorzystać Elixira i dlaczego?

Odpowiada Bartosz Pranczke, Engineering Manager w Netguru:

Elixir ma obiektywną przewagę wszędzie tam, gdzie potrzebujemy ponadprzeciętnej niezawodności i wydajności. Erlang jest technologią często stosowaną do obsługi systemów telekomunikacyjnych, które działają nieprzerwanie przez lata. Jest to sprawdzone w boju rozwiązanie do obsługi tysięcy połączeń w jednym czasie.

Odpowiada Paweł Świątkowski, Team Leader w Boostcom:

Z uwagi na koncentrację na współbieżności Elixir świetnie się nada tam, gdzie jest ona wymagana. Klasycznym przykładem będą aplikacje korzystające z persystentnych połączeń, np. Web Socketów. Ruby radzi sobie z nimi co najwyżej średnio, a właściwie należałoby powiedzieć, że słabo. Elixir natomiast potrafi bez większego nakładu pracy utrzymać dziesiątki, jak nie setki tysięcy takich połączeń.

Elixir świetnie też sprawdzi się w pisaniu własnych narzędzi korzystających z współbieżności — na przykład scraperów. Ma też przejęty od Erlanga fantastyczny system supervisorów, które pomagają zarządzać pulą procesów wykonujących jakąś pracę.

Często wymienianą cechą Elixira (a właściwie Phoenixa) jest to, że zwraca odpowiedzi w mikrosekundach. To prawda. Dla Railsów jest to kompletnie nieosiągalne. Jeśli więc dana aplikacja potrzebuje takich czasów, również warto rzucić okiem na Elixira.

Odpowiada Michał Buszkiewicz, Współzałożyciel i CTO w Curiosum:

Jeśli myślenie o naszej aplikacji zaczyna wykraczać poza zamknięte ramy cyklu żądanie-odpowiedź HTTP, powinniśmy poważnie zainteresować się tym, co może zaoferować nam Elixir. Mechanizmy programowania współbieżnego w Ruby są… upośledzone, i nie wiem, czy jestem w stanie znaleźć łagodniejsze słowo. Tam, gdzie liczy się wysoka przepustowość i czas odpowiedzi, Elixir będzie zdecydowanie lepszym rozwiązaniem. To jest oczywiście kwestia, które może z początku nie być istotna, ale jeśli przewidujemy, że aplikacja może w przyszłości wymagać wysokiej skalowalności, warto rozważyć jego zastosowanie.

Elixir, promując paradygmat funkcyjny, wymusza na programiście utrzymywanie pewnego rygoru i czystości kodu. Prowadzi to często do tego, że powstaje on w mniejszym tempie, jednak praktycznie zawsze jest on dzięki temu lepiej przemyślany. Jeżeli na utrzymywanie takiego rygoru jesteśmy w stanie sobie pozwolić, z pewnością wybór tego języka zaprocentuje.

Oferty pracy z

Pytanie 5. Jakie napotykasz największe problemy związane z wykorzystaniem Ruby’ego?

Odpowiada Bartosz Pranczke, Engineering Manager w Netguru:

Najczęściej wymienianym problemem Rubiego jest właśnie jego wydajność. O ile jednak można obiektywnie powiedzieć, że są rozwiązania bardziej wydajne to już ciężej z określeniem na ile to jest faktycznie problem dla 99% aplikacji. Dobrym kontrprzykładem jest platforma Shopify napisana w RoR, która obsługuje w czasie Black Friday 10 tysięcy zamówień na minutę (czyli pewnie kilkaset razy więcej samych zapytań). Problemem, z którym ja się najczęściej spotykam jest fakt, że najbardziej zalecane przez twórców RoR podejście — tzw. Rails Way — może powodować problemy przy rosnącej aplikacji. Nie zawsze jest to dobre podejście i czasami powoduje, że bardzo często aplikacje pisane przez nieco mniej doświadczonych programistów, którzy podążają za Rails Way kończą jako bardzo trudne do utrzymania.

Odpowiada Paweł Świątkowski, Team Leader w Boostcom:

Większość pewnie najchętniej zacytowała by tu popularną opinię, że Ruby jest wolny. To prawda, ale w świecie webowym nie ma to tak naprawdę większego znaczenia. Obecnie największe dla mnie problemy to utrzymanie dużych projektów. Jeśli rozwijamy je nieostrożnie, łatwo wpaść w pułapkę doprowadzającą nas do posiadania niezrozumiałego kodu, który będzie się wykładał w mało oczekiwanych momentach.

Niestety, wiele “standardowych metod robienia rzeczy” w Ruby nie pomaga w pisaniu projektów odpornych na starzenie się. A środowisko bywa bardzo oporne w adoptowaniu nowych, lepiej przemyślanych rozwiązań (które wciąż powstają!).

Odpowiada Michał Buszkiewicz, Współzałożyciel i CTO w Curiosum:

Przewrotnie stwierdzę, że największym problemem tego języka są jego największe zalety… w rękach kiepskich programistów. Przykładowo: w Ruby każdą istniejącą już klasę możemy „otworzyć” do modyfikacji, dopisać do niej nową metodę, zmodyfikować istniejącą — monkey patching. To bywa przydatne w sytuacjach, gdy z jakiegoś powodu musimy lekko zmodyfikować zachowanie któregoś z używanych gemów. Wykonanie tego przez programistę, który do końca nie wie co robi, bywa źródłem nieoczekiwanych rezultatów i skrajnej frustracji.

Bolączką Ruby jest programowanie współbieżne — z racji obecnego mechanizmu Global Interpreter Lock, wielowątkowość staje się niemal bezużyteczna. Obchodzi się to stosując w razie potrzeby osobne procesy na poziomie systemu operacyjnego, co jest mechanizmem kosztownym i mało wydajnym. Niedawno miałem do czynienia z koniecznością zrównoleglenia dość skomplikowanego skryptu w Ruby — wyrwałem sobie przy tym trochę włosów z głowy, odkrywając po drodze kilka powodujących błędy „segmentation fault” bugów w Rubym i stosowanych gemach. Zdecydowanie nie polecam.

Pytanie 6. Jakie napotykasz największe problemy związane z wykorzystaniem Elixira?

Odpowiada Bartosz Pranczke, Engineering Manager w Netguru:

Elixir to nadal technologia dość niszowa, co powoduje stosunkowo mały ekosystem. Znacznie częściej trzeba samemu pisać rozwiązania, które w innych technologiach są łatwo dostępne w postaci bibliotek. Problemem może też być po prostu fakt, że większość programistów uczy się programować na językach obiektowych, co czasem przekłada się na pewne problemy przy zmianie paradygmatu. Nie pomaga fakt, że na uczelniach zwykle jedynym językiem funkcyjnym, którego się uczy to Prolog. Jest to język, który dla kogoś na początkującym etapie kariery raczej nie wydaje się być ciekawy rozwiązaniem na realne problemy. Może to ogólnie źle nastawiać w kierunku języków funkcyjnych.

Odpowiada Paweł Świątkowski, Team Leader w Boostcom:

Głównym problemem jaki widzę, jest próba pisania w Elixirze jako takim “nowym lepszym Ruby”. Ponieważ te języki cechują zupełnie inne paradygmaty, to nie może wyjść. Taki kod nie jest ani ładny, ani wydajny, ani odporny na błędy. Jest to więc pewna pułapka, którą ten język nieświadomie zastawił poprzez posiadanie bardzo podobnej składni.

Największym więc moim zdaniem problemem jest to, że aby dobrze posługiwać się Elixirem, należałoby najpierw zapomnieć o Ruby albo nauczyć się Erlanga. Żadne z nich nie jest prostym zadaniem.

Odpowiada Michał Buszkiewicz, Współzałożyciel i CTO w Curiosum:

Elixir, w moim odczuciu, jest trudniejszy w debugowaniu niż Ruby. Dostępne na dzień dzisiejszy narzędzia są — w stosunku do tych, których na co dzień używamy w Ruby — ograniczone, lub niezbyt intuicyjne. Sprawę utrudnia dodatkowo mechanizm makr, który jest jednocześnie tym, co czyni ten język tak niesamowicie elastycznym, a zarazem kompletnym wrzodem, gdy chodzi o analizę występujących problemów.

Osobiście nie odczuwam problemu z „przeskakiwaniem” między paradygmatem obiektowym a funkcyjnym, gdyż w obu poruszam się swobodnie i staram się tak naprawdę stosować podobne dobre praktyki (dużo do myślenia dała mi prezentacja „SOLID Elixir” — Georgina McFadyen, ElixirConf EU 2018). Paradoksalnie pewną irytację sprawia mi czasem „ortograficzne” podobieństwo tych języków, w którym czai się mnóstwo „fałszywych przyjaciół”.

Pytanie 7. Czy dostrzegasz różnice w łatwości utrzymania dużej aplikacji w Ruby’m a w Elixirze? Jakie?

Odpowiada Bartosz Pranczke, Engineering Manager w Netguru:

Ciężko tu mówić o obiektywnych różnicach. Łatwość utrzymania dużej aplikacji to w 90% zasługa programistów pracujących nad nią, a nie technologii. Obie technologie wspierają wszystkie potrzebne mechanizmy do tego, by móc zarządzać dużą aplikacją. Obie też nie wymuszają ich stosowania.

Odpowiada Michał Buszkiewicz, Współzałożyciel i CTO w Curiosum:

Zgodzę się z opinią, że tak naprawdę łatwość utrzymania dobrze napisanej aplikacji w Ruby jest taka sama, jak łatwość utrzymania dobrze napisanej aplikacji, za którą stoi Elixir.

Promowane przez charakter tych języków praktyki programistyczne mają tendencję do prowadzenia do rozwiązań o różnym charakterze: aplikacje w Ruby on Rails rosną często z czasem do ogromnych rozmiarów jako monolity (stając się kolosami na glinianych nogach), zaś charakter języka Elixir powoduje, że szybciej zaczynamy myśleć np. o architekturach opartych na mikroserwisach. Grunt to przemyślany projekt.

Zobacz też

Backend Tworzenie cross-platformowej logiki w języku C++ dla natywnych aplikacji (cz.1)

Pytanie 8. Jak oceniasz społeczność Ruby’ego oraz Elixira? Czy uważasz, że któraś z nich jest bardziej przyjazna/pomocna?

Odpowiada Bartosz Pranczke, Engineering Manager w Netguru:

W dużym stopniu te społeczności się przenikają. Myślę, że duża część programistów Elixira programowała lub dalej programuje także w Ruby. W przypadku obu tych technologii, ich twórcy należą do bardzo sympatycznych osób co bardzo dobrze wpływa na poziom kultury społeczności powiązanych z tymi technologiami.

Odpowiada Paweł Świątkowski, Team Leader w Boostcom:

Obie społeczności są fantastyczne. Główna różnica jest taka, że społeczność Ruby jest dużo większa. A ze wzrostem liczby ludzi zawsze idzie pojawianie się toksycznych jednostek, ludzie którzy nie potrafią zapytać o pomoc itp. Mniejsze społeczności łatwo odbierać jako przyjaźniejsze, ale ja jestem fanem obu.

Odpowiada Michał Buszkiewicz, Współzałożyciel i CTO w Curiosum:

Społeczność Ruby istnieje o wiele dłużej i można to traktować zarówno jako zaletę, jak i wadę, bo czasem wręcz zbyt łatwo znaleźć nieaktualną już odpowiedź na jakieś pytanie pochodzącą z roku, załóżmy, 2007.

W społeczności Ruby wydaje się, że znaczny jest udział osób nieposiadających wykształcenia informatycznego, którzy posiedli ten fach samodzielnie lub z pomocą kursów czy licznych w tej społeczności warsztatów. Studia mogą dać atut w postaci szerszego spojrzenia na informatykę i programowanie, ale jestem zwolennikiem otwartości zawodu i znam wielu świetnych programistów przechodzących z innych branż.

Elixir posiada prawdopodobnie wyższy próg wejścia ze względu na bardziej wymagający paradygmat, niemniej da się ostatnio zaobserwować inicjatywy mające na celu jego upowszechnianie.

Pytanie 9. A może źle zadajemy pytanie i powinno brzmieć tak: Czy to już czas, by web developerzy znali zarówno Ruby’ego i Elixira?

Odpowiada Bartosz Pranczke, Engineering Manager w Netguru:

Na rynku dostępne jest dużo bardzo ciekawych technologii. Na pewno warto aktywnie rozszerzać wachlarz swoich umiejętności. Np. znajomość Elixira i koncepcji programowania funkcyjnego bardzo dobrze wpłynie na to jakiej jakości kod piszemy w Ruby (np. nauczy nas jak pomocne jest maksymalne ograniczenie zmienności obiektów (ang. immutable objects)) i vice versa.

Odpowiada Paweł Świątkowski, Team Leader w Boostcom:

To dopiero źle zadane pytanie. Oczywiście, zawsze jest dobry czas, by nauczyć się kolejnego języka. Nie wyobrażam sobie sytuacji, w której by to miało zaszkodzić. Nowy język to zawsze trochę inny punkt widzenia, który pozwala spojrzeć na pewne rzeczy z innej perspektywy. Na przykład społeczność tworząca obecnie serię narzędzi dry-rb bardzo dużo czerpie ze świata C# oraz… Javy, od której zawsze Ruby tak bardzo się odcinał.

Poznanie Elixira zdecydowanie zmieniło u mnie sposób patrzenia na kod i tworzenia aplikacji. Zaczęło bardzo brakować mi pattern matchingu (więc stworzyłem bibliotekę do niego w Ruby), ale też inaczej spojrzałem na pewne aspekty tworzenia aplikacji webowych — szczególnie organizacji kodu.

Odpowiada Michał Buszkiewicz, Współzałożyciel i CTO w Curiosum:

Jeśli spojrzymy na gigantów IT, nie znajdziemy serwisu napisanego wyłącznie z użyciem jednego języka programowania (przykłady choćby tu). Czas, by web developerzy uczyli się nowych koncepcji i paradygmatów — okazuje się, że wyjątkowo często są one ponadczasowe i ich znajomość niesamowicie ułatwia naukę nowych języków.

Zobacz też

Backend Escape from Merge Hell: Why I Prefer Trunk-Based Development Over Feature Branching and GitFlow