POIT #134: Elixir

Witam w sto trzydziestym czwartym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest Elixir.

Dziś moim gościem jest Michał Buszkiewicz – współzałożyciel i CTO w Curiosum, software house z Poznania. Ekspert od języka Elixir, Phoenix Framework i powiązanych technologii. Wcześniej zjadł zęby na projektowaniu aplikacji Ruby on Rails, z miłością do nieszablonowych rozwiązań. Trener programistów w Ruby, Rails, Git, SQL, JavaScript, obecnie wewnątrz Curiosum przyucza do fachu junior developerów Elixira.

W tym odcinku o Elixir rozmawiamy w następujących kontekstach:

  • dlaczego firma Michała postawiła na Elixir?
  • jak ten język się narodził? Kto go stworzł?
  • na jakie zapotrzebowanie odpowiada Elixir i związane z nim technologie?
  • jak skonstruowany jest język i jak wygląda architektura jego środowiska uruchomieniowego?
  • czy programowanie funkcyjne z wykorzystaniem Elixira jest trudne?
  • jakie najpopularniejsze lub najszerzej używane biblioteki i frameworki aplikacyjne dla języka Elixir są godne odnotowania?
  • kto stoi obecnie za rozwojem tego języka?
  • jak wygląda popularność tego języka w branży?
  • jak rozpocząć naukę tego języka?
  • jak wygląda rynek pracy i zapotrzebowanie na specjalistów znających Elixir?
  • czy tranzycja z języków obiektowych na Elixira jest trudna?
  • jakie są problemy albo braki tego języka?
  • czy jest to dobry język na start w programowaniu?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

To jest 134. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o języku programowania Elixir.

Przypominam, że w poprzednim odcinku rozmawiałem o Kubernetes.

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/134

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. 

Sponsorem podcastu jest firma Apptension, wiodący polski twórca produktów cyfrowych i wydajnych, skalowalnych aplikacji. Zerknij na ich portfolio na apptension.com/portfolio

 

Sponsorem dzisiejszego odcinka jest również platforma rekrutacyjna SOLID.Jobs. Jeśli szukasz pracy w IT, koniecznie odwiedź adres solid.jobs. Znajdziesz tam tylko oferty pracy z widełkami wynagrodzeń. Jeśli aktualnie nie myślisz o znalezieniu nowej pracy, to koniecznie zapisz się na Job Alert, a otrzymasz regularnie wiadomość e-mail z zestawieniem ofert, które mogą Cię zainteresować. Jeśli w swojej pracy dalej korzystasz z SVN-a, to koniecznie odwiedź SOLID.Jobs

 

Nazywam się Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Zostając patronem na platformie Patronite możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły. Jednocześnie bardzo dziękuję moim obecnym patronom. 

A teraz życzę Ci już miłego słuchania. 

 

Odpalamy! 

 

Cześć! Dzisiaj moim gościem jest współzałożyciel i CTO w Curiosum, software housie z Poznania. Ekspert od języka Elixir, frameworka Fenix i powiązanych technologii. Wcześniej zjadł zęby na projektowaniu aplikacji Ruby on Rails, z miłością do nieszablonowych rozwiązań. Trener programistów Ruby, Rails, Git, SQL, JavaScript. Obecnie wewnątrz Curiosum przyucza do fachu Junior Developerów Elixira. Moim i Waszym gościem jest Michał Buszkiewicz.

 

Cześć, Michał! Bardzo mi miło gościć cię w podcaście. 

 

Cześć! Fajnie, że się spotykamy, cieszę się bardzo. 

 

Tak sobie teraz pomyślałem, że właściwie nie dołożyłem do tego przedstawienia ciebie, wątku prelegenta na konferencjach, bycia gościem w podcastach – z tego co widzę, jest to też znaczący element twojej działalności. 

 

Tak. To było bardzo fajne doświadczenie, pokazać się podczas ElixirConf EU w Warszawie niedawno. Porozmawialiśmy trochę o debugowaniu aplikacji. Generalnie prezentacja pokazywała trochę bardziej nieszablonowe podejścia do tematu, co też tak jak wspomniałeś, bardzo lubię. Odzew był bardzo pozytywny, nawet wśród osób, które gdzieś tam z tymi podejściami się nie do końca zgadzały, tak że bardzo się cieszę, że udało się i że mieliśmy okazję spotkać się wszyscy razem po dwóch latach. 

 

Tak, dokładnie, teraz wszyscy są wytęsknieni tego typu spotkań. 

Ten odcinek jest też dla mnie wyjątkowy pod tym względem, że Elixir, o którym będziemy dzisiaj rozmawiać, jest technologią, czy powiedzmy tą gałęzią technologii, w której się obracam od około trzech lat, więc tym bardziej miło mi będzie porozmawiać z osobą, która też w tym stacku się odnajduje. 

Dobrze, to przejdźmy może do konkretów. Na początku stały punkt programu, czyli pytanie do gościa. Michał, czy ty słuchasz podcastów? Jeśli tak, to masz jakieś swoje ulubione audycje, o których możesz powiedzieć?

 

Muszę przyznać, że jestem typem odbiorcy, który raczej najlepiej się czuje jako czytelnik. Zdarza mi się czasem słuchać podcastów typowo nastawionych na Elixir, takich jak Thinking Elixir, w którym zresztą też kiedyś brałem udział, Elixir Mix czy też podcasty trochę szczerzej patrzące na programowanie, Running in Production przykładowo. 

Natomiast jeśli chodzi o takie zasoby czytane, które gdzieś tam są bardziej w moim stylu, jeśli chodzi o odbiór treści, to bardzo lubię wszystko, co podsyłają mi takie topowe newslettery, takie jak Data Elixir, ElixirWeekly. Tak że jeśli chodzi o takie źródła wiedzy na bieżąco, to to są rzeczy, które najczęściej do mnie docierają.

 

Pewnie, rozumiem. Wcale mnie to nie dziwi, ponieważ mam takich odbiorców podcastu, którzy jedyne, w jaki sposób konsumują ten podcast, to jest czytanie transkrypcji, więc doskonale rozumiem, że po prostu każdy ma swoje preferencje, jedni wolą słuchać, niektórzy oglądać, a jeszcze inni czytać. 

 

