Szymon Warda: Cześć słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io lub gdzieś tu na dole, poradzicie sobie. No dobrze Szymonie, o czym dzisiaj?

Szymon Warda: A dzisiaj mamy gościa niezwykłego. Dodam taką historię. Dawno, dawno temu miałem mieć prelekcję na 4Developers, moja pierwsza prelekcja. Zarąbista gorączka, 39 stopni, generalnie cały pod kołdrą, upocony. Odpuszczamy? Nie, dobra, pójdę. Robię tą prelekcję. Na koniec prelekcji podchodzi do mnie jakiś koleś i zaczyna coś mówić generalnie do mnie. Ja mówię w ogóle o co w ogóle chodzi, a on na końcu wrzuca: ale co, to Ty nie wiesz kto jest prowadzącym Twojej ścieżki? Z taką pełną szczerością: nie mam zielonego pojęcia. Na co Jarek mówi: to ja jestem. A to się fajnie wiąże, bo prelekcja była o czym? Była baza graphowych swoją drogą.

Jarosław Pałka Tak.

Szymon Warda: Kółko zatoczyło pewną historię, że tak powiem. Dobra, ale teraz tak poważnie. To jest wielka przyjemność, Jarek Pałka, Senior Staff Performance Engineer w Neo4j. Programista na ostatniej prostej przed emeryturą, chyba do tej emerytury masz jeszcze kawałek, wydaje mi się, który ciągle programuje i pasjami zagłębia bazy danych, języki programowania i maszyny wirtualne. Ciągle wychodzi z traumy bycia managerem i architektem. Tej traumy to chyba trochę pozbierałeś, faktycznie. Witamy, witamy.

Jarosław Pałka Dzień dobry. Bardzo, bardzo wczesne dzień dobry.

Szymon Warda: Nie takie wczesne.

Jarosław Pałka W moim wieku dzieci drogie… Dobra, to bez przesady.

Szymon Warda: Dobrze, to o czym dzisiaj będzie? Dzisiaj chcieliśmy z Tobą porozmawiać głównie o JVM, bo w tym JVM siedzisz dużo. Znasz się chyba najlepiej z osób, które ja znam. Tak że zacznijmy. Czym w ogóle jest JVM?

Jarosław Pałka Czym jest JVM? Ja kiedyś na jakiejś prelekcji też miałem zagwozdkę, jak to wytłumaczyć. Wymyśliłem sobie, że to jest nieistniejący komputer. Bo tak naprawdę maszyna wirtualna, bo JVM nie jest jedyną maszyną wirtualną, jest jakimś tam bytem abstrakcyjnym nad sprzętem. Czymś, co abstrahuje nam w jaki sposób nie tyle jak system operacyjny, czyli tam mamy sterowniki, dyski, urządzenia, bo tak naprawdę ta abstrakcja jest głównie nad procesorem, że mamy sobie abstrakcyjny, wymyślony procesor po to, żebyśmy mogli wykonywać ten kod napisany raz. Nie wiem czy pamiętacie tą reklamę jak JVM się pojawił? W ogóle dlaczego się pojawiła? Write once, run everywhere. Różnie z tym bywało na początku, teraz też różnie z tym bywa. Ale maszyna wirtualna, można by chyba tak najlepiej powiedzieć, że to jest biblioteka. Czasami niektórzy mówią, że to jest manage runtime według klasyfikacji języków programowania. Czyli to jest taki kawałek kodu, który wykonuje nasz kod wygenerowany na ten nieistniejący procesor, czyli ten nasz bytecode i jednocześnie wykonuje całą masę rzeczy. To jest narzędzie powstałe dlatego, że programiści są leniwi i to rozwiązuje problemy leniwych programistów. Więc abstrakcyjna maszyna, która rozwiązuje problemy leniwych programistów.

Łukasz Kałużny: Dobra, ale jak pójdziemy po Javie, bo tam rzuciłeś też o rysie historycznym, z Javy stworzonej przez Suna. I słuchaj i potem jak popatrzymy, to co chyba było kluczowe, to zmiany licencyjne Oracla, które się wydarzyły w ostatnich latach. To była taka… Nie wiem, czy jeżeli patrzymy na rys historyczny Javy, czy jest to z Twojej perspektywy, osoby siedzącej niskopoziomowo w JVM-ie, czy ta zmiana była istotna czy nie, z takiej perspektywy tego, co się dzieje? Po przejęciu Oracla i potem już próby zarobienia mocno przez Oracla na tej licencji JVM-owej.

Jarosław Pałka Wiesz co, dla mnie to jest temat strasznie kontrowersyjny, bo ma znamiona clickbait’u moim zdaniem. Ja przez swoje 20 lat wokół JVM-a cały czas kręcąc się i orbitując nie pracowałem w firmie, która miała wykupioną licencję Javy oracle’owej ani sunowskiej. Wszystkie systemy produkcyjne, które ja miałem, a były to różnej maści duże rzeczy, bo było w tym też np. Allegro, działały na jakichś tam wersjach open source’owych tej maszyny wirtualnej. Bo musimy sobie wyjaśnić jedną bardzo ważną rzecz. Tak naprawdę mamy trzy główne drzewa JVM-a. To jest tak, jak trochę z Linuxami, był ten System 5 i było BSD, był Berkeley i był system Five i to były jakieś tam dwie główne gałęzie Linuxa. To tak można sobie popatrzeć na to jak to wygląda w Javie, że mamy tą postsunowsko-oracle’ową działkę, którą na potrzeby dyskusji nazwiemy hotspot i większość maszyn wirtualnych, na których ludzie pracują, to są rzeczy, które wyszły z hotspota. To tak naprawdę jest hotspot z jakimiś tam dodatkami. No i mamy tą, ja też w życiu nie widziałem produkcyjnie tego wykorzystanego, ale nie miałem przyjemności pracowania w bankach. W tym momencie to się nazywa OpenJ9, czyli maszyna wirtualna stworzona przez IBM-a, maszyna wirtualna Javy, która implementuje specyfikację Javy, stworzona przez IBM. No i tam po drodze są pomniejsze krzaki. Czyli swego czasu był taki projekt Apache Harmony, który chciał zrobić kompletnie open source’ową maszynę wirtualną od zera. Są różne dziwne eksperymenty za naszą wschodnią granicą. Ja już nie pamiętam jak to się nazywało, Excalibur czy Incelsior? Więc jest tam, są jeszcze takie jakieś eksperymentalne na potrzeby edukacyjne maszyny wirtualne typu JAX. Ale tak naprawdę większość z nas pracuje na czymś, co wychodzi z hotspota. To jest jakby główna gałąź rozwijana, gdzie jest rozwijana teraz maszyna wirtualna, gdzie powstaje, rozwijana jest Java i cała ta reszta. I dla mnie całe to zamieszanie licencyjne to jest clickbait. I chyba wydaje mi się, mam wrażenie, nieudany skok na kasę Oracle. Oni mnie nigdy nie zatrudnią. Ja ostatnio mam jakieś tendencje, jakieś głośne mówienie na ten temat.

Łukasz Kałużny: Nie martw się, tu też z nich sobie żartujemy, więc…

Jarosław Pałka Czyli to jest dobre miejsce. Jesteśmy w bezpiecznym miejscu.

Łukasz Kałużny: Tak, jesteś bezpieczny, tak, jesteś w tym miejscu. Jarek, mi jeszcze MVP nie odebrali, Microsoft mi jeszcze nie odebrał, więc…

Jarosław Pałka Może nie mają czasu na takie rzeczy. Więc ja rozumiem organizacje, których, ja to nazywam zarządzanie przez Komitet architektów. Czyli na wszystko masz komitet. Jest komitet od kupowania nowych licencji, jest komitet do podejmowania decyzji, czego używamy, jest komitet od wybierania architektury. I w takich dużych organizacjach i myślę szczególnie jakichś tam właśnie finansowo, ubezpieczeniowo, które gdzieś są mocno regulowane, ja sobie wyobrażam, że ta sytuacja jest skomplikowana dla nich. Ponieważ oni w tym momencie muszą po tej zmianie licencji, w momencie, kiedy chcą utrzymywać patche security po tym, jak się skończy nasz LTS i skończy się support dla tej wersji, no to muszą zacząć płacić Oracle’owi i muszą Oracle’owi płacić za support, za szybkie rozwiązywanie błędów, za możliwość zgłaszania security vulnerabilities i naprawiania ich. Więc wyobrażam sobie takie miejsca, w których nie byłem, więc są dla mnie abstrakcyjne, że rzeczywiście ktoś, kto ma licencję Oracle, płaci. Płaci jak za wołu. Czyli, ja nie pamiętam teraz, było tak, że to było od głowy, że ta licencja była od ilości ludzi w organizacji.

