Niezawodność języków programowania na bazie Elixir i Erlang

W ramach podcastu “Porozmawiajmy o IT” miałem okazję opowiedzieć o niezawodności języków programowania na bazie Elixir i Erlang.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Niezawodność języków programowania na bazie Elixir i Erlang - Porozmawiajmy o IT

Dzisiejszy odcinek jest nieco inny, ponieważ jest odcinkiem solowym. Tak naprawdę nie mogę sobie przypomnieć w tym momencie, kiedy ostatni raz realizowałem właśnie taki odcinek, w którym nie ma gościa, nie ma wywiadu, a ja sam wypowiadam się na jakiś temat.

Musiało to być chyba dosyć dawno temu, więc tym bardziej z pewnym entuzjazmem i powiewem świeżości podchodzę do nagrywania tego odcinka. Jestem bardzo ciekawy, czy tego typu treści solowe, gdzie nie ma żadnego rozmówcy, z którym wymieniam poglądy, to jest coś, czego chciałbyś słuchać więcej. Daj mi koniecznie znać, ponieważ to mi też pozwoli planować w przyszłości odcinki — za co Ci oczywiście bardzo dziękuję.

W dzisiejszym odcinku poruszę temat, który jest mi dosyć bliski zawodowo. Będę mówił o językach, z którymi działam od kilku ostatnich lat i które są dla mnie też pewnym powiewem świeżości, bo wcześniejszy okres zawodowy poświęciłem głównie językowi Ruby, frameworkowi Ruby on Rails — to było grubo ponad 10 lat moich doświadczeń zawodowych. W momencie, kiedy przeszedłem na Elixir, kiedy znalazłem ten język, później dowiedziałem się, że on pracuje tak naprawdę na maszynie wirtualnej Erlanga, to można powiedzieć, że doświadczyłem czegoś zupełnie nowego; doświadczyłem zupełnie innego paradygmatu, ponieważ Elixir jest językiem funkcyjnym i to też była dla mnie swego rodzaju świeżość, nowe podejście do rozwiązywania problemów.

Dzisiaj będę się skupiał głównie na niezawodności języków programowani, posiłkując się przykładami z Erlanga i Elixira, natomiast jeśli jesteś zainteresowany tym, żeby usłyszeć więcej o samym języku Elixir, to odsyłam Cię do odcinka 134., który jest poświęcony w całości temu językowi.

Na początku każdego odcinka pytam mojego gościa o to, czy słucha podcastów i proszę, żeby polecił jakieś audycje, o których warto tutaj wspomnieć. Nie muszę pewnie Ci mówić, że ja podcastów słucham na potęgę, jestem wręcz od nich uzależniony, ale też, żeby tradycji stało się zadość, to chciałbym dzisiaj polecić dwa podcasty, na które trafiłem nie tak dawno temu, ale które myślę, że są wartościowe.

Pierwszym podcastem jest podcast Gosi Fraser TECHSPRESSO.CAFE. To podcast technologiczny, ale skupiający się głównie na bezpieczeństwie informacji, na cyber security.

Może niekoniecznie od takiego bardzo technicznego podejścia, czyli narzędzi, sposobów zapewnienia bezpieczeństwa aplikacji, ale o bezpieczeństwie informacji jako takim oraz tym, jak rządy i wielkie korporacje do tego podchodzą. Myślę, że często otwiera oczy ta perspektywa Gosi, zdecydowanie warto tego podcastu posłuchać, bo wszyscy obecnie żyjemy w takim środowisku i takim społeczeństwie informacyjnym, gdzie musimy aktywnie o to bezpieczeństwo informacji z naszego kręgu zabiegać.

A drugi podcast, o którym chciałem powiedzieć, jest zupełnie odmienny, dla fanów fantasy, może dla fanów Sapkowskiego. To będzie naprawdę gratka, ponieważ tym podcastem jest podcast Michała Kuźniara Słowiańskie demony. To są takie raczej krótsze podcasty, które opisują wybrane, najczęściej spotykane w naszym kręgu Europy Środkowej demony pojawiające się w spuściźnie słowiańskiej. Całkiem ciekawy, dobrze opowiedziany podcast, więc zapraszam.

A teraz przejdźmy do przedstawienia niezawodności języków projektowania, posiłkując się przykładami z Erlanga i z Elixira.

Myślę, że nieraz masz okazję zobaczyć gdzieś w internecie tryb maintenance, kiedy aplikacje, serwer muszą być na pewien czas wyłączone, aby określone prace związane z deploymentem, releasem nowej wersji aplikacji albo podniesieniem jakiś komponentów całego systemy mogły się odbyć. Korzystając z jakiegokolwiek tak naprawdę systemu bankowości elektroniczne,j pewnie co jakiś czas masz z tym do czynienia. Tak to już się w tym świecie technologicznym aplikacji webowych dzieje, że ten tryb jest co jakiś czas potrzebny.