Wiesz co, myślę, że to jest kwestia też jakiejś takiej umiejętności skupienia się na jednym wątku przez dłuższy czas. Muszę przyznać, że jest to coś, z czym czasem też walczę. I odbiór treści czytanej w takiej formie, że gdzieś przeczytam sobie fragment artykułu, później przeczytam kolejny fragment, później kolejny, często wydaje mi się po prostu łatwiejsze dla mojego sposobu funkcjonowania umysłu. 

Ale podcasty też oczywiście cenię, tak że nie zamykam się na nie zdecydowanie.

 

Jasne, świetnie.

Tak jak powiedziałem we wstępie, jesteś współzałożycielem software house’u Curiosum, i stawiacie na Elixira, jest to wiodąca technologia w waszej działalności. Ale nie zamykacie się tylko na te projekty, które realizujecie, ale też udzielacie się właśnie w community, prowadzicie bloga, tak jak powiedziałeś, byłeś ostatnio prelegentem na ElixirConf EU. 

Zastanawiam się skąd ten wybór? Co by nie było, Elixir nie jest najpopularniejszą technologią wśród software house’ów, a w Polsce to już na pewno. 

 

To nigdy nie było dla nas najważniejszym faktem, ale po jakimś czasie po założeniu firmy, dotarło do nas, że prawdopodobnie jesteśmy pierwszym software housem w Poznaniu i nie jestem do końca pewien, ale prawdopodobnie również w Polsce, który od samego początku postawił twardo na Elixir, nie przechodząc na tę technologię z jakiejś innej. To jest dość istotne, bo dzięki temu możemy powiedzieć, że jesteśmy w tej technologii specjalistami, nie rozmieniamy się gdzieś tam na drobne, dalej inwestując jakoś resztkowo w stosy technologiczne, w które nie do końca wierzymy. 

Natomiast posiadając takie doświadczenie zaczerpnięte z naszych doświadczeń podczas wcześniejszej pracy zawodowej w tworzeniu aplikacji webowych dla wielu branż, doskonale wiemy, jakie ograniczenia niosły za sobą technologie, których używaliśmy do tej pory w zakresie skalowalności czy zdolności do obsługi liczb jednoczesnych połączeń sięgających setek tysięcy, czy w niektórych przypadkach milionów. Tak że po prostu uświadomiliśmy sobie, że języki tradycyjnie kojarzące się z radością pracy developerów i prostotą wejścia w nie oraz tworzenia przy ich pomocy aplikacji, są po prostu nieprzystosowane do równoległego i szybkiego przetwarzania danych. 

To wszystko generuje później koszty skalowania infrastruktury, o których inwestorzy i twórcy startupów nie mają pojęcia w początkowej fazie rozwoju ich produktów. Tak że postanowiliśmy wyjść naprzeciw technologią, która jest zarówno produktywna w samym tworzeniu aplikacji, jak i gotowa na wyzwania stojące przed startupem, kiedy ta aplikacja opuszcza już fazę MVP i staje się czymś dużo więcej.

 

Jasne, rozumiem. Czyli był to świadomy wybór, zdefiniowanie sobie tych problemów technologii, z którymi wcześniej mieliście do czynienia i postawienie mocne na Elixir, rozumiem.

 

Dokładnie. 

 

To teraz prosiłbym cię, żebyś opowiedział trochę o samym języku. Skąd się wziął, kto go stworzył? Bo język jako taki nie jest może super, powiedzmy historyczny, ale bazuje na rozwiązaniach, które mają już sporo doświadczenia. Opowiedz, proszę, co to jest za język i jak powstał.

 

Głównym twórcą tego języka i w zasadzie pomysłodawcą całej tej idei jest Brazylijczyk José Valim, związany zresztą przez długi czas z ekosystemem, środowiskiem języka Ruby. Ten oto programista rozwinął w sobie zainteresowanie językami, narzędziami bardziej odpowiadającymi wyzwaniom związanym z wymaganiami wydajności i skalowalności, które stawiają dzisiejsze aplikacje. 

Szczególną pasję wzbudziła w nim maszyna wirtualna języka Erlang, który już od lat 80., kiedy to został stworzony w firmie Ericsson, był szeroko stosowany w telekomunikacji do rozwiązywania właśnie takich zagadnień. Okazuje się, że tego rodzaju problemy w dużej mierze wróciły i uświadomiono sobie, że jest to tak naprawdę zagadnienie, które jest bardzo istotne. 

Elixir jest pewnego rodzaju nadbudową nad ową VM-kę, która odpowiada za odczuwane przez José braki w języku Erlang, jeśli chodzi o składnię czy też wygodę użycia. Czerpie też inspiracje z innych języków funkcyjnych, czyli Haskella, Clojure oraz tak składniowo z Ruby. Z pierwszego z nich zaczerpnął m.in. konstrukcję pattern matchingu, drugi z nich dał początek pewnym koncepcjom związanym z organizacją kodu i różnym syntactic sugarom, a trzeci to tak naprawdę stylistyka składniowa. 

Aczkolwiek porównując to do języków naturalnych, porównałbym Ruby i Elixir do języków, które mają, powiedzmy podobną ortografię, ale całkowicie różną gramatykę, ponieważ często  występuje takie sprzedawanie Elixira jako podobnego do Ruby, co jest dość, powiedziałbym powierzchowne, jeśli nie bzdurne. 

 

Tak, na pierwszy rzut oka tak się może wydawać, ale pod spodem zupełnie inne mechanizmy. 

 

Tak, to też wynika z tego, że trochę zazębia się tutaj to community. Sami twórcy zresztą byli też związani z językiem Ruby i gdzieś tam dość mocno się przyczynili do rozwoju jego ekosystemu. Tak że tutaj jest dużo zbiegów okoliczności, a mało tak naprawdę jakichś faktycznych powiązań. 

 

Tak, myślę, że to raczej są tacy bracia, jeśli można tak powiedzieć o technologiach, natomiast faktycznie są to de facto dość mocno różniące się rozwiązania. Tak jak powiedziałeś, José Valim jako wówczas core member Ruby on Rails szukał rozwiązania problemu właśnie współbieżności, patrzył, jak to wygląda w innych językach, i tak trafił tak jak mówiłeś na Erlanga. 

I tak jak sam później mówił, pokochał wszystko to, co w tym Erlangu, w tej maszynie wirtualnej znalazł, ale też znienawidził to, czego tam brakowało, czyli właśnie prostoty tworzenia kodu, która w Ruby powiedzmy, jest czymś, co de facto definiuje cały język. Postanowił więc te swoje doświadczenia z Ruby trochę portować, powiedzmy na nowy język, który właśnie stworzył, i który działa na maszynie wirtualnej, więc jest tutaj możliwość uruchamiania wręcz kodu erlangowego. 