Łukasz Kałużny: Wiesz co, może nie wchodźmy w to. Wiesz co, ja bym rzucił tak, tam jest część, której jeszcze nie wszyscy mają świadomość, że np. jakieś regulacje prawne narzucają właśnie wymaganie posiadania supportu czy aktualności i innych rzeczy. To czego np. większość nie wie, że banki np. w Polsce muszą do KNF-u raportować wykryte podatności i jak szybko je usunęli.

Jarosław Pałka Dokładnie, dokładnie w tym momencie, kiedy jesteśmy w miejscu, gdzie… To klasycznie, to jest środowisko, w którym Oracle czuje się dobrze, bankowość i ludzie, którzy mają dużo pieniędzy. Więc myślę, że na pewno to stanowi jakąś tam część ich budżetu, ale nie wiem, czy to stanowi jakiś fantastyczny zysk dla nich, bo ta ilość organizacji jest jest niewielka. Chociaż być może płacą absurdalny haracz, który powoduje, że my biedaki możemy używać Javy za darmo, ponieważ duże banki za to płacą. I mamy jakieś tam rzeczy związane właśnie, tak jak Ty mówisz, z regulacją formalnie, itd. Myślę, że to też wynika z tego, że takie organizacje mają… To jest trochę taka gra na słabościach. No bo zauważcie, że teraz wychodzą dwie wersje Javy w roku. Te organizacje duże nie są znane z tego, że one chętnie migrują do nowych wersji. Ja pamiętam taką organizację w Krakowie, w której pracowałem, w której podbicie takiej biblioteki do C++, która nazywała się Boost z wersji nie pamiętam, wymyślę, ale chodziło o Minor, powiedzmy 1.45 na 1.46 zabrało dwa lata dyskusji czy to jest dobra decyzja. W międzyczasie pojawiła się już wersja 2.0 tej biblioteki i myślę, że tu jest ten problem, że Java na tyle szybko w tym momencie się rozwija i kręci i pojawiają się nowe wersje, że Oracle jest świadom tego, że te organizacje pewnie są ciągle jeszcze na ósemce, albo będą na tej ósemce tak długo, aż ostatni żyjący programiści znający ósemkę nie odejdą. Więc muszą w związku z tym, że polityka upgrade’ów i polityka przechodzenia na nowe wersje oprogramowania jest ich organizacja jaka jest, więc bezpieczeństwo ponad wszystko i zapomnijmy o innowacjach. Ale rozumiem, chodzi o nasz hajs, nie wszyscy muszą żyć na krawędzi. Ale w związku z tym, że oni nie mogą się tak szybko upgrade’ować, więc są gotowi zapłacić ten haracz, żeby te wszystkie wersje wstecz były trzymane.

Szymon Warda: Okej, a teraz właśnie mówisz o upgrade’zie, mówisz, że się dzieje tak naprawdę. To jak obecnie wygląda w ogóle rozwój JVM? Co tam się zmienia? Co się dzieje?

Jarosław Pałka JVM nie żyje, to jest stary. Śmierć. JVM, jest jak rock and roll i to umiera od 50 lat.

Łukasz Kałużny: Jak [niesłyszalne 00:11:35]. No ale dobra.

Szymon Warda: Dobra.

Jarosław Pałka Ja uwielbiam te dyskusje, uwielbiam. A potem wiesz… O Boże, spokojnie, serce mi zaczęło szybciej bić, bo się denerwuję. Bo najpierw na konferencji na korytarzu słyszę, że JVM odchodzi i teraz to, ostatnio głównym wrogiem JVM jest albo Rust albo Web Assembly.

Jarosław Pałka Ale spokojnie, myśmy się okopali na swoich stanowiskach i patrzymy jak tam biegają chłopaki bez tarczy i bez zbroi i czekamy aż się pozabijają sami.

Szymon Warda: Z majtkami w okolicy kostek.

Jarosław Pałka Dokładnie, dokładnie, dokładnie, bo tam w Rust’cie kiedyś była akcja z Rustem, że się zaczął forkować, bo się chłopaki pokłócili, tam jakieś emocje wjechały. Więc ja uważam, że JVM ma się dobrze, ma się nawet bardzo dobrze. I mówię JVM, specjalnie JVM, bo musimy sobie jasno powiedzieć, że Java to jest jeden z języków dostępnych na JVM-a, domyślnie. JVM jest platformą z abstrakcyjnym procesorem, jest abstrakcyjny procesor. Możemy sobie wymyśleć dowolną ilość języków działających. Ja widziałem ostatnio szalony projekt przepisania C w Javie, w JVM-ie, przepraszam.

Szymon Warda: Takie kółko może zatoczyć właściwie, C w Javie, Java w C.

Jarosław Pałka Dokładnie i tak się możemy bawić. Żółwie all the way down. I co jest ciekawe z tym przepisywaniem, to chłopaki polegli na tym, że w specyfikacji C jest coś takiego jak undefined behaviours. Czyli mamy takie zachowania, które wymykają się ze specyfikacji i nie jesteśmy tego w stanie zasymulować w JVM-ie, ponieważ JVM jest manage environment i to ma pewne swoje konsekwencje. JVM ma się świetnie. I co mnie irytuje to wiesz, ci wszyscy, którzy głoszą koniec JVM, koniec Javy, nadejście zimy. Potem pytanie na konferencji: na której wersji jesteście? Albo: czy znacie ten feature, czy mają pokornie rączki przy sobie? Więc wiesz, tak jak u nas w branżuni dużo straszenia i machania ręką. JVM ma się świetnie. I myślę, że to co najbardziej pomogło JVM-owi, to jest wejście w ten release train, gdzie mamy dwa release’y w ciągu roku. Ja mam wrażenie, że w tym momencie większość ludzi nawet nie ogarnia, co jest w nowej wersji, nawet jeśli są na tej nowej wersji. Bo to jest piękno JVM-a, Ty możesz przejść na nową wersję JVM-a nie zmieniając języka. Co jednocześnie jest przekleństwem JVM-a, bo ten proces deprekacji pewnych rzeczy zajmuje lata. Do tej pory niektórzy się śmieją, że mogą uruchomić kod, który został skompilowany wersją 1.1, co już nie jest prawdą, bo chyba wyrzucili wsparcie. Ale przez długi czas byłeś w stanie odpalić kod, który nie tyle był napisany, ale zbudowany JVM-em w 1995 i dalej sobie spokojnie mykał na nowej wersji.

Łukasz Kałużny: Czyli JVM przeżywa to co developerzy kernela windowsowego.

Jarosław Pałka A co chłopaki przeżywają?

Łukasz Kałużny: Win API 16 jeszcze miał [niesłyszalne 00:15:00]…

Jarosław Pałka Wiecznie żywe, wiecznie żywe.

Łukasz Kałużny: Wiecznie żywe, tak.

Jarosław Pałka No powiem Ci, to był jeden z zarzutów i jeden z takich elementów blokujących rozwój, że cała polityka zarówno Suna i Oracle’a była taka, że co zostało napisane ma działać, nie pozwólmy sobie, nie łammy kompatybilności wstecznej. Wiele feature’ów języka wygląda tak, jak wygląda dlatego, że nie chcieliśmy złamać kompatybilności wstecznej. To przez to teraz… Dlatego, że wychodziła jedna wersja na 10 lat. Teraz jak mamy ten wymuszony Kadence co pół roku, to powoduje, że możemy sobie pozwolić na łamanie kompatybilności wstecznej, bo mamy cały ten program, że mamy inkubację feature’a, potem mamy stabilizację, potem on zostaje featurem. Tam jest cała polityka wchodzenia nowych rzeczy zarówno do języka jak i JVM-a, są rzeczy, które np. nie wyszły poza fazę inkubacji, mamy fazę preview. Więc tam teraz chłopaki mogą sobie spokojnie biec nie szkodząc nikomu tak bardzo, jak szkodzili z wychodzeniem z nowych wersji. Więc ja uważam, że JVM ma się świetnie. Tylko, że w tym momencie ci wszyscy, którzy narzekali, że nic się nie dzieje, siedzą i zastanawiają się, czy może jednak lepiej by było, żeby była jedna wersja na pięć lat.

Łukasz Kałużny: Czyli klasyczne nie ogarnianie kuwety.

Szymon Warda: Tak, tak.

Jarosław Pałka No myślę, że się absurdalnie teraz… Wczoraj chyba widziałem listę tego, co ma się pojawić w następnym LTS-ie, czyli 2024… Java 24 i ta lista jest naprawdę, jak dowiozą będzie super.

Łukasz Kałużny: Słuchaj, bo właśnie mówisz, że chłopaki, bo…

Jarosław Pałka Tak, nie chłopaki, dziewczyny.

Łukasz Kałużny: Dziewczyny, ja bardziej trochę odnoszę się do tego słuchaj, kto tak naprawdę teraz do JVM-a kontrybut? Bo jak sobie popatrzysz, to co stoi za tym projektem, można byłoby ukrócić. Gdzie tam realnie jest kasa za tą kontrybucją? Bo no nie oszukujmy się, projekty open source’owe trochę przestały być, tej skali projekty przestały być trochę rzeczami dla idei i ktoś za czas pracy developerów, którzy kontrybuują w ten czy inny sposób, płaci. Więc takie moje pytanie jest oprócz tego gdzie jest kasa, to kto kontrybuuje i dlaczego tam kontrybuuje?

