JVM Wednesday vol. 91 – Kotlin 1.7, Netflix nie używa RX, Vector API w akcji

1. Kto tak naprawdę używa RX? Okazuje się, że nie Netflix

Dzisiaj zaczniemy do ploteczek z Twittera. Okazuje się, że czasem w ad hocowej rozmowie mogą wypłynąć ciekawe informacje, które potrafią postawić na głowie pewne powszechnie znane w branży fakty. Prawdopodobnie każdy, kto używał kiedykolwiek RxJavy, na jakimś etapie zetknął się z informacją, że biblioteka ta powstała na potrzeby Netflixa. To właśnie ona przetarła szlaki innym projektom związanym z reaktywnym programowaniem. Jej oryginalna wersja powstała jeszcze w czasach, gdy nikt nawet nie planował Reaktywnych Strumieni (dopiero wydanie 2.0 wprowadziło zgodność z tym standardem). Można więc powiedzieć, że to właśnie Netflixowi możemy podziękować za boom na reaktywność na backendzie. Dlatego więc dla wielu osób zaskoczeniem będzie, że Netflix… praktycznie wycofał się już z reaktywności.

A to wszystko dowiedzieliśmy się dzięki Twitterowi. Otóż w jednym z wątków narzekających na programowanie reaktywne, ktoś rzucił pytanie “ Czy jakakolwiek duża firma tego w ogóle używa”, otrzymując oczywiście odpowiedź, że czerwony system streamingowy. Tutaj szybko włączył się Paul Bakker z rzeczonej firmy, aby stwierdzić, że nic bardziej mylnego… 

Co ciekawe, nie był to wynik jakichś odgórnej decyzji. Po prostu przez lata kod Netflixowy coraz częściej, “oddolnie” refaktoryzowany był do blokującego API, ze względu na fakt, że coraz większe znaczenie ma dla firmy GraphQL i tworzący się pod spodem “graf” API, a reaktywność nie do końca w tym przypadku była w stanie pomóc, stopniowo się więc jej pozbywano. Jeśli jesteście ciekawi, jak Netflix używa dla odmiany GraphQL… zapraszam do lektury bardzo ciekawego posta na ten temat.

Oczywiście, absolutnie nie traktujcie tego wpisu jako “skoro Netflix przestał RXa używać, to czas wyrzucić go ostatecznie ze swojego stacku”. Bardziej tutaj planowałem zwrócić uwagę na to, jaka masa legend krąży po branży, często bazujących na mocno nieaktualnych już informacjach. Firmy ewoluują, zmieniają się im potrzeby i podejścia. Dlatego też jak kuszącym by nie było powoływanie się na autorytet uznanych firm przy podejmowaniu decyzji technologicznych, okazuje się, że tkwi w tym nawet więcej pułapek, niż na pierwszy rzut oka się wydaje.

Kontrowersyjna opinia: Z reaktywnym kodem jest jak z CAP Theorem, która powstał by uwidocznić pewien konkretnego problem, ale była na tyle nośna, że nagle wszyscy stwierdzili, że wszystkie bazy muszą być klasyfikowane jako AP i CP, jakby to były jedyne wyróżniki. Tak jak wszystkie aplikacje nagle zaczęły dziwić się, że wprowadzenie “reaktywności” nie rozwiązało nagle problemów ze skalowalnością.

Źródła

• https://twitter.com/rafaelcodes/status/1523327905434062848?s=21&t=V5qMCfzlM7ONRoTPPZJM7A&utm_source=pocket_mylist
• https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Kotlin 1.7 wydany

Sezon nowości kotlinowych powoli się rozpędza. Dopiero co informowaliśmy o Roadmapię, a tu już wyszła kolejna “duża” edycja Kotlina! Przyjrzyjmy się zatem, co ciekawego przynosi nowa edycja języka.