Chciałbym cię zapytać, na jakie zapotrzebowanie odpowiada Elixir? Języków programowania jako takich pewnie powstaje do szuflady bardzo wiele, niektóre giną tak samo szybko, jak powstają, ale Elixir jakoś się wybił czy wybija. W związku z tym należy podejrzewać, ze faktycznie zaspokaja jakiś problem czy jakąś niszę. Mógłbyś coś takiego wymienić, jeśli chodzi o Elixira? 

 

To jest pewnego rodzaju sweet spot między efektywnością, prostotą kodowania a jakością wyników pracy, można tak to najkrócej określić. Myślę, że istnieje niejeden powód, dla którego to właśnie Elixir, a nie takie języki bardziej powiedzmy, purystyczne funkcyjnie, jak np. Haskell, są na pewnego rodzaju drodze do mainstreamu, można powiedzieć. 

Sądzę, że Elixir odpowiada na odwieczny problem ściany, na jaką natrafiają startupy wybierające na początku technologię znaną z szybkiego developmentu aplikacji, powiedzmy radości pracy developerów, time to deliver itd. Te technologie nie mają wiele do zaoferowania w kwestii dalszego skalowania tych aplikacji. Oczywiście samo zastosowanie odpowiedniej technologii, czyli tutaj Elixira, nie jest gwarancją czegokolwiek, dlatego że jest masa projektów źle prowadzonych i wykorzystujących to w nie do końca świadomy sposób, ale charakterystyka języka i tego toolsetu sprawia, że jednak daje większe możliwości i wprowadzi w naturalny sposób do lepszych rozwiązań.

 

Sądzę, że Elixir odpowiada na odwieczny problem ściany, na jaką natrafiają startupy wybierające na początku technologię znaną z szybkiego developmentu aplikacji, powiedzmy radości pracy developerów, time to deliver itd. Te technologie nie mają wiele do zaoferowania w kwestii dalszego skalowania tych aplikacji. Oczywiście samo zastosowanie odpowiedniej technologii, czyli tutaj Elixira, nie jest gwarancją czegokolwiek, dlatego że jest masa projektów źle prowadzonych i wykorzystujących to w nie do końca świadomy sposób, ale charakterystyka języka i tego toolsetu sprawia, że jednak daje większe możliwości i wprowadzi w naturalny sposób do lepszych rozwiązań.

 

Dokładnie. 

Dobrze, teraz może wejdźmy trochę w to, jak ten język jest zbudowany. Jak wygląda konstrukcja tego języka, jak wygląda architektura środowiska uruchomieniowego? Rzuć, proszę na to trochę światła.

 

To zacznijmy właściwie od narzędzi dzielonych z językiem Erlang, czyli BEAM – jest to maszyna wirtualna, która z kolei jest częścią OTP, czyli Open Telecom Platform, który jest po prostu zestawem standardowej biblioteki narzędzi dla języka Erlang. I jest to ta podstawa, która zapewnia właśnie skalowalność i fault tolerance, czyli taką kolejną ważną cechę zarówno Erlanga, jak i Elixira. No i do tej właśnie maszyny wirtualnej kompilowane są zarówno aplikacje w języku Erlang, jak i Elixir. 

Same cechy tej maszyny wirtualnej są zdecydowanie ważniejsze od tego, co czasami wspomina się jako istotne w przypadku maszyn wirtualnych choćby Javy, czyli jakieś wieloplatformowości itd. Tutaj tak różowo nie jest, jeśli chodzi np. o uruchamianie kodu skompilowanego w jednej platformie na drugiej platformie, ale nie jest to najważniejszy aspekt i nie na tym się skupiamy. 

Natomiast istotną cechą samego języka jest fakt, że zadania jego własnego kompilatora są relatywnie skąpe, biorąc pod uwagę fakt, że znaczna część kluczowej konstrukcji języka jest zbudowana przy pomocy makr, czyli takich funkcji przyjmujących pewne dane i zwracających kod. Przykładowo słówko tworzące funkcję, czyli „dev” jest także zdefiniowane jako makro, w kodzie źródłowym samego języka można dokładnie zauważyć, co dzieje się w trakcie definiowania funkcji, jak jest rejestrowana itd. Ten kompilator po wstępnym parsingu kodu przechodzi do fazy macro expansion, podczas której kolejne makra, czyli te nasze funkcyjki generujące kod są rozwijane do postaci, w której już nie ma czego rozwijać. Znajdują się w niej tylko elementy złożone z czegoś, co widzimy w takim module Kernel Special Forms, czyli takich konstrukcji obsługiwanych bezpośrednio przez kompilator. I ta postać z kolei jest już kompilowana do bytecode’u. 

To tak w największym skrócie sposób, w jaki Elixir wygląda i można powiedzieć, że to jest dość ważna cecha, dlatego że ona bardzo mocno określa sposób tworzenia biblioteczek, jakichś tam DSL-i, gdzie to jest potrzebne. I oczywiście cały aspekt metaprogramowania, który też jest bardzo ważny. 

 

Właśnie, to jest ciekawa rzecz, że całkiem spora część Elixira jest obecnie napisana w Elixirze tak de facto. 

 

Dokładnie.

 

To jest fajna rzecz. To, co powiedziałeś, że ten bytecode, czyli Elixir kompilowany do bytecode’u, uruchamianego później na maszynie wirtualnej, to jest tak jakby, jak to się mówi, stać na ramionach gigantów, czyli bazujemy na tym, co przez dziesiątki lat tak naprawdę, jeśli chodzi o maszynę wirtualną Erlanga, było rozwijane i na tym dokładamy jeszcze coś, co pozwala w przyjemniejszy, łatwiejszy, bardziej dostępny sposób pisać właśnie oprogramowanie. Myślę sobie, że analogia, która byłaby tutaj może bliższa słuchaczom, jest taka, że można porównać to trochę do Scali i maszyny wirtualnej Javy. Można powiedzieć, że jest to podobny koncept przynajmniej. 

Tak jak powiedziałeś Elixir bazuje na paradygmacie funkcyjnym, to jest jak gdyby core’owy paradygmat tego języka. Co by nie było, ten paradygmat zyskuje obecnie trochę na popularności, ale ciągle jest jeszcze niszowy. Programowanie obiektowe zdecydowanie króluje, jeśli chodzi o nowoczesne języki programowania. 