Jarosław Pałka Wiesz co, z hotspotem, bo o tym mówimy, skupmy się na tym, to jest tak, że przez długi czas mówiło się, że hotspot to jest referencyjna implementacja JVM-a, jakkolwiek by to nie brzmiało. No i rzeczywiście tak jest, że te wszystkie nowe rzeczy są testowane na hotspocie i J9, czy jakieś inne próby zbudowania JVM od zera muszą gonić to, co robi Oracle. I sytuacja jest taka, że Oracle trzyma w ręce JVM-a głównie przez to, że płaci kilku wariatom pensje. Mam na myśli Marka Reinholda, Briana Goetza czy kolega Rose czy Alex Barkley, gdzie ci ludzie siedzą i kminią. To są ludzie, którzy przychodzą z tymi największymi zmianami w JVM-ie w sensie koncepcyjnym. To oni głównie płacą tym ludziom, którzy myślą: dobra, co następne będzie w JVM-ie? Czego nam brakuje? Co musimy zrobić, żeby JVM był bardziej cloud friendly? Co musimy zrobić, żeby pociąg AI nie odjechał? No bo trochę się wymknęło to spod kontroli, bo nagle Python zaczął królować w tym świecie ML-a i automatycznie… I tutaj wiesz, kilka zmian w JVM-ie wynikało, moim zdaniem, z tego, że patrzyli na to, jak Python odjeżdża, jeśli chodzi o świat ML i AI. Więc jak gdyby głównym kontrybutorem i głównym sponsorem jest Oracle, zatrudnia większość ludzi, którzy do tego kontrybuują. Architekci czy ludzie, którzy gdzieś tam podejmują najważniejsze decyzje, to są ludzie z Oracle. Ale oprócz tego mamy Red Hata, mamy IBM-a, mamy Amazona i mamy Microsoft. Surprise, surprise. Powiem ci, że piekło zamarzło, ale wiesz…

Szymon Warda: To już dawno temu.

Jarosław Pałka Chodzi o pieniądz, panie.

Szymon Warda: Jak MS powiedział, że Microsoft loves Linux, wtedy już zamarzło.

Jarosław Pałka Dokładnie. Wiesz, bo idea ideą, ale pieniądz pieniądzem. I jak sobie popatrzycie na kontrybutorów i SAP, to też trzeba by jak gdyby…

Łukasz Kałużny: Ale oni mają bardzo prosty, SAP ma prostą potrzebę kontrybucji.

Jarosław Pałka To znaczy?

Łukasz Kałużny: Idącą za tym, co sprzedają biznesowo.

Jarosław Pałka To teraz odpowiedziałeś na wszystkie pytania. Dlaczego Amazon się w to pcha? Co Amazon sprzedaje? Amazon sprzedaje EC2 AWS-a, co jest większością. W związku z tym, że główną platformą niestety, jakbyśmy nie chcieli patrzeć na wyniki, to jednak Java jest dominująca w tych rozwiązaniach mocno. Nie wiem czy wygrywa czy nie, ale gdzieś tam jest w topce, jeśli chodzi o jakieś tam rozwiązania backendowe. To w tym momencie chcesz zrobić dobrze swoim klientom, więc chcesz się upewnić, że ta platforma, na której Twoi klienci tworzą, czyli Java, będzie na twoim AWS-ie świetnie śmigała. No i stąd Coreto, które tak naprawdę jest hotspotem podkręconym, podtuningowanym pod AWS-a, który oczywiście jest kontrybuuowany, te rzeczy są kontrybuowane z powrotem, tak jak np. projekt CRACK. To samo jest, wiesz, z IBM-em, bo on widzi, że ten OpenJ9 nie do końca działa. To była maszyna wirtualna, która powstała specjalnie na potrzeby świata J2ee, to jest dopiero historia. Ludzkość czasami zapędza się w taki kozi róg, ale dalej w tym kozim rogu stoi i krzyczy, że jest super. Ale J9 powstał tak naprawdę, jeśli ktoś deplayował Liberty i nie pamiętam jak się dokładnie to IBM-owskie dzieło nazywało, nie pamiętam już, to było dawno temu, to to robił na J9, ale nikt poza tym tego J9 nie używa. Red Hat, wiadomo, kontrybucje Red Hata i te rzeczy związane z IIS-em, które on tam miał. Więc jak sobie popatrzycie, to Microsoft, ja słyszałem kiedyś rozmowę, gdzie ktoś, nie pamiętam albo nie wiem, nie mogę powiedzieć może nawet, ktoś jasno powiedział: bardzo dużo klientów na Azure jest na Javie. To jest w naszym interesie, żeby to śmigało.

Łukasz Kałużny: Wiesz co, ale oni zakupili, nawet tam było swego czasu, jClarity bodajże to z Zulu.

Jarosław Pałka Wiesz co, oni nie dość, że kupili produkty, to oni jeszcze kupili ludzi. Monica Beckwith, architekta G1 garbage collectora jest w Microsofcie. Kirk Pepperdine, jeśli chodzi o jakieś rzeczy wydajnościowe w Javie, jest w Microsofcie. Ja się zastanawiam jakim cudem nie udało im się podkupić Alekseya Shipileva, który jest dla mnie absolutnym guru jeśli chodzi o JVM. Ale Aleksey jest teraz w AWS-ie. Popatrz, co się stało, że ci ludzie, Marcus Lagergren, który co prawda teraz trochę się, że tak powiem, wykleił ze świata JVM, ale swego czasu był człowiekiem, był moim bohaterem, jeśli chodzi o rzeczy, które robił, to gdzieś tam pracuje w tych okolicach. Więc oni też wyciągnęli, bo wyciągnęli tych ludzi i Microsoft i IBM i inne organizacje i AWS do siebie. Przecież Alibaba ma swojego własnego klona hotspota, który się nazywa Dragonwell. Więc cała ta zabawa polega na tym, że przez tą masę ludzi, którzy piszą w tej Javie, to spowodowało, że fajnie by było mieć te nasze chmury i te nasze produkty zoptymalizowane pod to. I dlatego się to tak kręci. Więc ten hajs nie jest bezpośrednio w JVM-ie, bo ten hajs bezpośrednio w JVM ma Oracle, który kosi na bankach, a cała reszta tak naprawdę walczy o to, żeby ci klienci przyszli do nich, bo oni mają najbardziej zoptymalizowanego JVM-a pod swoją chmurę.

Szymon Warda: Ale też druga opcja, ten JVM, który u nich chodzi, potencjalnie kosztuje ich najmniej. Te małe procenty się zbierają przy tej skali i to po prostu…

Jarosław Pałka Tak, to też jest osobna sprawa, że oni tak naprawdę wiesz, przy tej skali każda nanosekunda, każdy zaoszczędzony kilobajt, to są realne jachty, prawdziwe jachty dla dla executive’ów.

Łukasz Kałużny: Dobra, słuchaj, a ja bym jeszcze jedną rzecz, bo jak widzieliśmy się w Rzeszowie na konferencji, wspomniałeś, że tam piekło zamarza, czasami jeszcze bardziej na zasadzie, nie pamiętam, czy z garbage collectorem czy z czymś, wspomniałeś, że ktoś z Microsoftu wyskoczył, że: może zaimplementujmy to tak jak w .Necie pod spodem. Wspominałeś, jakbyś mógł powiedzieć o tej historii, że też te firmy przynoszą swój know how z innych zupełnie rozwiązań.

Jarosław Pałka Te rzeczy, ja ostatnio się przewróciłem, a to wam powiem później, ale przewróciłem się, jak się dowiedziałem, że pewna znana osoba ze świata .Neta pracowała przy pierwszej wersji Javy. Więc ta historia, o której Ty mówisz, to jest sytuacja związana z tym, że Java ciągle walczy. Tak naprawdę chłopaki z JVM ciągle walczą o to, żeby można było alokować obiekty na stosie, żeby te krótko żyjące obiekty można było alokować na stosie, nie stercie. Chodzi o to, żeby ten garbage collector nie wchodził nam w paradę tak często. Szczególnie ten cały funkcyjny paradygmat, który bardzo mocno opiera się na tym, że alokacja na stosie jest fundamentalna i Java pchnęła się w którąś stronę w momencie, gdy ten funkcyjny. Zrobiła taki fajny… Fajny, moim zdaniem nie do końca, jeszcze nieskończony projekt amalgamatu funkcyjnego z obiektowym. Ale Java nie ma alokacji na stosie. Ma coś takiego jak, Boże, jak to się ładnie nazywa, skalaryzacja obiektów. Ale nie ma alokacji na stosie. I w pewnym momencie Microsoft zasabmitował patcha, w którym do kompilatora wewnętrznego JVM mówiąc: słuchajcie, myśmy to zrobili tak i myśmy to przepisali pod JVM-a, macie to tutaj. Spokojnie, ten patch nie wszedł jako taki, bo tam jakieś inne plany były, ale wynikiem tego patcha jest poprawiona wydajność… Znaczy nie tyle wydajność, co przewidywalność, escape analysis. Więc teraz jest taka technika, która w JVM służy do sprawdzenia, czy obiekt można zalokować na stosie i to jest dosyć skomplikowany algorytm. I widziałem ostatnio poprawki od Microsoftu, który skuteczność tych przewidywań zwiększył o jakieś 12%, więc o ileś tam procent mniej obiektów możemy zalokować na stercie, możemy je zrobić na stosie. Ten patch ciągle jest chyba na GitHubie i tam jest ładnie napisane, że: myśmy w tej wersji .Netu zrobili to i tak i zrobiliśmy retrofitting tego algorytmu pod JVM-a, jakbyście chcieli to sobie wejdźcie.