Najważniejszą nowością wydaje się z pewnością wersja Alfa kompilatora K2. Jak mieliśmy okazję wspominać przy okazji wydania Roadmapowego, to właśnie K2 jest przyszłością Kotlina i to właśnie na niej bardzo mocno opierają się plany twórców, aby w niedalekiej przyszłości być w stanie w realny sposób stworzyć z Kotlina rozwiązanie prawdziwie multiplatformowe, bez potrzeby wielokrotnej implementacji tych samych funkcjonalności. Wersja Alfa na razie wspiera wyłącznie JVM i jest jeszcze dość mocno ograniczona, ale pierwsza testowa edycja to bardzo ważny krok dla całego projektu. Więcej o kompilatorze K2 możecie dowiedzieć się z prezentacji twórców.

Z ważnych nowości z pewnością wymienić trzeba też inkrementalną kompilacje za pomocą Gradle. Twórcy chwalą się, że ich wewnętrzne testy wykazały poprawę o ponad 80% dla zmian po trafieniu do cache. Kotlin od lat ma opinie dosyć przyciężkawego, dlatego każdy ruch w stronę poprawy Developer Experience (a takimi są w końcu wszelkie poprawki procesu kompilacji) są bardzo na miejscu. 

Jeżeli chodzi zaś o rzeczy związane z syntaxem języka, to zdecydowanie to wydanie stoi pod znakiem dalszego pokrycia sytuacji brzegowych, z którymi radzić sobie musi system typów Kotlina (pod tym względem bardzo mi to przypomina ostatnie release notes TypeScripta). Nowe wydanie przynosi bowiem min. typy ostatecznie nie-nullowalne oraz wnioskowanie typów w ramach tzw. Builderów. Wprowadzono też operator underscore, pozwalający na automatyczne wnioskowania o typie generycznym, gdy znane są pozostałe argumenty. 

Parę drobiazgów przynosi też biblioteka standardowa, bowiem ponownie wprowadza oryginalne nazwy funkcji, ale z nie-nullowalną zwracaną wartością. Dodano więcej możliwości jeśli chodzi o Regexpy, a nowe funkcje min(), max(), minBy(), maxBy(), minWith() i maxWith() zwracają teraz bezwzględnie element kolekcji lub rzucają wyjątek.

fun main() {
    val numbers = listOf<Int>()
    println(numbers.maxOrNull()) // "null"
    println(numbers.max()) // "Exception in... Collection is empty."
}

Z ciekawych rzeczy – Optionale doczekały się funkcji rozszerzeń, co ma zapewnić większą kompatybilność z javowym kodem i bibliotekami.

val presentOptional = Optional.of("I'm here!")

println(presentOptional.getOrNull())
// "I'm here!"

val absentOptional = Optional.empty<String>()

println(absentOptional.getOrNull())
// null
println(absentOptional.getOrDefault("Nobody here!"))
// "Nobody here!"
println(absentOptional.getOrElse {
    println("Optional was absent!")
    "Default value!"
})
// "Optional was absent!"
// "Default value!"

Oczywiście, to tylko część tego co znajdziecie w nowym wydaniu Kotlina, pełne jest one drobnicy a nie zahaczyłem tak naprawdę o zmiany, które pojawiły się np. w kontekście KotlinJS. 

A jak już w temacie Kotlina jesteśmy – ukazały się wyniki dotyczącej użycia Kotlin Multiplatform przez społeczność. Wyniki zostały okraszone eleganckimi infografikami, prezentującymi stan ekosystemu. Nie będę się rozpisywał, bo w zasadzie zacząłbym przepisywać to, co znajduje się w podsumowaniu ze strony JetBrains.

Jeśli chcecie uzyskać dostęp do pełnego raportu – niestety musicie zostawić jego twórcom swój e-mail.

Źródła

• Kotlin 1.7.0 Released
• The State of Kotlin Multiplatform Survey Q3-Q4 2021
• Get Kotlin Multiplatform Survey Results Directly In Your Inbox

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

3. Vector API na przykładzie alternatywy dla Arrays.sort