Myślę sobie, że trochę na to niestety wpływa to, że w takim powszechnym mniemaniu, jak się z kimś rozmawia, to programowanie funkcyjne odbierane jest jako bardzo skomplikowane, matematyczne, wręcz naukowe, nacechowane, naszpikowane taką teorią – taki jest odbiór. Czy ty się z czymś takim spotykasz, programując w Elixirze? Czy tak to programowanie funkcyjne wygląda? 

 

Elixir jest raczej daleko od tego rodzaju cech, które właściwie bardziej przypisuje się językom bardziej purystycznym, jak Haskell, Elm, może F Sharp. Pewnych koncepcji istniejących w tych językach po prostu celowo wręcz do Elixira nie przenoszono. Są to języki często statycznie typowane, kiedy w Elixirze mamy typowanie dynamiczne, i jest to naprawdę sól w oku programistów, którym przyszłoby korzystać z Elixira, a którzy do tej pory korzystali np. z Haskella. W Elixirze mamy podejście let it crash, w kontraście do takiego ścisłego wyłapywania błędów już w trakcie kompilacji np. w Haskellu. Tak że zagorzali fani języków funkcyjnych takich bardzo purystycznych, z dużą dozą teoretyzmu, raczej Elixira nie polubią. 

Ja traktuję tutaj programowanie funkcyjne jako taki paradygmat, który po prostu kładzie nacisk na pewnego rodzaju procesy przetwarzania danych z jednej postaci w drugą. Myślę, że to jest ten aspekt programowania funkcyjnego, który w Elixirze jest najistotniejszy i bardzo ułatwiony w użyciu przez choćby pipe operator. 

Wracając jeszcze do wszystkich innych języków – uwielbiany przez wszystkich ludzi bardzo zajaranych tym matematycznym aspektem programowania funkcyjnego, np. Haskell, pozostanie prawdopodobnie językiem też świetnym, ale wybieranym w konkretnych projektach, do osiągnięcia konkretnego celu, w sposób świadomy. Natomiast Elixir ma przed sobą przyszłość obejmującą szersze zastosowanie. 

Niebagatelne znaczenie ma tu pewnego rodzaju prostota oraz zalety jego maszyny wirtualnej w porównaniu z językami obiektowymi, do których, można powiedzieć, dobudowano pewne elementy programowania deklaratywnego czy też funkcyjnego – w zasadzie wszystkie znane nam współcześnie języki jakieś takie elementy posiadają. Zdecydowanie największym plusem jest tutaj i mutowalność danych i całkowity brak obiektowości – jakkolwiek dziwnie to brzmi dla kogoś przyzwyczajonego do OOP – ponieważ dzięki temu banalnie proste jest rozumowanie o interakcjach pomiędzy modułami i np. przesyłanie kodu w środowisku tak lokalnym, jak i rozproszonym. 

 

Elixir jest raczej daleko od tego rodzaju cech, które właściwie bardziej przypisuje się językom bardziej purystycznym, jak Haskell, Elm, może F Sharp. Pewnych koncepcji istniejących w tych językach po prostu celowo wręcz do Elixira nie przenoszono. Są to języki często statycznie typowane, kiedy w Elixirze mamy typowanie dynamiczne, i jest to naprawdę sól w oku programistów, którym przyszłoby korzystać z Elixira, a którzy do tej pory korzystali np. z Haskella. W Elixirze mamy podejście let it crash, w kontraście do takiego ścisłego wyłapywania błędów już w trakcie kompilacji np. w Haskellu. Tak że zagorzali fani języków funkcyjnych takich bardzo purystycznych, z dużą dozą teoretyzmu, raczej Elixira nie polubią.

 

Tak. Myślę, że istotna też jest praktyczność i pragmatyczność tego. Jednak Erlang jako język służący w telekomunikacji musiał być bardzo pragmatyczny, i tak samo tutaj mam wrażenie, że wszystkie te koncepty programowania funkcyjnego, które występują i w Erlangu, i w Elixirze właśnie temu też mają służyć. Tutaj nie chcemy teoretyzować, tylko faktycznie zająć się budowaniem czegoś, co po prostu będzie na produkcji działało. 

A jeśli mówimy już o produkcji i o tych zastosowaniach, to chciałbym cię zapytać, jakie takie najszerzej używane frameworki, biblioteki, właśnie zastosowania Elixira są, powiedzmy, znaczące i godne odnotowania?

 

Nie da się ukryć, że jeżeli rozmawiamy o aplikacjach elixirowych gdzieś tam w webie, to najczęściej myślimy o Phoenix Framework lub którychś z jego składowych. Jest to framework, który można porównywać w pewnym sensie do Ruby on Rails, jednak jest on zdecydowanie bardziej modułowo skonstruowany i zdecydowanie łatwiej poszczególne jego elementy gdzieś tam z siebie odłączać, jeżeli to jest potrzebne, z którychś rezygnować itd. Zresztą twórcy tego frameworka nie raz otwarcie mówili, że korzystali z doświadczeń frameworków właśnie takich jak Ruby on Rails i pewne zastosowane w nich rozwiązania projektowe po prostu uznali za błędne, i nauczyli się na swoich czy też cudzych błędach. 

Dość ciekawym elementem, obecnie jeszcze niebędącym w wersji 1x jest Phoenix LiveView, który w pewien sposób przypomina Reacta, choć jest to porównanie, które należałoby tak naprawdę obwarować wieloma gwiazdkami. Jest to de facto wykorzystanie możliwości maszyny wirtualnej Erlanga w zakresie umiejętności przetwarzania setek tysięcy procesów na raz do przeniesienia, zarządzania stanem interfejsu aplikacji webowej, tak naprawdę na nasz serwer, który utrzymuje dla każdego połączenia z tym serwerem użytkownika, który np. wyświetla daną stronę. Tak naprawdę osobny proces, który utrzymuje stan i przesyła go klientowi, czyli przeglądarce przez WebSockety, co też jest zresztą mocną stroną Phoenixa. 

Dalej mamy też oczywiście frameworki stosowane często wspólnie z nim, np. Absinthe do konstrukcji API w GraphQL’u, co też jest bardzo fajną sprawą. Oczywiście nie wspominając o wszystkich innych bibliotekach, które są niezbędne dla większości apek, choćby Ecto do baz danych, które zresztą jest ciekawym podejściem do mapowania tabel na struktury w naszym języku, gdyż rzecz jasna nie mamy tu do czynienia z językiem obiektowym, więc nie może to być mapowanie obiektowo-relacyjne. Natomiast główną cechą jest to, że Ecto stara się być tak blisko koncepcji czysto SQL-owych, jak to tylko możliwe. I to jest troszeczkę inne podejście niż w wielu innych frameworkach ORM-owych. 

