TLDW: Wrażenia z Keynote KotlinConf 2023 - JVM Weekly vol. 131

Podczas godziny (bo tyle trwała całość), dowiedzieliśmy się jak będzie wyglądały kolejne kroki twórców Kotlina, a także padło parę interesujących deklaracji.

Oglądnięte? Jeśli nie to zapraszam do mojego tekstowego podsumowania imprezy.

Kotlin 2.0 i Kotlin K2

Cała konferencja rozpoczęła się od dużej zapowiedzi – nadchodzi Kotlin 2.0. Nie jest to wielka nowość – fakt tego, że wydanie 1.9 będzie ostatnim z linii 1.x. Wersja 1.10 się nie pokaże, zamiast niej przeskoczymy od razu do wydania 2.0. Wynikać ma to z faktu, że to właśnie na tą wersje planowane jest wydanie długo oczekiwanego kompilatora K2 – „jednego, by wszystkimi rządzić”.

K2 to tak zwany frontend kompilatora. Proces kompilacji zwykle dzieli się bowiem właśnie na dwa główne komponenty: frontend i backend. Każdy z tych komponentów pełni odrębną rolę w trakcie kompilacji.

Frontend kompilatora jest głównie odpowiedzialny za przetwarzanie składni i semantyki kodu źródłowego. Wykonuje on szereg zadań, takich jak analiza leksykalna, składniowa i semantyczna . Podczas tych kroków frontend sprawdza błędy składniowe, generuje drzewo AST reprezentujące strukturę programu oraz sprawdza, czy program przestrzega reguł i ograniczeń języka. Frontend przeprowadza również kontrolę typów, aby upewnić się, że zmienne, wyrażenia i wywołania funkcji są używane zgodnie z ich odpowiednimi typami. Po zakończeniu tych zadań frontend generuje pośrednią reprezentację (IR) kodu źródłowego, która służy jako dane wejściowe dla backendu kompilatora. Z kolei backend kompilatora skupia się na optymalizacji i generowaniu finalnego kodu maszynowego lub bajtkodu dla docelowej platformy.

Z powyższego opisu łatwo zauważyć, że to, z czym większość z nas ma do czynienia na codzień (i to niezależnie czy jako użytkownik końcowy czy nawet twórca narzędzi) to frontend kompilatora. I jak się okazuje, to właśnie ta część miała największy potencjał na optymalizacji. Wystarczy zresztą spojrzeć na liczby, którymi ze sceny chwalił się Roman Elizarov:

Jednak nie o samą wydajność rozwiązania tutaj chodzi. K2 ma zapewnić wspólną infrastrukturę dla wszystkich potencjalnych targetów języka. Dzięki temu jego twórcy nie będą musieli każdorazowo implementować tych samych funkcjonalności na potrzeby JVM, WebAssembly czy Androida, co ma znacznie przyspieszyć ewolucje Kotlina.

Zmiana „dużej” wersji języka potrafiła mocno zamieszać w ekosystemie danego języka, jednak w wypadku Kotlina JetBrains obiecuje bardzo stabilny proces migracji. Po pierwsze, zmiany motywujące podbicie numeracji odbywają się pod maską, a twórcy celowo nie planują wprowadzać w nowym wydaniu żadnych nowych nowości w samym syntaksie języka – te zostawiają sobie na wydania 2.x, które przyjdą po udanym przejściu na K2 (o czym już za chwilę). Dodatkowo jednak JetBrains zyskuje na tym, że kontroluje zarówno Kotlina, jak i jest głównym dostawcą narzędzi do niego. Pozwala to bowiem na znacznie sprawniejsze przeprowadzenie całej operacji, gdy większość najważniejszego toolingu może być rozwijana równolegle z językiem.

Jeżeli ktoś nie może się doczekać nowego „majora” języka, to w zeszłym tygodniu ukazał się Kotlin 1.8.20, który wprowadza flagę -language-version 2.0. Ta umożliwia przetestowanie najnowszych zmian w kompilatorze, a sam Roman Elizarov prosił o to, żeby takowe testować – ma to pozwolić twórcom na solidne sprawdzenie całości.

A jak już zapowiedziałem, że będzie też o nowych wersjach języka…

Nowe funkcjonalności języka