Szymon Warda: To ja dorzucę taką ciekawostkę, bo o ile pamiętam, to .Net chyba 1.1 albo 1.0, jeszcze ten stary, stary, stary. Tam była taka kompatybilność, że rzeczy pisane w .Necie, albo można było odpalić na JVM, albo rzeczy javowe można było odpalić na .Necie, na runtime’ie. I z tego korzystała nawet jedna duża polska firma i pisała swój system Enterprise, przez co potem nie chcieli z tej wersji w ogóle zejść.

Jarosław Pałka Dokładnie. A dlatego się to tak stało, że człowiekiem, który pracował nad pierwszymi speckami JVM-a był Ted Neward. A Ted Neward kręcił się przy .Necie. Jego znamy głównie z prezentacji o architekturze, ale to był człowiek, szpieg w krainie Deszczowców, który jak sobie popatrzycie na niektóre tzw. Java enhancement proposal, czyli formalne dokumenty opisujące zmiany w języku i w maszynie wirtualnej, to tam nazwisko Teda Newarda się pojawia. Wiesz, ciężko by było, ja się też kiedyś zastanawiałem, dlaczego się tak dzieje i to w wielu językach mamy przenikanie się i pojawiają się te same nazwiska, pojawiają się te same koncepty, ponieważ ludzi, którzy siedzą i rozumieją budowanie języków na świecie jest skończona ilość.

Szymon Warda: Niewielka.

Jarosław Pałka To nie jest najbardziej popularna dyscyplina sportu. To jest trochę jak curling, fajnie się ogląda, ale nikt nie chce w to grać. I myślę, że to też z tego wynika, że to źródło tych idei, co zrobić z tymi maszynami wirtualnymi, jak rozwijać te maszyny wirtualne, jak rozwijać języki, to jest skończona ilość osób, które gdzieś tam ogarniają to i one się ze sobą spotykają. Ja myślę, że oni są jak politycy, wiesz, oni krzyczą na siebie publicznie, a potem idą razem na piwko i zastanawiają się, jak sobie tam rzeczy w językach naprawić. Więc tak, ta współpraca jest dosyć mocna, przynajmniej na poziomie tych ludzi, którzy pracują nad koncepcją.

Szymon Warda: Dobra, to mówimy o ludziach w takim razie. A w takim razie jak się ma w ogóle obecna społeczność JVM-owa tak naprawdę? Jak to wygląda?

Jarosław Pałka Nie wiem panie, ja w piwnicy od 6 lat siedzę.

Szymon Warda: Ludzi nie widzę.

Jarosław Pałka Powiem Ci, ostatnio ktoś mnie zapytał, czy są jakieś nowe firmy w Krakowie? A ja mówię: zakopałem się w tych graphach i w tym performance. Więc tak jak wychodzę z domu, to przez 15 minut mrużę oczy i zasłaniam się, bo mnie razi słońce. Wiesz co, wydaje mi się, że jest ciekawie na wielu poziomach. Bo z jednej strony dostarcza nam zabawy sam Oracle wypuszczając kolejne nowe wersje, więc są emocje. I np. Project Loom, który rozpalił ostatnio wszystkie fora i wszystkie dyskusje i odmiana po prostu wirtualnych wątków przez wszystkie przypadki, bo to jest jedna z takich rzeczy gorących, która się pojawiła.

Łukasz Kałużny: Czyli trochę próbowanie złapania modelu korutyny wreszcie w Javie, jeżeli dobrze kojarzę.

Jarosław Pałka Tak naprawdę korutyny, jeśli wejdzie, to co ma wejść w 24, to my jesteśmy w domu, jako Platforma, żeby to sobie już zaimplementować poważnie, bo te wszystkie rzeczy związane ze współbieżnością i korutynami w Javie, no to była mocna prowizorka. I teraz, jeśli my dostaniemy niskopoziomowy mechanizm, taki właśnie jak wirtualne wątki i możliwość samemu schedule’owania wątków, a nie przez system operacyjny, to my będziemy mieli oczywiście nie 100% kontroli, ale większą kontrolę nad tym, to rzeczywiście będzie można na poważnie mówić o korutynach w Javie. Więc z jednej strony mamy tę dyskusję o tych fascynujących rzeczach typu Project Loom, niekończący się wiecznie projekt Valhalla. Ale jak on wejdzie, to naprawdę będzie Valhalla, jak wejdzie.

Szymon Warda: A możesz przybliżyć co to są za projekty dla słuchaczy?

Jarosław Pałka Wiesz co? Tak. Project Loom to są wirtualne wątki, czyli możliwość odpalenia… To jest taki model N do M, bo teraz mamy 1 do 1, czyli jeden wątek Javy to jest jeden wątek systemu operacyjnego. A teraz z wirtualnymi wątkami mamy bardzo lekkie wątki, w sensie nie potrzebują alokacji pełnego stosu. To nie jest wątek systemu operacyjnego, to jest wątek zarządzany przez Javę. Ten narzut na pamięć jest nieduży. One oczywiście są wykonywane w obrębie tak zwanych wątków systemowych. Trochę to tak Erlangiem śmierdzi, jak sobie tak pomyślicie o tym modelu procesów i przez to, że możemy sobie… Odpalenie takiego wątku jest bardzo tanie i możemy sobie te wątki tworzyć w dowolnej ilości. I maszyna wirtualna na chwilę obecną, np. jeśli wykonujemy operację IO, to ten wątek schodzi. Mamy tzw. kontynuację, więc możemy sobie zatrzymać metodę w połowie zafreeze’ować, ściągnąć ją z procesora, puścić inny wątek. A to jest jak gdyby w skrócie, w wielkim skrócie projekt Loom. A projekt Valhalla to jest cała bitwa o to, żeby naprawić, usprawnić model organizacji pamięci trochę. I tego, że u nas wszystko było ciężkim obiektem, który miał identity zanim był alokowany na chipie. I projekt Valhalla będzie nam pozwalał tworzyć własne typy prymitywne, bo w tym momencie w Javie mamy typy prymitywne, te, które nam dostarcza platforma. I mimo tego, że będziemy tworzyć własne typy prymitywne, to będą one się zachowywać jak obiekty, mimo tego, że tymi obiektami nie będą. Konsekwencji jest tego cała masa, szczególnie jeśli chodzi np. o layout w pamięci, jak to będzie wyglądać. Więc projekt Valhalla bardzo dużo zmieni, jeśli chodzi o to, w jaki sposób i jak bardzo Java jest pamięciożerna. To jest jedna rzecz. A druga rzecz, to oczywiście mechanika sympatii. W związku z tym, że w Javie cierpimy na pointer chace’ing, bo jak masz kolekcję w Javie, to jest to kolekcja wskaźników, więc jak gitarujesz po tej kolekcji, to latasz po pamięci jak wariat po każdym, nie masz sekwencyjnego odczytu, a wiemy, że procesory jeżeli coś lubią to sekwencyjny odczyt.

Szymon Warda: Cache.

Jarosław Pałka Więc jeżeli my sobie w projekcie Valhalla będziemy w stanie pozbyć się wskaźników i po prostu ułożyć sobie te dane jedne po drugim, bite po bajcie, no to w tym momencie już widzimy, że automatycznie nam to fajnie przyspieszy. Więc jak gdyby jest bardzo duża dynamika po tej stronie. Z drugiej strony, po czym ja poznaję, czy język, czy środowisko jest żywe? Po ilości flame warów i po ilości emocji, które budzą. Bo z jednej strony mamy Javę, JVM, który przynosi nam dużo zmian, z którymi różnie się ludzie nie zgadzają, zgadzają, mniejsza z tym, ale są emocje, to się przetacza. To jak podniesiesz ten temat, to tam się toczą emocje. Z drugiej strony ewoluuje sam język. No i tutaj mamy tą walkę Goliata z Dawidem. Czyli najpierw Scala próbowała pogryźć Javę, teraz Kotlin próbuje pogryźć Javę. Pojawiają się kolejne i widać, że sama platforma jest na tyle uniwersalna i daje nam na tyle solidną podstawę, że opłaca się budować nowy język na tym. Więc mamy znowu te młode, znaczy nie takie młode już, Scala to już chyba ma pełnoletność, próbujące podgryzać Javę. Więc mamy tych i to bardzo fajnie widać na konferencjach. Większość młodych ludzi wchodząc w świat JVM-a wchodzi w Kotlin, bo Java jest dla starych ludzi, powiedzmy sobie szczerze.