Dalej: jest wiele gotowych bibliotek, które pozwalają na interakcje z popularnymi usługami chmurowymi, choćby z AWS-em, tak że tutaj nie trzeba, powiedzmy, wyważać otwartych drzwi czy też wymyślać koła na nowo. Jest wiele różnych klientów HTTP, które pozwalają na interakcje z jakimiś API, które musimy konsumować w sposób taki bardziej zorganizowany. Generalnie wszystkie biblioteki takich najpopularniejszych zagadnień, z którymi mamy do czynienia w aplikacjach webowych są dostępne. 

A już odchodząc trochę od weba, mamy też oczywiście Nerves, czyli framework służący do budowy aplikacji IoT, głównie na poziomie takich urządzeń, jak Rasberry Pi, co też jest bardzo fajnym zagadnieniem. Jeśli chodzi o zupełnie inne zastosowania, to czasami szukam sobie jakichś takich zupełnie innych rzeczy i okazuje się, że jest np. framework do dwuwymiarowych interfejsów użytkownika jak Scenic. Albo framework do konstrukcji jakichś takich ładnych wizualnie dashboardów z użyciem również Racta, jak Kitto. 

Tak że tutaj zastosowań jest naprawdę dużo. Wiele bibliotek, które zostały stworzone np. kilka lat temu i nie są do dzisiaj rozwijane, działa dzisiaj bez przeszkód z uwagi na to, że Elixir jest językiem, który mocno stawia na taką harmonijność rozwoju. W tej chwili jest to język, jeśli chodzi o ficzery z pierwotnego backloga, zamknięty. One zostały wszystkie zrealizowane, i jedynie czasami pojawiają się jakieś depracations, które tak naprawdę zostaną skasowane dopiero wtedy, kiedy powstanie Elixir 2.0. Natomiast ogólnie rozwój języka jest taki, że raczej trudno jest się spodziewać, że gdzieś tam z wersji załóżmy 1.12 na 1.13 pojawią się jakiekolwiek breaking changes, taka jest po prostu ich polityka. I to jest fajne, bo mniej zaskoczeń następuje. 

 

Tak, nie da się ukryć, że web to jest najmocniejsze obecnie zastosowanie Elixira, zwłaszcza z Phoenixem, właśnie z bardzo dobrą obsługą WebSocketów, Pub/Sub’em, który jest w stanie naprawdę uciągnąć mnóstwo jednoczesnych połączeń z Live View, gdzie jesteśmy w stanie jak gdyby, zamiast renderować cokolwiek za pomocą JavaScriptu, tak naprawdę odpytywać backend przez WebSocket i uaktualniać ten interfejs, dajmy na to, w czasie rzeczywistym. Tutaj wręcz robi się jakieś animacje, które są generowane na serwerze i poprzez właśnie WebSockety przesyłane do przeglądarki z minimalizacją JavaScriptu prawie do zera. 

Ale oprócz tego, taka branża właśnie jak IoT czy też urządzenia embedded, to też są takie zastosowania, o których może na pierwszy rzut ucha nie słychać, ale które w pewnych miejscach naprawdę się odnajdują. Ja znam np. takie zastosowanie w przypadku nawigacji na łodzie, gdzie łódź wypływa na miesiące wręcz w morze, więc nawigacja nie może tam zawieść, musi działać w sposób ciągły i w sposób przewidywalny. 

Okazuje się, że jest taka firma, która właśnie produkuje takie zaawansowane rozwiązania i chwalili się jakiś czas temu wykresami z tego, jak np. wygląda konsumpcja pamięci, procesora itd. To jest naprawdę przewidywalna technologia, w sensie maszyna wirtualna wstaje, aplikacja jest uruchamiana, konsumpcja zasobu jest na jakimś poziomie i przez miesiące utrzymuje się to na tym samym poziomie, nie ma tutaj żadnych wahnięć. 

Dodatkowo na takich, już może nie zabawkach, ale takich płytkach jak np. Rasberry, Arduino itd. – tam też można uruchomić taką bardzo, bardzo odchudzoną wersję maszyny wirtualnej właśnie z Elixirem, to wszystko bootuje się bardzo szybko. Tak że takie zastosowania też jak najbardziej są. 

Powiedziałem o tej niezawodności trochę, ty wspominałeś Michał o tym, że w sposób współbieżny i w sposób rozproszony możemy taki kod sobie uruchamiać. Czy według ciebie właśnie te ficzery pod tytułem niezawodność, współbieżność, jakaś rozproszoność tego kodu – czy to są takie główne ficzery, które sprzedają Elixira?

 

Tak, tutaj myślę, że wszelkie systemy, które wymagają wysokiego poziomu współbieżności lub takie, które mogą tego w przyszłości wymagać, są dobrym miejscem, żeby tej technologii użyć. Na przykład Elixir m.in. dzięki maszynie wirtualnej Erlanga pozwolił Discordowi na obsługę 5 milionów równoległych połączeń klientów. Później z kolei troszkę to podrasowano jeszcze z użyciem Rusta, ale cały czas jest to wynik, który budzi respekt. 

I tak jak mówiłem, mamy tutaj często do czynienia z podejściem let it crash, umożliwionym przez bardzo sprawne zarządzanie procesami i zajmowanymi przez nie zasobami przez VM, który bardzo sprawnie je czyści wtedy, kiedy jakiś proces się nam wykrzacza w kontrolowany sposób. I oczywiście filozofia ta to nie jest takie coś, że świecimy użytkownikom w oczy błędami – są to takie błędy, których oczekujemy na poziomie serwera, z którymi liczymy się już na etapie projektowania w zależności między procesami. 

Myślę, że bardzo fajną rzeczą jest to, że rozumowanie na temat współbieżności przetwarzania jest banalnie proste dzięki temu, że mamy model aktorów i komunikację międzyprocesową przez message passing, a nie współdzielenie danych. I tak jak wspominałem, brak stanowych obiektów znanych z OOP zdecydowanie ułatwia implementację wszelkich zagadnień związanych choćby z przesyłaniem kodu między węzłami w celu odpalania jakichś funkcji zdalnie. 

 

