JVM Tuesday vol. 90 – Microstream, State of Clojure i Roadmapa Kotlina

1. Czym jest MicroStream?

W zeszłym tygodniu kończyliśmy naszą edycję na Micronaucie, a w tym mamy do tego pewien followup. O ile przekazaliśmy Wam informację, że w nowej wersji frameworka pojawi się wsparcie dla MicroStream w formie micronautowego modułu, to nie zdążyliśmy już z ogłoszeniem, że MicroStream ogłosiło dołączenie do Micronaut Foundation. Narzędzie stało się srebrnym sponsorem frameworku i pojawiła się zapowiedź dalszego zacieśniania współpracy. Dlatego też wróćmy jeszcze jeszcze raz do tematu, i w nieco dłuższej formie porozmawiajmy o tym, czym MicroStream jest i na jakie problemy odpowiada.

I na to pytanie trochę też, aczkolwiek z małym twistem 😉

Kojarzycie taki termin jak niedopasowanie impedancji obiektowo-relacyjnej? Inaczej Object-relational impedance mismatch – kocham bezpośrednie polskie tłumaczenia? Za tym cudownym terminem stoi problem stary jak frameworki ORM – co należy rozwinąć jako Object-Relational Mapping. To zaś można przetłumaczyć na mapowanie obiektowo-relacyjne (trochę lepiej). Wynika on z tego, że model obiektowy i relacyjny są ze sobą mocno niekompatybilne, i to jeszcze na poziomie samych koncepcji.

Za Wikipedią, w wolnym tłumaczeniu:

Obiekty odnoszą się do siebie nawzajem, tworząc coś co w sensie matematycznym określa się jako graf skierowany (sieć zawierającą pętle i cykle). Schematy relacyjne są z kolei tabelaryczne i oparte na algebrze relacyjnej, która definiuje powiązane ze sobą heterogeniczne krotki (grupy pól danych w „wierszu” o różnych typach dla każdego pola), gdzie powiązania są zawsze odwracalne (klucze obce można śledzić wstecz, ponieważ INNER JOIN jest symetryczny), co jest cechą bardziej zbliżoną do grafów nieskierowanych.

ORMy zawsze musiały sobie z tym niedopasowaniem radzić, w lepszy lub gorszy sposób, modelując dane w sposób bardzo koślawy. Często do tego stopnia że wymuszały specyficzny sposób pisania kodu, taki by frameworkowi się podobało, lub też tworzenie warstw pośrednich, co skończyło się modą na używanie frameworków jak najbliższych SQL-owi jako takiemu.

MicroStream podchodzi do problemu inaczej. Zamiast używać modelu relacyjnego, serializuje obiekty do tak zwanego ObjectGraphu. Dzięki temu nie są wymagane żadne nadmiarowe konwersje, procesor się nie zużywa i w ogóle ratujemy planetę.

Ale serio serio, jako argument za spróbowaniem używają “Save lots of CPU power, CO2 emission, and costs in the data center.” 😉

Chwalą się też, że ichniejszy DataGraph może być persystowany zarówno in-memory, w zewnętrznym cache, jak i każdej bazie danych przyjmującej binarne dane. Używanie indeksów przy pobieranie danych zastąpiono zaś tworzeniem inteligentnych podgrafów, pozwalających na efektywne dotarcie do konkretnego podzbioru całego zrzutu pamięci. Całość ma być mała i bardzo “natywna” dla Javy, dobrze integrować się z natywnymi API Javy, jak choćby Stream API i pozwalając na łatwą serializacje również obiektów, nad którymi nie mamy kontroli.

A skąd budżet na sponsoring Micronauta? W wersji Community twórcy MicroStreama umożliwiają tylko i wyłącznie PostgreSQL, MongoDB, SQLite i systmeu plików. Bardziej zaawansowane rozwiązania, jak choćby np. S3 czy inne blob storage, dostępne są w wydaniu komercyjnym. Niestety, nigdzie nie udało mi się znaleźć grona płacących klientów rozwiązania.

Jeśli jeszcze jest Wam mało w temacie MicroStream, to foojay.io właśnie rozpoczęło serię na temat tego narzędzia. Jej pierwszą część znajdziecie tutaj, wraz z dużo szerszym wprowadzeniem w temat, wraz z szerokimi potencjalnymi przypadkami użycia. Akurat w ostatnich tygodniach ciągle trafiam na MicroStream, i choć ciężko mi powiedzieć na ile to jest oddolne działanie społeczności, a na ile akcja marketingowa… no cóż, zadziałało. Może właśnie stwierdzili, że czas się zacząć mocnie monetyzować.