Jarosław Pałka Dobrze, to przed czterdziestką piszę.

Łukasz Kałużny: Wiesz co, Jarek, to ja w ogóle zadam, bo trochę wleciałeś już w następny wątek, więc ja automatycznie zadam to pytanie a propos przy tych problemach. Właśnie, jak Twoim zdaniem wygląda przyszłość JVM-a? I takie podpytanie, które rzuciłeś a propos wątek starych ludzi, to czy właśnie jako młody developer jest sens wchodzić w ogóle w języki oparte na JVM-ie? Tak, wrzucając trochę, dolewając benzyny tutaj do Twojego ogniska.

Jarosław Pałka Odpowiem, zachowam się teraz jak wysokiej klasy konsultant, to zależy. To zależy, bo tak naprawdę język jest… Ja oczywiście, jak pewnie czuć, jestem fanem JVM-a, ale mam już na tyle, gdzieś tam wyrosłem z tej fazy biegania z maczetą po Krakowie i likwidacji niewiernych, że patrzę na to czysto jako narzędzie. Do czego Ty chcesz tego użyć? I co Ty chcesz z tym zrobić, jeśli Ty chcesz pisać? No właśnie, to też jest taka skomplikowana sytuacja, bo teraz te rzeczy, które się pojawiły w Javie, na przykład Foreign Functions and Foreign Memory trochę zabrały rynku takim językom jak Go i Rust. Tego jeszcze nie widzimy, ale to ugryzło ten kawałek tortu, bo Java zaczyna sobie radzić z alokacją i pamięci poza stosem, stertą, bez garbage collectora. Można powiedzieć, że triumfalnie wskaźniki wróciły do JVM-a, ukryte, bo nie nazywają się pointerami, tylko memory segment, ale wszyscy wiedzą o co chodzi. Zależy to tak strasznie, bo na końcu robić, bo wydaje mi się tam, gdzie gdzie JVM, może teraz wykażę się niekompetencją, ale ewidentnie JVM po stronie frontendu nie wiem, czy przegrał bitwę, czy świadomie się wycofał, ale gdyby rzeczy frontowe, frontowe, frontendowe powstają w czym powstają. JavaScript rządzi. Jak swego czasu były takie projekty jak Stratz czy Apache Wicket, które gdzieś tam próbowały robić frontend, taki webowy w Javie, czy błąd ludzkości, za którym ludzkość odkopuje, czyli JavaServer Faces, JSF-y.

Łukasz Kałużny: Właśnie chciałem… Zastanawiałem się…

Szymon Warda: Zahaczyłem o to nawet.

Jarosław Pałka Mój kolega jest autorem stronki IhateJSF.com. Nie wiem czy ta stronka dalej istnieje, ale swego czasu…

Łukasz Kałużny: Zerkniemy. Nie, wiesz, pamiętaj, że ktoś w Microsofcie popełnił w tym samym czasie Web Formsy, więc…

Jarosław Pałka To była faza tak zwanego rządu architektów. Ja to nazywam fazą, końcówka lat 90, to była faza rządów architektów, ponieważ większość rzeczy powstawała w ten sposób, że najpierw powstawała specka. Zauważcie, co się zmieniło między… To zmiana pokoleniowa moim zdaniem też troszeczkę, że na początku było tak, że najpierw powstawała specka, a potem powstawały implementacje tej specki i wtedy się okazywało, że o specka do dupy. Wracamy do specki. A potem te rzeczy zaczęły powstawać… Wiesz, w jaki sposób powstał tak naprawdę cały ten ruch mikrousług? Po prostu ktoś najpierw to zaimplementował, patrz Netflix, i dopiero potem na bazie tego zaczęły powstawać wszystkie Spring Cloudy, Spring i tam mikroserwisy i tak dalej. Więc trochę się chyba nauczyliśmy, że pisanie specek to nie jest droga na tworzenie przewidywalnego, rozwijalnego softu.

Łukasz Kałużny: Nawet ciekawą rzeczą jest, z mojego poletka microsoftowego, tak jak David Fowler wrzuca przykłady na Twittera. Co uważacie za czytelniejsze w ogóle od strony języka? Że wrzuca przykłady z C Sharpa nowej składni i zaczyna z ludźmi dyskutować, co wygląda dla nich przyjemniej do użycia, że w ogóle idzie od próby prototypowania.

Jarosław Pałka Taka ergonomia nas, jako programistów. Tak, zgadzam się z Tobą.

Łukasz Kałużny: A z drugiej strony chyba eksperymentowo… Zauważ, tak jak powiedziałeś, te specki to też przypomina to, że ludzie, którzy tworzą jednak tę maszynę wirtualną, inne rzeczy eksperymentują i prościej jest im pracować na żywym organizmie, co z tego wyjdzie niż myśleć.

Jarosław Pałka Cały ten proces u nas inkubatorów, preview i tego, że nawet jesteśmy w stanie wycofać jakiś w miarę skończony nowy feature języka, bo jak gdyby feedback od użytkowników jest taki: panie, co wyście wymyślili? Więc trochę jest, użyjmy tego słowa, nawet tworzenie języków jest bardziej teraz takie Agile.

Szymon Warda: Powiedział Agile’owe.

Jarosław Pałka Ale wiesz, kto jest klientem? My jesteśmy w tym momencie klientami języków i maszyny wirtualnej, więc fajnie by było zacząć ten feedback zbierać od nas. To wynika też trochę z tego, że uwielbiam, polecam wszystkim na YouTubie Archiwum AT&T, nagrania z Carriganem, z Ritchiem i z całymi tymi ludźmi, którzy tworzyli C i Linuxa w tych flanelach, w tych brodach, nagrane jakąś marnej jakości kamerką. I dociera, jak obejrzycie sobie, bo to jest taki chyba z pół godziny film, w jaki sposób Unix powstawał, koncepcja, to dociera do Was, że wcześniej było tak, że ten człowiek, który zaprojektował sprzęt, był też człowiekiem, który projektował kompilator na ten sprzęt i był tym samym człowiekiem, który tworzył język na ten kompilator. I dlatego te języki w tej fazie przejściowej wyglądały w ten sposób, że nikt nikogo się nie pytał o zdanie, bo każdy jak gdyby miał w głowie pełny obraz. Potem chyba się ludzie zorientowali, że tak naprawdę ci ludzie, którzy tworzą te języki, to nie są ci sami, którzy w nich piszą. I ja widzę tu wielu… GO może nie jest takim przykładem, bo ja mam wrażenie, że on jest tak mocno troszeczkę tak zarządzany odgórnie.

Łukasz Kałużny: Znaczy inaczej, GO jest bardzo…

Jarosław Pałka Ten Rob, tak, Rob Pike?

Łukasz Kałużny: Wiesz co, inaczej, przypomnijmy sobie, że wyszło po to, żeby… GO powstał po to, żeby uczyć studenciaków pisać po googlowemu. U nich w środku to było w ogóle jako język treningowy, a potem się okazało, że da się zrobić z niego coś wydajnego.

Jarosław Pałka Ale wy wiecie, że na przykład Smalltalk powstał tylko i wyłącznie i w ogóle programowanie obiektowe powstało tylko i wyłącznie po to, genialny wywiad z Alanem Kay’em, żeby nauczyć dzieci komunikacji z komputerami. Programowanie obiektowe nigdy, nigdy, powtarzam jeszcze raz, nie miało wyjść poza fazę: pokażmy przedszkolakom, jak się pracuje z komputerami. To jest, tak…

Szymon Warda: Pierwszy raz to było tak, że to obiekt wysyłał sygnał innemu obiektowi, a nie było, że posiada obiekt. I to było bardzo, bardzo, bardzo ważne tak naprawdę, jak się to wszystko komunikuje. Te historie stare, o których właśnie mówisz, AT&T i tak dalej, tam bardzo fajne perełki można znaleźć i zobaczyć, jak [niesłyszalne 00:42:26].

Jarosław Pałka Tak, tak, w jaki sposób pewne decyzje zostały podjęte i niektóre decyzje ciągle jak gdyby konsekwencje tych decyzji są z nami, np. null. Sławna historia Million Dollar Mistake. Ale jak sobie posłuchacie, dlaczego tak się stało… Jest wywiad Jamesa Goslinga, to pokazuje jakim jestem psychofanem, jest wywiad Jamesa Goslinga z… Freeman? Fridman? Taki…

Łukasz Kałużny: Z Lexem?