Tak, tutaj myślę, że wszelkie systemy, które wymagają wysokiego poziomu współbieżności lub takie, które mogą tego w przyszłości wymagać, są dobrym miejscem, żeby tej technologii użyć. Na przykład Elixir m.in. dzięki maszynie wirtualnej Erlanga pozwolił Discordowi na obsługę 5 milionów równoległych połączeń klientów. Później z kolei troszkę to podrasowano jeszcze z użyciem Rusta, ale cały czas jest to wynik, który budzi respekt. 

 

Właśnie, José Valim jest twórcą tego języka, o ile mnie pamięć nie myli, był to 2012 rok, gdy w ogóle pojawiły się jakieś pierwsze wersje Elixira. Kto obecnie stoi za rozwojem tej technologii? Jak to obecnie się kształtuje?

 

Tak, obecnie jest to 6-osobowy Elixir Core Team, którego José również jest członkiem. Natomiast język jest oczywiście wspierany przez szereg firm współtworzących i sponsorujących główne biblioteki i najszerzej zaadaptowane frameworki, jak Phoenix czy Nerves. Core Team oczywiście dba o to, by z jednej strony jak najlepiej wysłuchać głosu społeczności w kwestii funkcjonalności i kierunków rozwoju… Sam José podczas ostatniego ElixirConfa stwierdził, że gdyby zależało to tylko od niego, niektóre elementy języka wyglądałyby zupełnie inaczej, ale decydował głos społeczności. 

Natomiast  z drugiej strony chwalebne jest to, że ten Core Team pilnuje, by język nie dostawał za dużo takiego bloatu, czyli funkcji, które nie są na tyle uniwersalnie potrzebne całemu community, by wbudowywać je w jego core. Jest taki silny nacisk, by tego typu rzeczy stawały się osobnymi bibliotekami i jakby rywalizowały ze sobą na czymś na kształt wolnego rynku.

 

Dokładnie. 

Dobrze, powiedz jak z twojej perspektywy, wygląda popularność tego języka obecnie w branży? Oczywiście możemy sobie zobaczyć na TIOBE index albo innych tego typu indeksach, natomiast chodzi mi tutaj np. o podaż developerów, co może być jakimś znaczącym czynnikiem na przykład dla firm, jeśli chodzi o zdecydowanie się na pójście w tę technologię. I też firmy, które produkcyjnie wykorzystują właśnie Elixira w swoich zastosowaniach.

 

Zaczynając od końca – oczywiście firm wykorzystujących Elixir produkcyjnie jest coraz więcej i są to naprawdę sporzy gracze, choćby Pinterest, który był w stanie zmniejszyć o połowę liczbę serwerów, która jest im potrzebna, 10 razy mniej kodu w pewnych obszarach aplikacji. Moz, który bardzo zredukował użycie dysków i przyspieszył jego API. Lonely Planet, Financial Times, Toyota, Bleacher Report, Discord…

 

PepsiCo.

 

PepsiCo, dokładnie. WhatsApp, który wprawdzie używa wprost raczej Erlanga, natomiast jest to oczywiście oparte na tej samej infrastrukturze, więc można tutaj to podpiąć. Tak że tych firm jest coraz więcej, więc myślę, że to jest najlepszy dowód na to, ze ten język ma rzeczywiście wiele do zaoferowania. Natomiast jeśli chodzi o środowisko takie typowo startupowe, to o ile hasło takie jak Ruby on Rails jest pewnego rodzaju triggerem, oczywistością, która od razu kojarzy się z określonymi zaletami znanymi od lat, to Elixir czy Phoenix dalej jest czymś, co trzeba w aktywniejszy sposób sprzedawać. 

Wzbraniałbym się jednak przed takim stwierdzeniem, że jest to technologia niszowa. Może raczej bym powiedział mniej oczywista, jeśli chodzi o jej wybór do określonych celów. Natomiast tak jak mówiłem – coraz więcej naprawdę dużych graczy kojarzonych z webem i nie tylko, chwali się użyciem Elixira, co jednak dobrze świadczy o jego sile przebicia. 

Natomiast wracając do rynku pracy – nie da się ukryć, że jest trudny. Większość developerów przechodzi do Elixira z innych języków, na poziomie takim powiedzmy przynajmniej Regularowym. Podaż takich osób jest relatywnie niewielka, gdyż zdolni developerzy bardzo szybko znajdują zatrudnienie. Można powiedzieć, że podaż nie nadąża tutaj za popytem, który jest zdecydowanie widoczny zarówno w software house’ach, które korzystają z tego języka, jak i startupach, które działają na własną rękę. Czasami powstaje w ten sposób troszeczkę niezdrowy wyścig, którego efektem wcale nie jest udana rekrutacja, zarówno w takich firmach bardziej produktowych, jak i software house’ach, ale trzeba się z tym liczyć. 

Natomiast inną strategią, którą również z sukcesami stosujemy w Curiosum, jest rekrutacja młodych utalentowanych programistów, którzy brzydko mówiąc, nie są skażeni programowaniem obiektowym, i wewnętrznie szkolimy ich naszymi autorskimi metodami oraz z dużym powodzeniem powierzamy im zadania rozwoju projektów komercyjnych pod okiem bardziej doświadczonych kolegów. 

I ci Juniorzy naprawdę szybko uczą się tworzenia zgrabnych, uporządkowanych i wydajnych architektur aplikacji. Okazuje się, że tak naprawdę learning curve tego języka jest taki, że wcale nie trzeba developera z jakimś nie wiadomo jak ogromnym doświadczeniem, aby był efektywny. Zależy nam oczywiście, by każdy programista, który dołącza z naszego ramienia do projektów, spełniał określone przez nas standardy, dzięki czemu CV konkretnego developera, który dołącza do konkretnego projektu, ma mniejsze znaczenie niż sam fakt współpracy z nami i dostępu do naszej bazy wiedzy, naszego know-how. 

 

Natomiast inną strategią, którą również z sukcesami stosujemy w Curiosum, jest rekrutacja młodych utalentowanych programistów, którzy brzydko mówiąc, nie są skażeni programowaniem obiektowym, i wewnętrznie szkolimy ich naszymi autorskimi metodami oraz z dużym powodzeniem powierzamy im zadania rozwoju projektów komercyjnych pod okiem bardziej doświadczonych kolegów. I ci Juniorzy naprawdę szybko uczą się tworzenia zgrabnych, uporządkowanych i wydajnych architektur aplikacji. Okazuje się, że tak naprawdę learning curve tego języka jest taki, że wcale nie trzeba developera z jakimś nie wiadomo jak ogromnym doświadczeniem, aby był efektywny.

 