A na koniec mam coś bardzo niskopoziomowego i technicznego. Dopiero co mieliśmy okazję podrzucić Wam tekst Jamesa Baker dotyczący użycia precyzyjnych narzędzi kontroli współbieżności projektu Loom jako alternatywy dla Jepsena. Widać, że niezwykła popularność pierwszego tekstu dodała Jamesowi wiatru w skrzydła, gdyż w krótkim okresie udało mu się spłodzić kolejny, który również szybko “wytrendował”. Tym razem wziął na warsztat Project Panamę i przychodzące wraz z nim Vector API.

Nowa publikacja dotyczy problemu tak wydawałoby dawno już “wyżyłowanego”, czyli sortowania. James postanowił sprawdzić, ile tak naprawdę będziemy w stanie zyskać, omijając javową abstrakcję i dobijając się bezpośrednio do samego procesora. Te wspierają bowiem tak zwane operacje SIMD (ang. Single Instruction Multiple Data), pozwalające na przetwarzanie wielu strumieni danych równocześnie za pomocą pojedynczej instrukcji. Pozwala na znaczące skrócenie czasu wykonywania obliczeń. SIMD są z nami od lat, ale na drodze do ich popularyzacji stanął fakt, że trudno jest napisać poprawnie kod z ich użyciem, a co najważniejsze, kompilator w wielu przypadkach może to zrobić za nas. Te mechanizmy nie są jednak idealne, więc w celu osiągnięcia maksymalnej wydajności, niezbędna będzie ingerencja programistów. Vector API, czyli część Projektu Panama, umożliwia właśnie wykonywanie tego typu operacji w sposób maksymalnie bezpieczny i uniknięcia potencjalnych błędów segmentacji, tak popularnych przy bezpośrednim adresowaniu pamięci jak to ma miejsce w przypadku operacji SIMD.

Jako benchmark użyto zaś Arrays.sort. Sam kod jest na tyle skomplikowany i przechodził na tyle iteracji, że nie będę go tutaj przeklejał i pozwolę sobie odesłać zainteresowanych do oryginalnego postu. Nas ciekawić tutaj będą jednak wnioski autora. Zaczniemy od tych pozytywnych… jest szybko, naprawdę szybko – zaproponowana przez autora implementacja osiągnęła w benchmarkach wydajność blisko trzykrotnie lepszą niż rozwiązanie dostarczane z JDK. Obarczone jest to jednak pewnymi problemami. Przykładowo, autor nie ukrywa, że pisanie przy pomocy Vector API to proces regularnego strzelania we własną stopę i długotrwałego debugowania (które samo w sobie też jest bardzo trudne, ze względu na fakt, że działamy bezpośrednio z natywną pamięcią). Samo zmierzenie uzyskanej wydajności w realistyczny sposób też wymagało od Jamesa nieco kreatywności. Samo API, ze względu na to, że jest rozwiązaniem “bezpiecznym” dla programistów, też nie pozwala na uzyskanie pełnej mocy procesora – rozwiązania w C++ w dalszym ciągu są wielokrotnie bardziej wydajne. Wydaje się jednak, że dla wielu programistów, Java ze wsparcie SIMD może okazać się bardzo ciekawą alternatywą dla języków bliższych maszynie 

Polecam lekturę całości – nie jest ona najlżejsza, ale autor robi wszystko, aby bezboleśnie przeprowadzić czytelnika przez meandry kodowania przy pomocy nowej zdobyczy pochodzącej z Projektu Panama.

Źródła:

• SIMD accelerated sorting in Java – how it works and why it was 3x faster

Bonus: Doczekaliśmy się zamrożonej listy funkcjonalności JDK 19. 

Prezentuje się następująco: 

• 405: Record Patterns (Preview) 
• 422: Linux/RISC-V Port
• 424: Foreign Function & Memory API (Preview)
• 425: Virtual Threads (Preview)
• 426: Vector API (Fourth Incubator)
• 427: Pattern Matching for switch (Third Preview)
• 428: Structured Concurrency (Incubator)

Jak można zauważyć, raczej doczekamy się w niej wyłącznie jednego stabilnego ficzera (konwersji Javy na Linuxy pracujące na procesorach RISC-V), ale jeszcze raz podkreślam coś, o czym wspominałem już od dłuższego czasu – będzie to najciekawsze nowe wydanie Javy od lat.