Jarosław Pałka Z Lexem i tam pada, chyba w tym wywiadzie z Lexem, pytanie dlaczego wiedząc już wtedy, w połowie lat 90, że null to nie jest dobry pomysł jako byt w języku programowania, dlaczego Java wychodząc, próbując wyjść z tego… Wszyscy myślą, że Java powstała po to, żeby pozbyć się C++, a to nieprawda. Java powstała po to, żeby można było programować lodówki. Tylko się nie udało. Zamiast lodówek mamy serwery. Bo to był język na potrzeby embedded. To był język, który powstał na potrzeby embedded.

Szymon Warda: Jak Java była reklamowana, to właśnie była reklamowana na potrzeby embedded. Więc Jarek tutaj wcale nie żartuje. Tak było reklamowane właśnie.

Jarosław Pałka Poszukajcie sobie projektu Dynabook. I to jest pierwsze uruchomienie publiczne nagrane Javy na tablet, który był grubości kilku centymetrów i to jeden z pierwszych tabletów dotykowych. Ale wracając do Lexa i Jamesa Goslinga i James powiedział: słuchaj, zrobiliśmy null, bo myśmy też mieli deadline’y. Więc to fajnie oglądanie tych starych… Ja uwielbiam taką archeologię programistyczną, szczególnie w obszarze baz danych, języków programowania, kiedy do ciebie dociera, dlaczego na pewne rzeczy my teraz tak psioczymy i narzekamy i potem widzimy całą tą dziwaczną sekwencję od 50-któregoś roku…

Łukasz Kałużny: Która się ciągnęła.

Jarosław Pałka Ciągnęła błędów, czasami niedostatku sprzętowego. Pewne decyzje wynikały z tego, że sprzęt był jaki był, 8 bajtów i 640 kilobajtów. Więc to jest fantastyczne.

Łukasz Kałużny: Inaczej, to tak jak czemu mówimy patch albo bug? Akurat w poprzednim odcinku dorzucaliśmy screeny patchy i buga.

Jarosław Pałka Tak, tak, tak, tak, dla mnie to jest fantastyczne. Więc wracając do tematu czy pakować się w Javę? Wydaje mi się, że jeżeli nie masz zmysłu artystycznego i jedyne kolory, które rozróżniasz to jest czarny i biel i konsola jest Twoim miejscem życia, czyli ogólnie chcesz w backend, jesteś człowiekiem, który… Ja miałem kumpla, który po kształcie logów, które się szybko tailowały na screenie stwierdza czy jest błąd, bo to było takie debugowanie wizualne. Nie musiał czytać treści, widać było po wcięciach gdzie poleciał exception. Że jeżeli Ty chcesz naprawdę gdzieś robić rzeczy backendowe, to Java jest naturalnym wyborem. I wydaje mi się, że to jest dobre środowisko z wielu powodów. Po pierwsze masz wiele opcji. To może być Kotlin, to może być Scala, to może być Closer, jeśli ktoś już naprawdę chce odlecieć. I wiem, że np. sporo FinTechów używa np. Closer w Londynie z jakichś powodów. Tam mają kilka zabawek w Closer typu software transactional memory i kilka innych zabawek, które powodują, że to wszystko gdzieś tam jest… Jeszcze Atomic, który działa na Closer, który daje Ci praktycznie za darmo audyt logów, więc budowanie tych wszystkich fintechowych rzeczy, bledgerów i tak dalej w Closer wydaje się naturalne i masz to. Z drugiej strony jest wojna frameworków. Spring, który teraz zasiadł, strącił króla JTUI i JB, zasiadł na tronie, a z tyłu stoją wiesz, tam z nożami i próbują się go pozbyć przez wszelkiej maści mikronauty, quarkusy i tak dalej. Więc tu się absolutnie dużo dzieje. No i też ja nie wiem jakim cudem, absolutnie nie mam pojęcia, kto wpadł na genialny pomysł pisania baz danych [niesłyszalne 00:46:36].

Szymon Warda: No właśnie.

Łukasz Kałużny: Widzisz, idealnie Jarek, mamy do Ciebie następne pytanie. No właśnie, bo mamy sobie, teraz już padły języki w postaci Rusta, Golanga, które w tym momencie, powiedzmy przez ten cały cloud native stały się naturalnym wyborem high performance’owym.

Jarosław Pałka No dobra.

Łukasz Kałużny: Inaczej, w wielu projektach, które są w ostatnich latach, poszły jako z tej ścieżki high performance, jak pójdziemy w bebechy, to jest Rust, Golang, jeżeli to nie jest JVM, jeżeli popatrzymy. Jak dla Ciebie właśnie ten temat performance’owy teraz, high performance’owy wygląda z Twojej perspektywy? No i właśnie czy jest sens pisać bazy danych na JVM-ie?

Jarosław Pałka Wiesz co, to jest taka zabawa, że ludzie myślą Java, to tak mniej więcej tak jak masz w świecie JavaScriptu, że w sprawie JavaScriptu jak mówisz JavaScript, to połowa ludzi myśli React, druga połowa myśli Angular. I tak samo jest w Javie. Ktoś mi mówi, że piszemy w Javie. Aha, czyli masz Springa. A to kojarzy się jednak z dosyć dużym narzutem pamięciowo-procesorowym, to kosztuje i tak dalej. No ale nie wszędzie potrzebujesz takiej szalonej wydajności, powiedzmy sobie szczerze. Ten Spring jest, w związku z tym, że prędkość dostarczenia liczy się bardziej niż wydajność systemu, no to w tym momencie to wszystko się zgadza. Wydaje mi się, że z jakiegoś powodu, jak popatrzycie sobie na np. słynne Big Data lub Sparkling…

Łukasz Kałużny: Wiesz co, ja miałem dorzucić, ten, Kafka, Elastic.

Jarosław Pałka Elastic, Neo4J, czyli my, Hazelcast… Co my tam jeszcze potrzebujemy? Czekaj, to jest…

Szymon Warda: Okej, okej, ale z tym Big Data, to są systemy generalnie, które pracują z reguły na wielu, wielu, wielu maszynach i tam jest często ważniejsze skalowanie. Tak zarzucę takim trochę adwokatem diabła, że tam jest ważne, żebyśmy się fajnie skalowali, wymieniali po wielu instancjach i żebyśmy byli super wydajni. A bazy z reguły kojarzą się z tym, że mimo wszystko mamy tych instancji dość niewiele, nie komunikują się krzyżowo, że tak powiem i jednak na tym nam zależy. Swoją drogą dorzucę gratulacje, bo jak odpalałem Neo4J-a parę lat temu, importowałem tam chyba parę milionów obiektów, to było: eeeeeeeeeeeeeeeeeeeeeeeeee… Jak ostatnio odpaliłem, to łyknął to w 5 sekund. Tak że myślałem, że się po prostu wywalił, a okazało się, że wszystko zaimportował. Tak że…

Jarosław Pałka Tak, pracujemy. Wiesz…

Szymon Warda: Zauważyłem.