Jasne. Właśnie, jak jesteśmy przy nauce tego języka, to chciałbym cię zapytać, jak rozpocząć tę naukę, gdzie szukać materiałów, z czego najpierw skorzystać? 

 

Jest wiele książek na PragProg, m.in. „Learn Functional Programming with Elixir”, która bardzo fajnie spina temat samego Elixira z programowaniem funkcyjnym tak ogólnie, i to jest bardzo fajna książka. Na późniejszych etapach fajnie jest też sięgnąć po książki mówiące o jakichś bardziej konkretnych zagadnieniach z tego języka. Bardzo dużo dała mi choćby książka Chrisa McCorda o metaprogramowaniu w Elixirze, które naprawdę jest czymś zupełnie innym, niż koncepcje, które służą do tego celu w innych językach. 

Natomiast jeśli chodzi o pozostałe zasoby, ja się osobiście uczyłem języka z materiałów dostępnych na jego stronie, w takim bardzo podstawowym zakresie i pomimo że nie są jakoś bardzo obszerne, to mi jako wówczas programiście innych języków, który w miarę dobrze się czuł w nowych rzeczach, wystarczyło to do poznania podstaw. 

Jest też Elixir School, czyli taki kurs dostępny też za darmo online, który traktuje to trochę obszerniej. Czasami polecamy też materiały wideo na Udemy, jakieś kursy, które dość szeroko pokrywają zagadnienia związane z Elixirem. Generalnie tych materiałów jest sporo. Może nie tak dużo jak w przypadku jakichś tradycyjnych języków typu Java itd., natomiast generalnie uważam, że są zdecydowanie wyższej jakości i tu na pewno jest z czego się uczyć. 

 

Pewnie. Ja bym może jeszcze do tego dorzucił Exercism.io – to jest taki system do ćwiczenia swoich umiejętności programistycznych, oczywiście w wielu językach, m.in. w Elixirze, gdzie rozwiązuje się poszczególne zadania, które mają rosnący poziom trudności. Swoje rozwiązanie możemy oczywiście sprawdzić lokalnie, ale też wysłać do tej platformy i tam liczyć na komentarz, na sprawdzenie swojego rozwiązania, w takim przyjaznym środowisku. To też jest fajny sposób, żeby albo rozpocząć naukę, albo podszkolić się, robiąc sobie takie codzienne cuty, takie codzienne testy. 

Wspominałeś o tym, że np. rekrutujecie czy też przyjmujecie osoby, które douczacie do Elixira. Ja mam bardziej doświadczenie z osobami, które powiedzmy migrują do Elixira w tym sensie, że mają już jakieś doświadczenie, nieraz nawet całkiem duże, w programowaniu w innych językach, zazwyczaj obiektowych. Czy taka tranzycja według ciebie – kiedy ktoś już rzeczywiście ma jakiś warsztat, ale taki mocno obiektowy i chce przejść na Elixira – jest łatwa, jest trudna, czy ma to w ogóle jakieś znaczenie, że ktoś ten bagaż doświadczeń obiektowych duży już posiada? 

 

Ja bym może jeszcze do tego dorzucił Exercism.io – to jest taki system do ćwiczenia swoich umiejętności programistycznych, oczywiście w wielu językach, m.in. w Elixirze, gdzie rozwiązuje się poszczególne zadania, które mają rosnący poziom trudności. Swoje rozwiązanie możemy oczywiście sprawdzić lokalnie, ale też wysłać do tej platformy i tam liczyć na komentarz, na sprawdzenie swojego rozwiązania, w takim przyjaznym środowisku. To też jest fajny sposób, żeby albo rozpocząć naukę, albo podszkolić się, robiąc sobie takie codzienne cuty, takie codzienne testy.

 

Oczywiście, ma to duże znaczenie. I to wszystko zależy od tego, czy tej tranzycji dokonuje utalentowany programista, solidny developer, który rozumie różnicę paradygmatów i jest gotowy, by ich świadomie powiedzmy nie mieszać, czy jest to koder, który robi to z musu, zostaje wrzucony na głęboką wodę, znając uprzednio, powiedzmy PHP lub jakiś inny język. Widzieliśmy na własne oczy wiele przykładów, w których do programowania w języku funkcyjnym zabierały się osoby, które kompletnie tego paradygmatu nie rozumiały. Tak że dużo zależy od umiejętności konkretnej osoby. 

Natomiast wspominałem wcześniej o pewnej powtarzanej często opinii o podobieństwie Elixira do Ruby, mówiąc teraz trochę o ludziach, którzy robią tego rodzaju przejście, tak zresztą jak i ja. Trzeba uważać, żeby osobie uczącej się Elixira czy też chcącej potencjalnie to robić nie wyrządzić w ten sposób troszeczkę krzywdy, bo to jest trochę tak, jakbyś powiedział, że turecki jest podobny do polskiego, bo mają podobne alfabety. 

Tutaj w Elixirze oczywiście mamy całkowity brak obiektowości i mutowalność danych, i kolejną najważniejszą różnicą jest podejście do metaprogramowania, ponieważ oba języki są bardzo elastyczne, ale na kompletnie różne sposoby. W Ruby w zasadzie wszystko można monkey patchować dosłownie w dowolnym momencie w run time’ie, klasy i metody można sobie definiować wedle uznania. 

W Elixirze monkey patching jest praktycznie niemożliwy by design, a magiczne generowanie kodu odbywa się w trakcie kompilacji przez ten mechanizm makr, o których wspomniałem. I zasadniczo z chwilą skompilowania apki, jej moduły są zamknięte na wszelkie dodatki, które w Ruby można dodawać, kiedy się chce. To jest bardzo ważna różnica na etapie, w którym np. jako Senior Developer Ruby’iego jesteś asem tworzenia DSL-i przy pomocy metod Missing Define Method i innych kruczków, a nagle stoisz przed językiem takim jak Elixir, w którym, aby ogarnąć metaprogramowanie, musisz zrozumieć, jak działa choćby AST, Parser i inne zagadnienia z makrami związane. I to jest element, który mi najprawdopodobniej sprawił więcej problemów niż sam fakt odejścia od paradygmatu obiektowego do funkcyjnego.

 

Tak, czyli ta świadomość tego, co się robi, jest tutaj kluczowa. 