A czy ktoś z Was używał MicroStreama? Dajcie znać 😉

Źródła

2. The State of Clojure 2022

Dawno nie było u nas Clojure, co? To dobrze się składa, że akurat pojawia się okazja, żeby trochę nadrobić to, co wydarzyło się w ekosystemie tego króla współczesnych języków lispopodobnych.

Zacznijmy od tego – czy Clojure jest używany w realnych projektach? Jak najbardziej, mamy do czynienia z coraz większym odestkiem osób, które używają Clojure komercyjnie. Co ciekawe, wiąże się to ze stratami we wszystkich innych grupach. Ciekawe, czy oznacza to pewnego rodzaju chów wsobny i po prostu pewne przemieszanie w ramach dość stałej grupy? Akurat brakuje mi w ankiecie danych na temat wzrostu całego ekosystemu.

Lećmy dalej. Skąd ludzie biorą się w ekosystemie Clojurowym? Java to dość naturalny kierunek tranzycji, JavaScript również (ClojureScript to jeden z motorów napędowych całego projektu), ale… Python? muszę przyznać, że jest to dla mnie dość zaskakujący kierunek tranzycji. Byłoby śmiesznie, jakby był to efekt jakiejś pojedynczej dużej tranzycji z Pythona do Clojure 😉 Ale efekt jest dość stały, więc może jakiś czytający to clojurowiec mnie oświeci?

Nie wszystkie wykresy można znaleźć w oryginalnym poście, o dostęp do niektórych dane trzeba się trochę natrudzić. Byłem bardzo ciekawy, jak rozkłada się użycie w poszczególnych częściach branży, ale nie znalazłem tego w poście towarzyszącym wynikom, w związku z czym zaglądnąłem do “czystych” danych. Okazuje się, że najczęstszym miejscem użycia Clojure jest… Web Development i projekty Open Source, a dopiero na trzecim są projekty komercyjne (ciekawe, jak mają się one do Web Developmentu). Podejrzewam, że duża w tym zasługa ClojureScripta.

Podobnie, po dane o użyciu w konkretnych domenach też trzeba się schylić. Tutaj jednak nie ma zaskoczenia – Clojure zawsze kojarzył się z FinTechami, i dość dobrze oddaje to powyższa tabelka.

Na koniec zostawiłem sobie mój ulubiony wykres, ten który dotyczy zaangażowania w społeczność języka. Ciekawe, na ile grupa wypełniająca ankietę to ludzie z pewną inklinacją do “udzielania się” (albo aktywna deklaratywnie), ale zaskakuje, że prawie ćwierć z nich zajmuje się rozwojem narzędzi open-source, a prawie połowa zajmuje się ewangelizacją własnej organizacji. Z mojego doświadczenia – Ci od Clojure tak mają. Uwierzcie mi, coś o tym wiem na własnym przykładzie.

Trochę jak prawnicy. Po czym poznasz programistę Clojure? Bo Ci o tym powie.

I to w czymś co przypomina “starszą mowę”.

Dane z ankiety pewnie nie należy traktować jako ostatecznego źródła prawdy na temat ekosystemu, ale w dalszym ciągu stanowią okno w społeczność Clojure. Pełne rezultaty możecie znaleźć tutaj, w tym odpowiedź na pytania otwarte i więcej szczegółów. Jakby ktoś się zastanawiał – w ankiecie udział wzięło 2352 osoby.

Źródła:

3. Aktualizacja Roadmapy Kotlina!

Po okresie posuchy, jeśli chodzi o nowe informacje na temat Kotlina, sytuacja powoli zaczyna się rozkręcać – nareszcie doczekaliśmy się bowiem nowej wersji Roadmapę języka. W ramach niej, ludzie z JetBrains postanowili zawrzeć wszelkie swoje plany na drugą połowę 2022, ale również uchylić rąbka tajemnicy na to co przyniesie początek 2023.

Nie da się ukryć, że twórcy Kotlina mocno wzięli sobie do serca uwagi użytkowników, narzekających na suboptymalny developer experience języka, przejawiający się min. długim czasem kompilacji. Dlatego też kluczową zmianą, na którą szczególny nacisk kładą twórcy języka jest nowy kompilator.