Jarosław Pałka Oprócz tego popijania kawki i robienia fiki, czyli tej szwedzkiej tradycji, to coś tam się u nas dzieje. Wiesz co, wydaje mi się, może się mylę, ale język to jedno, a ekosystem to drugie. I wydaje mi się, że te rzeczy odpaliły w tych konkretnych językach z powodu ekosystemu, z powodu dostępności bibliotek. Elastic, gdyby nie było Apache Lucene, gdyby Lucene nie powstał w Javie, z jakiegoś powodu, został napisany w Javie, no to myślę, że byłby z tym problem. Apache Kafka. Apache Kafka wykorzystała ten fakt, ktoś… Bo wydajność tych rzeczy typu bazy danych nie do końca leży w języku, tylko w zrozumieniu tego, jak działa komputer. Jeżeli, tak jak chłopaki w przypadku Apache Kafki stwierdzili dobrze, opiszemy to wszystko na zerocopy, czyli jak gdyby pakiet, który leci po sieci jest tym samym co jest zapisywany na dysk, bo to jest cała sztuczka, że my możemy wykorzystać mechanizm zerocopy, które mają systemy operacyjne i Java pod spodem implementuje zerocopy. Jak robimy sobie na FileChannel transfer, to Java sprawdza czy nasz system operacyjny wspiera zerocopy. Jak wspiera zerocopy, to jedziemy sobie po zerocopy. Więc jak gdyby to nie jest do końca to, czy ten język jest szybki, tylko ci ludzie, którzy to piszą, są świadomi tego, że jeżeli napiszą to w ten sposób w Javie, to Java w ten sposób zachowa się na Linuksie. I moim zdaniem kwestią ważniejszą jest zrozumienie systemu operacyjnego i to, w jaki sposób maszyna wirtualna korzysta albo robi abuse tego systemu operacyjnego, może być tak, że nie zachowuje się… Dobra, mam słaby polityczny żart i ja go nie rzucę, bo to w tych czasach to nie jest.. Żart, w nim biorą udział dwa państwa, nie mieszajmy. To wydaje mi się, że w tym momencie ten język przestaje być taki ważny z punktu widzenia wydajności, jeśli Ty zrozumiesz, co musisz zrobić. W naszym przypadku, w przypadku bazy danych, czym się zajmuje baza danych? Profesjonalnym przerzucaniem dużej ilości rzeczy w pamięci między dyskiem a pamięcią. To jest profesjonalna łopata do przerzucania rzeczy między dyskiem a pamięcią. W czym Java ma problem? Znaczy w sensie co jest źródłem latency w Javie? No garbage collector. No to jak się możemy go pozbyć? Przestańmy alokować na chipie. I w tym momencie, jak sobie popatrzycie na te wszystkie zabawki typu Elasticsearch czy Hazelcast czy Neo4J, my tak naprawdę praktycznie tego chipu nie używamy. Ja jako performance engineer w Neo praktycznie nie patrzę na GS logi. Nie dlatego, że jesteśmy tak super, że nie muszę na to patrzeć, ale dlatego, że my praktycznie nie alokujemy na chipie. Robimy alokację na off chipie i robią to wszystkie bazy danych napisane i wszystkie Big Data napisane w Javie. I teraz, dlaczego to działa? Bo z jednej strony Java Ci pozwala pogadać sobie coraz lepiej z systemem operacyjnym bezpośrednio. Z drugiej strony masz cały ten ekosystem bibliotek gotowych. My nie pisaliśmy własnego clusteringu, myśmy użyli apki, teraz piszemy własny clustering z powodu zmiany licencji apki, wiadomo co się stało. Ale wiesz, pisząc własną bazę danych, to nie musisz być mistrzem systemów rozproszonych. Bierzesz bibliotekę, która Ci to zrobiła. Ja mam wrażenie, że obecnie można zbudować sobie bazę danych samemu w domu z klocków, dlatego, że ten ekosystem, który jest, jest tak bogaty. I z drugiej strony masz wsparcie narzędzi, więc jak sobie popatrzysz na język jako całość, to wydajność przestaje być tak ważna przy pisaniu w momencie, kiedy Ty wiesz, co masz zrobić i zaczyna być ważniejsze łatwość dostarczania rzeczy i utrzymywalność tego kodu. Tak mi się wydaje, że to…

Łukasz Kałużny: [Niesłyszalne 00:53:39] perspektywa.

Szymon Warda: Czyli tak trochę parafrazując, zrozumienie jak co działa pod spodem i taka konkretna wiedza i jest coś, czego się nie da zastąpić kolejną technologią. Czyli wrzucając sobie kolejnego GO, Rusta, i tak dalej, dojdziemy do poziomu, gdzie i tak będziemy musieli te rzeczy rozumieć. A wartość. To samo jest też w .Necie, to samo jest też w Javie, że to nam daje taką elastyczność, że możemy się skupić na miejscach, gdzie faktyczne dane są potrzebne i tam przysiąść, a pozostałe rzeczy po prostu pisze się łatwiej, bo właśnie to, co mówisz, jest ten ekosystem, można wziąć gotowe pudełka i poeksperymentować.

Łukasz Kałużny: Czy wiesz co Jarek, jedną rzecz, którą wyciągnąłem z rozmowy i zalinkowałem, bo ja też sam osobiście często wracam do niej w dyskusjach, na szkoleniach, to jest mechanika od Sympatii.

Jarosław Pałka Tak, zauważcie, co się stało, że to jest tak, że w momencie kiedy powstawał Elastic, Neo4J, Kafka, bla bla bla bla, Java w ogóle nie była kojarzona z takimi,wiesz…

Łukasz Kałużny: Nie była.

Jarosław Pałka Low latency i high… High performance to jeszcze jest jakby inny poziom abstrakcji. Tam już ludzie po prostu wykuwają bajty w krzemie. Ale nie było możliwości alokacji poza stertą i była magiczna klasa w Javie, nazywała się unsafe, która miała w dokumentacji: never ever use in production code. Co ludzie zrobili? Wszyscy tego użyli. Ponieważ ta klasa miała magiczną metodę alocate, która woła malloca pod spodem. I teraz co się stało? W momencie, kiedy Oracle, i to była piękna drama, Oracle krzyknął: zabieramy unsafe’a! Nie wolno tego używać! To jest wytrych wewnętrzny na potrzeby JVM-a, to była wewnętrzna klasa JVM-a, tylko po to, żeby JVM mógł pewne rzeczy zrobić. No to zaczęło się: ale nasz produkt na tym stoi. Nie zabierajcie nam unsafe’a, bo nam zabieracie jedzenie. Nie będziemy mogli mieć ryżu dla dzieci, bo cały nasz system stoi na tej jednej metodzie, alocate. I w tym momencie chłopaki z Oracle’a stwierdzili: dobra, dobra, dobra, wszyscy z tego korzystają. Damy wam do tego stabilne API. Więc mamy teraz coś, co nazywa się projekt Panama, Memory Foreign Functions i Foreign Memory, gdzie oni dali nam API do tego. Nagle się okazało, że Java dostaje obiekt, który się nazywa Memory Segment, klasy, która się nazywa Memory Segment, która pozwala nam w miarę bezpiecznie w przeciwieństwie do unsafe’a zarządzać tą pamięcią. Jak gdyby oni dostrzegli, jeśli zauważyli, że bazy danych i Big Data powstają na Javie, że jest potrzeba jednak natywnego dostępu do tej pamięci. Więc tak jak powiedzieliście, to jest kwestia zrozumienia skąd się bierze prędkość i wydajność w tych systemach, że to jest zerocopy, że to jest alokacja na stosie, że to jest wektoryzacja operacji, jeśli Wasz procesor wspiera operacje [niesłyszalne 00:56:36].

Łukasz Kałużny: Znaczy wiesz co…

Jarosław Pałka I to daje Ci 90% szybkości.

Łukasz Kałużny: Jarek, najśmieszniejsze, że te same ruchy… Raczej unsafe w .Necie był stabilny od dawna, bo tam był hak na haku wokół tego. Ale jak popatrzymy to też, Szymon, Spany i te inne rzeczy, które parę lat temu weszły, całe zabawy, żeby tego unsafe’a trochę schować, a dać też klasy, które dadzą całość w sposób ciutkę bezpieczniejszy. Bo to czy bezpieczne, to nie nazywajmy tego.

Jarosław Pałka .Net i JVM mają tą samą obietnicę, czyli bezpieczny kod. Nie w sensie security takiego, że nikt się nie włamie, ale to, że Ty wiesz co wykonujesz, że Ty nie… Tam jest taka bardzo fajna książka “Introduction to JVMs” pewnego człowieka o chińsko brzmiącym nazwisku. Co ciekawe, człowiek pracował i w Microsofcie i w Sunie i napisał książkę o maszynach wirtualnych. I tam jest takie trzy przykazania, trzy albo cztery przykazania maszyn wirtualnych. I to jest to, że po pierwsze, nie dostaniesz adresu do nieistniejącego obiektu. To ci gwarantuje zarówno .Net jak i JVM. To, że nie wykonasz kodu, który przychodzi z zewnątrz. Więc to jak gdyby też Ci gwarantuje. No i nie wejdziesz w wieczną pętlę, jeśli ta pętla nie jest świadomie napisaną wieczną pętlą wykonania. I to daje ci manage runtime. To są błędy, z którymi walczyły pokolenia naszych dziadków. Wielu programistów zginęło walcząc, ścigając wskaźniki i tak dalej. I to nam daje JVM i to nam daje .Net, że my nie przestajemy o tym myśleć kosztem czegoś. I teraz jak dostajemy to bezpieczeństwo, w sensie, że program nam się w sposób… Kiedy ostatnio widzieliście coredumpa w Javie albo w .Necie? No ja widziałem ostatnio, bo my specjalnie wymuszamy, ale…

Łukasz Kałużny: Tak, ale to tak nie. To tak specjalnie, żeby Ci się złożyło od strony [niesłyszalne 00:58:32]…

Jarosław Pałka Podejrzewam, że jak zapytasz większość ludzi na konferencjach, którzy są młodzi, co to jest coredump? No to oni będą takie…

Łukasz Kałużny: Nie, ja bardziej szukałem, kiedy była w ogóle potrzeba czegoś takiego, żeby się to złożyło…