Tymczasem gdy spojrzymy na nieco inną, ale bardzo pokrewną dziedzinę, jaką jest telekomunikacja, to tam czegoś takiego praktycznie nie ma. Nowoczesne rozwiązania telekomunikacyjne są oparte, można powiedzieć, na komputerach, maszynach, serwerach, centralkach telefonicznych, które de facto można by porównać do serwerów z rozwiązań webowych, a mogę się prawie że założyć, że nigdy nie miałeś okazji usłyszeć, rozmawiając przez tradycyjny telefon ze swoją babcią, że niestety, musimy za chwilę włączyć tryb maintenance i rozłączyć połączenie, ponieważ na najbliższej centralce będzie wgrywane nowe oprogramowanie. Raczej się to nie zdarza. I warto się zastanowić, dlaczego tak się dzieje

Nowoczesne rozwiązania telekomunikacyjne są oparte, można powiedzieć, na komputerach, maszynach, serwerach, centralkach telefonicznych, które de facto można by porównać do serwerów z rozwiązań webowych, a mogę się prawie że założyć, że nigdy nie miałeś okazji usłyszeć, rozmawiając przez tradycyjny telefon ze swoją babcią, że niestety, musimy za chwilę włączyć tryb maintenance i rozłączyć połączenie, ponieważ na najbliższej centralce będzie wgrywane nowe oprogramowanie. Raczej się to nie zdarza.

Jednym z powodów tak dużej niezawodności rozwiązań w systemie telekomunikacyjnym jest użyty język programowania i cała maszyna wirtualna, na której ten język działa. I tym językiem jest Erlang działający na maszynie Erlanga, nazywanej Beam.

Oczywiście sam język nie jest gwarantem tego, że aplikacja działająca z jego wykorzystaniem będzie niezawodna, bo byłaby to zbyt daleko idąca teoria. Śmiem twierdzić, że wykorzystując nawet najlepszy, najdoskonalszy język programowania, jesteśmy w stanie napisać coś fatalnego. Natomiast oczywiście, posiadając odpowiednie narzędzia, jesteśmy w stanie zbudować coś niezawodnego, coś bardzo dobrego, działającego optymalnie.

Takim narzędziem jest moim zdaniem Erlang. Powstał on w laboratoriach firmy Ericsson — tej znanej skandynawskiej firmie zajmującej się telekomunikacją. W latach 80. zaczęła ona eksperymentować z istniejącymi językami programowania, żeby wykorzystać je do programowania nowoczesnego sprzętu telekomunikacyjnego, który miał obsługiwać mocno narastający i wzmagający się ruch telekomunikacyjny jak na ten czas.

Próbowano różnych języków, ale żaden do końca nie pasował do tej domeny, dlatego podjęto decyzję, że firma stworzy swój własny język do tego przeznaczony. Została powołana pewna grupa, która w ramach firmy Ericsson i pod wodzą Joe Armstronga zaczęła tworzyć ten język, wzorując się na ówcześnie istniejących rozwiązaniach, np. na Prologu, Lispie itp., wręcz pierwszy kompilator języka Erlang został napisany z wykorzystaniem Prologa.

Po kilku latach powstał język, który został przyjęty dość entuzjastycznie przez środowisko, przez partnerów firmy Ericsson i zaczęto coraz intensywniej pracować nad rozwojem tego języka. Firma inwestowała oczywiście w ten język, traktowała go jako swój produkt. Na ten czas oprogramowania open source de facto nie istniały albo były czymś rzadkim, więc język Erlang jako produkt rozwijał się tylko i wyłącznie w ramach firmy Ericsson.

Istotny tu jest też rok 1996, kiedy powstało OTP, czyli Open Telecom Platform, która jest biblioteką dającą mnóstwo narzędzi, wbudowaną już w Erlanga. I tutaj jesteśmy w stanie wykorzystać wiele narzędzi, których używamy w codziennym programowaniu, nie musimy tego tworzyć na co dzień. To nie jest biblioteka standardowa w takim rozumieniu, ale jest zestawem wielu przydatnych narzędzi.

I tak to się stało, że firma Ericsson postanowiła po kilku latach jednak wycofać się z udostępniania tego języka dla swoich partnerów. Przeszła w zupełnie zamknięty wariant, co oczywiście spotkało się z protestem Joe Armstronga i grupy inżynierów tworzących język Erlang. Ta grupa opuściła firma, protestując w ten sposób. Ericsson bardzo szybko się zreflektował, że to był zły ruch i przywrócił wariant open source’owy języka Erlang.