K2, bo tak się nazywa, ma postawione dwa cele. Po pierwsze, ma on sam w sobie być znacznie szybszy od istniejących rozwiązań. Jednocześnie, jego wdrożenie pozwoli twórcom na łatwiejszą innowację, poprzez pozbycie się długu technicznego. K2 różni się bowiem od dotychczasowych rozwiązań tym, że ma stanowić wspólną abstrakcję dla całego Kotlina Multiplatform, a to wszystko dzięki nowemu formatowi pośredniemu. W tej chwili wariant JVMowy przeciera szlaki, ale już w tej chwili mówi się o wersja dla Kotlin JS, Kotlin Native i dla wydań mobilnych. W Roadmapie znaleźć można tematy też stabilizacje API pozwalającego na pisanie pluginów, a także oficjalny release wersji beta… niestety na razie nie podano żadnych dat. Pełne wdrożenie K2 zajmie jeszcze trochę czasu, dlatego też w planach twórców Kotlina pojawiły się nowości związane z istniejącym kompilatorem, jak na przykład usprawnienie kotlinowych skryptów.

Im więcej o nim czytam, tym bardziej tak sobie wyobrażam rozwój K2.

Jak już wspomnieliśmy o wersji Multiplatform, to ta już niedługo również doczeka się paru usprawnień, szczególnie w kontekście kodu Androidowego. Multiplatform ma się w końcu pojawić w wersji Beta, a takowej poświęcono ostatnio całą osobną, szczegółową notatkę, opisującą jak proces “promocji” będzie wyglądał.

Możemy zauważyć także dalszą inwestycje w narzędziówkę. Stabilizacja analizy kodu oraz unikania nadmiarowych kompilacji (co jest rozwiązaniem na dobrą sprawę potencjalnie jeszcze skuteczniejszym niż nawet najszybszy nowy kompilator) mają stanowić uzupełnienie działań związanych z K2.

Jeżeli chodzi o Kotlina w wersji JVM i JS, na roadmapie nie pojawiły się żadne nowe pozycje z nim związane. Ogólnie widać, że stabilizacja (w przypadku JS) i standaryzacja (w wypadku JVM) nowego formatu pośredniego (internal representation – IR) dla obu języków pochłania masę sił i trochę się przeciąga. W dalszym ciągu czekamy więc np. na wsparcie kapt (Kotlin Annotation Processor) w nowym JVMowym IR, a także na lepsze czasy kompilacji przy jego użyciu.

Podsumowując aktualizację Roadmapy – widać, że czasy dużych zmian w języku mamy już za sobą. Tylko i wyłącznie jedna nowa (bardzo kosmetyczna zmiana) w jego syntaxie – specjalna składnia dla operatora until – pokazuje, że Kotlin jako język jest już w zasadzie feature complete. Teraz nacisk kładziony jest głównie po pierwsze na wsparcie nowych platform, ale również dbanie o jak największy komfort pracy z całym ekosystemem – zarówno przez programistów zewnętrznych, jak i samych twórców języka. Jest to nie najgorsza decyzja – to w końcu właśnie świetną integracją z narzędziami i wygodą użycia Kotlin zdobył przecież serca użytkowników.

A jak już jesteśmy przy Kotlinie, to również początkiem tygodnia pojawiła się nowa wersja biblioteki KotlinDL o numerze 0.4, która wprowadza szereg nowości, z czego tą najbardziej zwracającą uwagę (i przez to używaną też w reklamie tej edycji) jest Pose Detector.

Aż mi się łezka w oku zakręciła, bo moją pracą inżynierską była właśnie forma detekcji pozy przy użyciu Kinecta.

Oprócz niego nowy KotlinDL przynosi wsparcie dwóch nowych modeli: EfficientDet oraz EfficientNet, oraz nowe warstwy wychodzące poza to, co przynosi standardowa biblioteka TensorFlow. Jeśli chcecie więcej informacji, także o pozostałych nowościach w tej wersji, oficjalne Release Notes są naprawdę dobrze napisane, więc zachęcam do lektury.

Źródła

PS: Edycja powstała przy NINA – Sleepwalking (Full Album).

1. Czym jest MicroStream?

Źródła

2. The State of Clojure 2022

Źródła:

3. Aktualizacja Roadmapy Kotlina!

Źródła

Odkryj więcej świetnych treści!