Jarosław Pałka Dokładnie. Więc jak gdyby my przez… Istnieje… I teraz widzisz, ja sobie tak myślałem, dlaczego w Javie powstał Neo4J czy baza danych w ogóle? Dlatego, że dla Ciebie ważniejsze jest bezpieczeństwo Twoich danych, w sensie nie utracisz tych danych, bo randomowo Ci się maszyna nie wywali. Więc wolisz czasami zapłacić mniejszą wydajnością, ale mieć gwarancję, że nagle w połowie zapisywania Twoich danych coś nie eksploduje i nie stracisz Twoich super ważnych danych. Więc to jest taki trade off, który zaczyna być coraz mniejszy moim zdaniem przez to, co się dzieje przynajmniej po stronie hotspota. Te wszystkie właśnie projekt Panama, Vector API, czyli dostęp do wektoryzacji, GPU, czyli Tornado VM, to jest maszyna wirtualna, która działa na GPU. Chyba ciągle jest w jakiejś tam fazie researchowo-eksperymentalnej, ale już można odpalić rzeczy na GPU z Javy. Więc ten gap, to było, musieliśmy poczekać wystarczająco długo, żeby ludzie znaleźli odpowiednią abstrakcję na te rzeczy. I w momencie, kiedy mamy odpowiednią abstrakcję, to dalej mamy to bezpieczeństwo i jednocześnie prędkość. Znaczy ja nie mówię, nie odrzucam sensu istnienia Rusta i GO, ale zauważcie np. dla mnie GO, z perspektywy mojej, macie krótką posadkę. Jak widzę GO, to zawsze jest to Kubernetes.

Szymon Warda: I okolice Googlowe.

Łukasz Kałużny: Okolice CNCF-u.

Jarosław Pałka Tak, tak, tak, to są okolice, tak, CNCF-u. Rust próbuje znaleźć swoją niszę. Ale wiesz, że ja ostatnio czytałem sporo narzekań na temat takich power pointers, że one są jednak trudne do zrozumienia.

Łukasz Kałużny: Raczej najtrudniejsze w życiu “hello world”. Takie bardziej, bardziej zaawansowane.

Jarosław Pałka Być może. Na pewno gdzieś tam znajdzie swoją niszę, ale ja swego czasu trochę śledziłem tą sytuację z Kernelem Linuxa i Rustem, czyli tam chłopaki próbowali coś wcisnąć. Nie wiem na czym się to skończyło. Ja jestem ciekawy czy ta społeczność na tyle urośnie ekosystemu, że będzie tam rzeczywiście łatwo wszystko…

Łukasz Kałużny: Czy wiesz co, ja mam, akurat na Rusta ja mam swoją perspektywę na dwa scenariusze, które gdzieś mogą być. Pierwszy to jest trochę następstwo C++ w tych rzeczach typowo core’owych, kernelowych, driver’ach. Nawet Microsoft mówi mocno, że tam się jednak daje jakąś tam poprawę bezpieczeństwa w tym kodzie, który jest jednak unmanage, jak popatrzymy sobie na C++. Druga moja perspektywa to jest taka, że łatwo w nim zbudować core Twojego SDK, który potem na różny sposób wstawisz do innych języków.

Jarosław Pałka Teraz popatrz, co się wokół tego dzieje. I moim zdaniem to tak będzie w tą stronę szło. I to jest taki model, który trochę Python też wziął. Dlaczego Python się przyjął do ML-owych rzeczy, odkładając na bok jak gdyby przyjazność tego języka dla ludzi, którzy mają życie osobiste?

Łukasz Kałużny: Pod spodem lata tyle rzeczy, właśnie shimów…

Jarosław Pałka Bo Python świetnie, prościutko, bardzo przyjemnie integrował z natywnymi bibliotekami. Więc ja, naprawdę wydaje mi się, że ten moment, kiedy Java, pojawi się projekt Panama i Ty jesteś w stanie w dwóch linijkach kodu bez magii zawołać wybraną funkcję w C z Javy nie będąc programistą C, bo wcześniej przy JNI, Java Native Interface, trzeba było być programistą C, żeby wywołać z Javy C. Nie dało się tego zrobić nie będąc programistą C. Teraz możesz. Więc tak jak mówisz, być może bardzo niskopoziomowe rzeczy będą w tym Rust’cie powstawać, a my będziemy dostawać z tego bardzo ładne zawijki w naszych manage językach.

Szymon Warda: Będzie większa segregacja. Kiedyś były dwa języki, które królowały, teraz tych języków będzie dużo więcej tak naprawdę i będą małe nisze. I chyba dobrze tak naprawdę.

Jarosław Pałka Wiesz co, ja się bardzo cieszę. Najgorsze co może być dla technologii to dominacja.

Szymon Warda: Tak, ale też próba upchnięcia jej do każdego przypadku użycia.

Jarosław Pałka Tak. Dla mnie np. to, że w Javie pojawiły się Scala i Kotlin, to był genialny kop w tyłek starego dziada. Bo język po wersji 8, on po prostu siadł. Dołożyliśmy tych streamów, dołożyliśmy i nic. Jakby był taki moment, gdzie mam wrażenie chyba skończyły się pomysły.

Szymon Warda: Że w ogóle mówiło się, że Java się skończyła, teraz wszyscy bedą kodowali w Scali. Scala była takim dużym uderzeniem.

Jarosław Pałka Był duży kop. Ja byłem, w tym momencie właśnie wchodziłem w Allegro i kiedy Scala zaczęła tam wszędzie mocno się rozpychać. I Kotlin i Scala dały kopa. Data classes Kotlina, no to Java mówi: dobra, my mamy rekordy. Sealed classy i pattern matching ze Scali? Dobra. Java mówi: dobra, my też mamy sealed classy. Więc wiesz, dla mnie ta różnorodność powoduje, że statek matka dostaje takie wiesz, otrzeźwienie regularnie. I to trochę też taki jest feedback, co społeczność potrzebuje, w sensie rozwoju języka. Więc ja bym się tam nie martwił i pisał te bazy danych w Javie dalej.

Szymon Warda: Dobra, to takie pytanie na pożegnanie. To z czym chciałbyś zostawić nasze osoby słuchające, z jaką myślą?

Jarosław Pałka O Jezus, z jakąś myślą… Wiecie co, wydaje mi się, że naprawdę warto. Ja wrócę do tekstu, który często, że tak powiem, przypominam na jakichś afterparty, libacjach. Uwielbiam to, co powiedział kiedyś Ted Neward, że żeby być programistą, dobrym programistą, trzeba zrozumieć warstwę abstrakcji niżej niż na której obecnie pracujesz.

Szymon Warda: Tak, bardzo prawdziwe.

Jarosław Pałka I to jest dla mnie… Stąd wzięła się moja absurdalna obsesja na punkcie JVM-a, ponieważ ja stwierdziłem: dobra, otworzę maskę, zaglądnę pod silnik. To jest tak jak na przykład ktoś pracuje z ORM-em.

Łukasz Kałużny: Powinien znać warstwę niżej.

Jarosław Pałka Warstwa, to jest tak, że ja np. nie schodzę na poziom Linuxa. Lubię sobie czasami otworzyć artykuł i mówić: o Chryste, dobra, szybko zamykamy. Bo to już jest, wiesz, to nie jest tak, że schodzisz na sam dół, bo tam nie ma tego dołu.

Łukasz Kałużny: Tam nie ma. Tam już jest zaraz… Inaczej i w pewnym momencie dotykasz krzemu.

Jarosław Pałka Dokładnie. I spod spodu słyszysz pukanie. Więc wydaje mi się, że to takie właśnie zdroworozsądkowe. Jeżeli ja używam Springa, to zrozum JVM-a, zrozum dynamiczne ładowanie klas, bo to jest jak gdyby esencją Springa. Jeśli używasz mocno ORM-ów, weź tą warstwę, zrozum SQL-a. Teraz, dobra, przyznaję się, czytam ostatnio sporo o Linuksie, ale dlatego, że przestaliśmy mieć problemy z JVM-em, zaczynamy mieć problemy z systemem operacyjnym. Więc gdzieś tam zaczynamy się kopać z koniem w pewnych momentach próbując zrozumieć pewne rzeczy na AWS-ie, dlaczego tak jest, a nie inaczej. Ale jeśli mam cokolwiek powiedzieć o warstwach, to nie kosztuje dużo. Nie trzeba ubierać skafandra i kamizelki kuloodpornej, warstwa abstrakcji niżej i od razu to powoduje, że Ty się stajesz lepszym programistą. Tak mi się wydaje.

Łukasz Kałużny: Chciałem powiedzieć, że pora odesłać DevOps’ów do kodu źródłowego Kubernetesa.

Jarosław Pałka Bardzo bym prosił. Bardzo bym prosił.

Łukasz Kałużny: Słyszycie? Ja się z Jarkiem tutaj zgadzam, chociaż tam to jest niestety nurkowanie jak w WordPressie.

Jarosław Pałka Tam mieszkają Orki, tak, tam mieszkają Orki. Tam się bramy Mordoru otwierają.

Szymon Warda: I ja bym jeszcze decydował kogo tam wpuszczamy generalnie, bo wnioski mogą być wyciągane nie takie jak sobie wyobrażam, tak swoją drogą. Zbyt duży optymizm tu widzę.

Łukasz Kałużny: Dobra.

Szymon Warda: I z tą myślą chyba się żegnamy.

Łukasz Kałużny: Dobra, to dzięki Jarku za świetną rozmowę.

Szymon Warda: Trzymajcie się.

Łukasz Kałużny: Hej.

Jarosław Pałka Hej.