Roman Elizarov ze sceny pokazał nam, czego możemy spodziewać się od kolejnych wydań Kotlina.

Static Extensions

Otóż proszę państwa, Kotlin otrzyma wsparcie dla funkcji statycznych… tak jakby.

Otóż możliwe stanie się dokładanie statycznych funkcji

fun File.static.open(name: String)

Co prawda w języku istniała już możliwość dokładania „efektywnie statycznych” extension funkcji , ale tylko wtedy, kiedy klasa posiadała Companion Object. Teraz będzie możliwe to również w przypadku, gdy nie mamy kontroli nad klasą bazową

Collections Literals

To się naprawdę dzieje!

Tutaj pozwolę sobie memem:

Myślę, że to właśnie na to ogłoszenie czekało Google, zanim obwieściło światu, że Kotlin DSL stanie się dom… bez spoilerów, będzie za chwilę.

Object (name-based) destructuring

Będzie zagadka. Poniższy kod

data class Home(val country: String, val city: String, )

val (city, country) = Home("Kraków", "Poland")

doprowadzi do trudnego do wychwycenia błędu (widzicie gdzie?).

Twórcy zapowiedzieli też, że pracują nad wprowadzeniem formy destrukturyzacji obiektów, która ma uniemożliwić tego typu pomyłki. Aktualne nie ma jeszcze gotowej propozycji syntaxu… to znaczy jest ich aż kilka, ale ukrytych w kotlinowym YouTracku. Zobaczymy, która ostatecznie wygra.

Explicit Fields

Dosyć hermetyczną zmianą jest też dodanie tak zwanych „explicit fields”. Jest to (przynajmniej z mojej perspektywy) syntax sugar nad mechanizmem określanym jako „backing” pól, a użyteczny w momencie gdy chcemy zwrócić jakąś wartość jako niemutowaną, ale być w stanie wykonywać na niej w momencie tworzenia jakieś operacje.

Całość jest skomplikowana (doczekała się własnego Design Doca), ale w praktyce sprowadza się do zmiany poniższego kodu

class C {
    private val _elementList = mutableListOf<Element>()

    val elementList: List<Element>
        get() = _elementList
        
      fun addElement(element: Element) {
      _elementList += element // works
    }
}

C().elementList += element // does not compile;

class C {
   val elementList: List<Element>
        field = mutableListOf()

  fun addElement(element: Element) {
      elementList += element // works
  }
}

// outside code
C().elementList += element // does not compile;

Zapowiedziano również redesign oraz stabilizację ContextReceivers, które swego czasu już trafiły do języka. Dzięki nowej architekturze K2, ułatwione zostanie też pisanie rozszerzeń do kompilatora, umożliwiających np. generowanie kodu.

Kotlin Notebooks

Mocno ewoluuje nam sposób, w jaki tworzymy kod. Z jednej strony w naprawdę szybkim tempie GPT-4 staje się bardzo dobrym partnerem do wspólnego kodowania, z drugiej techniki wcześniej używane głównie przez Data Scientistów powoli przenikają do reszty branży. Przyznam, że osobiście bardzo cenie sobie wszelakie notebooki (choć muszę przyznać, że bardzo łatwo o ich nadużycie). Do tej pory jednak głównie byłem konsumentem tych stworzonych przez kogoś innego, niż twórcom. Sytuacja ta może się niedługo zmienić, ponieważ JetBrains postanowiło stworzyć plugin do IDE. I wygląda to naprawdę przejemnie

Jako że obraz wart jest tysiąca słów, zrobiłem klip z fragmentu konferencji, w ramach którego pojawiło się to małe cudeńko.

Jeśli nie wiecie czy warto oglądać – na końcu OpenAI generuje kod, bo co to byłby w 2023 za Keynote bez GPT.

Do skryptowania wydaje się być to wręcz idealne. Pamiętam, jak bardzo ceniłem sobie zawsze Scala Worksheet.

To teraz przejdźmy, do chyba największego zaskoczenia…

Kotlin DSL domyślnym językiem