Joe Armstrong z grupą inżynierów po kilku latach wrócili do firmy, język jest cały czas rozwijany, istnieje całkiem sporo konferencji międzynarodowych, więc jest to aktywne community, które nadal rozwija język.

Największym użytkownikiem języka Erlang na ten moment jest oczywiście firma Ericsson wykorzystująca go do zastosowań telekomunikacyjnych, ale wykorzystują go również takie znane firmy jak Facebook, T-mobile czy Goldman Sachs.

Specyfika języka Erlang została dobrana do domeny telekomunikacyjnej, czyli do wielu połączeń, które muszą się odbywać równocześnie, konkurencyjnie, na tej samej maszynie i musimy też mieć możliwość aktualizacji oprogramowania na tej maszynie bez bezpośredniego fizycznego dostępu. Często te centralki telekomunikacyjne są umiejscowione w ten sposób, że raczej fizyczny dostęp jest utrudniony.

Specyfika języka Erlang została dobrana do domeny telekomunikacyjnej, czyli do wielu połączeń, które muszą się odbywać równocześnie, konkurencyjnie, na tej samej maszynie i musimy też mieć możliwość aktualizacji oprogramowania na tej maszynie bez bezpośredniego fizycznego dostępu.

Oczywiście te równolegle trwające połączenia nie mogą na siebie wpływać, powiedziałbym wręcz, że jeśli coś złego się wydarzy, nastąpi jakiś błąd z jednym połączeniem, to nie może to powodować, że wszystkie inne, równolegle obsługiwane połączenia również zakończą się niepowodzeniem. Takie są, dosyć ostre wymagania co do tej domeny telekomunikacyjnej, na której język Erlang działał.

Żeby podać kilka przykładów na to, jak duża jest niezawodność tego języka, to firma Ericsson chwali się takim switchem, który jest rozwiązaniem telekomunikacyjnym, można powiedzieć, że przypomina duży serwer, switch AXD301, który to po 20 latach użytkowania (jest to urządzenie, które cały czas jest produkcyjnie wykorzystywane i cały czas działa) odznacza się bardzo wysoką i rzadko spotykaną niezawodnością. Jak dużą niezawodnością, to pozwolę sobie odpowiedzieć na końcu tego odcinka, więc pozostań ze mną, by dowiedzieć się, o jakiej niezawodności urządzeń telekomunikacyjnych działających na Erlangu możemy mówić.

Innym ciekawym przykładem jest WhatsApp, który zasłynął nie tylko z tego, że gdy w 2014 roku był sprzedawany do Facebooka za 19 mld dolarów, to w tym momencie sprzedaży na platformie było 900 mln użytkowników i tylko 50 inżynierów do obsługi i rozwoju całej aplikacji, a core WhatsAppa jest napisany właśnie w Erlangu.

To pokazuje, jak relatywnie nieduże zasoby ludzkie są potrzebne, żeby utrzymywać tak wielki system konkurencyjnie obsługujący tak wiele połączeń.

Natomiast Erlang ma pewną dość istotną wadę, kiedy się na niego spojrzy, to nie da się ukryć, że wzorował się na językach powstałych w latach 70. ubiegłego wieku i ta składani dosyć daleko ma do czytelności — to jest jeden z głównych zarzutów.

I tutaj na scenie pojawia się nasz bohater José Valim, Brazylijczyk, który mieszka w Krakowie, tutaj założył rodzinę i który działał w core teamie frameworka Ruby on Rails. Tam zajmował się w pewnym momencie takim problemem, trade safety , czyli trybu działania frameworka na serwerze, kiedy wiele wątków wykonujących ten sam kod jest w stanie bezpiecznie i konkurencyjnie ten kod wykonywać.

I José sprawdzał, jak podobny problem jest rozwiązywany w innych językach, i tak m.in. trafił na Erlanga. Natomiast też uderzyło go to, że czytelność Erlanga nie była na najwyższym poziomie, powiedział nawet, że zakochał się we wszystkim tym, co znalazł w Erlangu, ale znienawidził to, czego tam nie znalazł.

Chodziło mu o to, że zakochał się w całym ekosystemie, w całym bogactwie różnych rozwiązań, które już są w Erlangu, i tej zapewnionej niezawodności, ale brakowało mu właśnie community, nowoczesnych narzędzi, czytelności języka.

Postanowił więc to zmienić i w roku 2012 stworzył język programowania Elixir, który działa na maszynie wirtualnej Erlanga, kompiluje się do tego samego byte codu, jednak składniowo jest bardzo podobny do Ruby’ego, czyli do języka, który był bliski autorowi, ale charakteryzuje się dużo lepszą czytelnością i wygląda jak nowoczesny język programowania.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-186-niezawodnosc-jezykow-programowania-na-bazie-elixir-i-erlang/