OK, to teraz może trochę niewygodne pytanie, ale chcę cię zapytać, jakie są problemy, braki w twojej opinii, jeśli chodzi o ten język, ten ekosystem? 

 

Problemy, z którymi mierzymy się, jeśli chodzi o sam język, bo już nie będę tutaj mówił, powiedzmy, o kwestiach już zupełnie pozajęzykowych, to czasami jest to słaba dokumentacja pewnych szeroko używanych bibliotek. Być może ich twórcom czasami brakuje zapału, żeby ją utrzymywać. Czasami jest tak, że dokumentacja rzeczywiście kończy się na READ ME i jest to wszystko, z czym masz do czynienia. Czasami jest tak, że rzeczywiście tego zapału brakuje nawet na rozwijanie samych bibliotek. Np. biblioteka Arc, którą stosuje naprawdę mnóstwo osób, służąca do uploadu plików, poprawcie mnie, jeśli się mylę, ale cały czas jest nieutrzymywana przez jej pierwotnych twórców. 

Inne braki? Ostatnio byłem na ElixirConfie właśnie z prezentacją na temat debugowania i generalnie cały czas szukam takiego złotego środka, jeśli chodzi o narzędzia do analizy kodu pod kątem błędów, które w nim wystąpiły. Tak że są pewne braki. Nie będę tu nawet wspominał o sytuacjach, gdy widzę dostępne gotowe biblioteki konsumujące jakieś API dla innych języków i ich brak do Elixira, dlatego że to jest naprawdę rzecz o mniejszym znaczeniu, jeśli API, o którym rozmawiamy, jest dobrze udokumentowane i da się po prostu zrobić dobry klient HTTP do tego celu, tak że to jest naprawdę coś mniej istotnego. 

Generalnie czasami pojawia się też temat czasów kompilacji, jest to coś, nad czym zespół Elixira bardzo mocno pracuje od kilku przynajmniej wersji. Jest naprawdę wyraźna poprawa w stosunku do tego co było np. w Elixirze 1.8. Głównie związane jest to z pewnymi szczegółami dotyczącymi śledzenia zależności pomiędzy modułami i tego, jakiego rodzaju zależności powinny skutkować automatyczną rekompilacją danego modułu itd. Natomiast ja tutaj widzę naprawdę na tyle ciągły i znaczący postęp, że ufam, że akurat te braki zostaną w pewnym momencie zażegnane i ten czas kompilacji oczywiście będzie się poprawiał. Tutaj jest naprawdę dobrze, jeśli chodzi o odpowiedź na tego rodzaju problemy.

 

Jasne, rozumiem. Chciałbym jeszcze nawiązać do tego, co mówiłem – że pokutuje takie powszechne mniemanie, że języki funkcyjne są trudniejsze niż obiektowe i przez to może się wydawać, że rozpoczynanie swojej przygody programistycznej od języków funkcyjnych to może nie być dobry pomysł. Że trzeba na początku trochę nasiąknąć doświadczeniem, wiedzą i dopiero później ewentualnie dokonać takiej tranzycji. Mówiliśmy już, że to oczywiście nie jest prawda, ale chcę cię jeszcze zapytać, czy według ciebie Elixir to jest dobry język na start w programowaniu?

 

Powiem tak – chciałbym, żeby tak było, natomiast czy tak jest, to w zasadzie zależy od tego, jakie są cechy takiego potencjału intelektualnego osoby, która uczy się programowania, ponieważ są osoby o bardzo różnych predyspozycjach. Jeśli osoby, o których mówimy, mają typowo ścisły umysł, to jak najbardziej programowanie funkcyjne ma przed sobą interesującą przyszłość dla takich ludzi. Ja bym naprawdę chciał spotykać na swojej drodze coraz więcej osób, które w ogóle są, że tak to ujmę, nietknięte takimi zwyczajami związanymi z programowaniem obiektowym. 

Natomiast cały czas jest wiele osób, którym zalecałbym raczej rozpoczęcie od nauki programowania w którymś języku zorientowanym obiektowo, gdyż tak jak mówiłem, rozumiem programowanie funkcyjne – przynajmniej w takim kształcie, w jakim jest ono widziane w Elixirze – jako bardzo mocno skupiające się na takich procesach przetwarzania danych z  jednego stanu w drugi. I niekoniecznie jest to sposób rozumowania, który będzie najłatwiejszy dla każdego na początku obcowania z programowaniem. 

Dla wielu osób paradygmat obiektowy będzie na tyle bliski do sposobu definiowania zjawisk nas otaczających, że będzie to po prostu paradygmat, w którym te osoby będą efektywniejsze. No i fajnie, też będą miały swoje miejsce, takim osobom też kibicuję. Myślę, że programowanie jest prawie dla każdego. Tak że tak, jest to w dużej mierze zależne od tego, jakie dana osoba ma predyspozycje. 

 

Tak jest, od nastawienia i predyspozycji, faktycznie. 

Michał Buszkiewicz był moim gościem, rozmawialiśmy o języku Elixir. 

Michał, bardzo ci dziękuję za rozmowę!

 

Dziękuję również! 

 

Na końcu zapytam cię jeszcze, gdzie cię można znaleźć w internecie, jak się z tobą skontaktować? Gdzie poczytać twoje blog posty?

 

Oczywiście. Dość często piszę content na naszym blogu curiosum.com, tak że tam przede wszystkim zapraszam po jakieś większe kawałki mojej twórczości. Zapraszam też na mój profil na Linkedin. Jeśli chodzi o Twitter, głównie można mnie znaleźć na naszym profilu firmowym @curiosum_dev. To są takie główne miejsca, w których można mnie spotkać. Czasami też piszę na grupach związanych z językiem Elixir, choćby na Facebooku, głównie informując o nowych postach, więc tam też można mnie złapać. 

 

Super. Standardowo wszystkie linki będą w notatce do odcinka. 

Michał, jeszcze raz bardzo ci dziękuję!

Do usłyszenia, cześć!

 

Cześć!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj! Elixir to funkcyjny język programowania, działający na maszynie wirtualnej Erlanga. W najnowszej ankiecie Stack Overflow Developer Survey Elixir zajął 4. miejsce wśród najbardziej lubianych przez programistów języków programowania. Sam od kilku lat działam w ekosystemie Elixira i zdecydowanie polecam!

Jeśli ten odcinek był dla Ciebie interesujący i przydatny, odwdzięcz się, proszę recenzją, oceną lub komentarzem w social mediach. Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o języku Elixir. 

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.