Ja naprawdę zawsze próbowałem polubić Kotlin DSL. Ma on obiektywnie masę zalet takich jak ulepszona obsługa IDE i lepsze bezpieczeństwo w czasie kompilacji. Mimo jednak bycia „typesafe”, bardziej ekspresywną alternatywę dla Groovy’ego, jego adopcja jest dość powolna. Jednym z podstawowych wyzwań, przed którymi staje podczas pracy z tym dialektem jest fakt, że znaczna liczba sampli, tutoriali i dokumentacji jest nadal w Groovym, a nie Kotlinie. Dzieje się tak głównie dlatego, że to właśnie Groovy został oryginalnie wybrany przez Gradle, co doprowadziło do powstania właśnie w tym języku bogatego ekosystemu treści i narzędzi zespołu strony społeczności. W rezultacie programiści często muszą tłumaczyć przykłady Groovy na Kotlin DSL, co może być czasochłonne i podatne na błędy ze względu na spore różnice w składni, API i ogólnej logice języka. Utrudnia to programistom wykorzystanie pełnych korzyści płynących z Kotlin DSL.

I tutaj całe na biało wchodzi Google. Firma (a właściwie zasiadająca w radzie Kotlin Foundation Grace Kloba) zapowiedziała bowiem, że Kotlin DSL stanie się domyślnym dialektem dla androidowych projektów opartych o Gradle. Całość stanowić ma impuls dla reszty społeczności, żeby porzucić ten czas porzucić Groovy’ego i zmodernizować swoje buildy.

Innymi słowy – miło Cię było poznać Groovy. It was fun while it lasted.

Nie bez przyczyny pewnie zresztą to właśnie dzisiaj rano mieliśmy premierę Gradle 8.1, który wprowadził sporo dodatkowych poprawek do Kotlina (ale też np. wsparcie dla JDK 20). Powyższy ruch jest określany bowiem jako rezultat wieloletniej współpracy między Google i Gradle, gdzie ten ostatni reagował na stały feedback i pomógł doprowadzić narzędzie do momentu, gdy wspomniana deklaracja mogła zostać odpowiedzialnie złożone.

I w ten sposób możemy płynnie przejść do kolejnego punktu, którym jest…

Rozszerzenie składu Kotlin Foundation

Tutaj będzie krótko, bo też samo ogłoszenie jest bardzo klarowne – Kotlin Foundation, początkowo założona przez Google i JetBrains, poszerzona została o kolejnych członków. Oprócz wspominanego już Gradle (pewnie się spodziewaliście), dołączy również oraz… Shopify. Ten ostatni kojarzył mi się głównie z Ruby, więc jest to pewne zaskoczenie, ale okazuje się, że firma aktywnie używa Kotlin Multiplatform.

I na samym końcu przejdziemy sobie właśnie do tego ostatniego.

Dalszy rozwój Kotlin Multiplatform

Jak pewnie stali czytelnicy tego newslettera wiedzą (nowych zapraszam do subskrypcji, poznamy się lepiej 😄), siedzę głównie po stronie Backendu. Dlatego też Multiplatform nigdy nie był dla mnie bardziej ciekawostką, aczkolwiek z czasem zacząłem traktować ten projekt z nieco większym szacunkiem. I choć takie zapowiedzi jak zmiana Jetpack Compose w Compose Multiplatform przyciągają uwagę, a wydanie wersji tego ostatniego na iOS z pewnością przyciąga uwagę, to ja najbardziej cieszę się na rozwój wersji WASM. Od pewnego czasu coraz bardziej interesuje się WebAssembly i wierzę, że z roku na rok będzie stawało się ważniejszym elementem ekosystemu programistycznego.

Ciekawostka – jeśli wczytać się w dokumentacje, to okazuje się, że cały Compose for Web jest oparty właśnie na Kotlin/Wasm. Pokazuje to tylko, z jakim potężnym narzędziem mamy do czynienia.

Było tego trochę, ale muszę przyznać, że bawiłem się jak na Google I/O ze starych czasów, kiedy pokazywali więcej narzędzi dla Developerów niż informacji o zmianach pod maską wyszukiwarki. A to tylko Keynote. Jutrzejszy poranek przyniesie bowiem sesje Coroutines and Loom behind the scenes prowadzoną przez Romana Elizarova. Możecie być pewni, że zrobię moje małe podsumowanie… ale to już za tydzień.

TLDW: Wrażenia z Keynote KotlinConf 2023 – JVM Weekly vol. 131