Aki Kotlinhoz nyúl, már nem akar Javához visszatérni (x)

Címkék

A hatékony, tömör kódot produkáló nyelv népszerűsége rohamosan növekszik – többek között a Telekom backend fejlesztői körében is, ahol a Kotlin bevezetése az elmúlt három év egyik sikersztorijának bizonyult.

Az agilis, microservice-ekre épülő alkalmazások, szolgáltatások létrehozásához a megfelelő építőelemek kiválasztása is elengedhetetlen - ez a Telekom backend fejlesztői berkeiben is gyorsan egyértelművé vált, és megfogalmazódott az igény egy olyan technológia iránt, amely nem csak innovatív, de sok szoftvermérnök is elérhető vele. Ehhez kiemelten fontos szempont volt, hogy gyorsan használatba vehető legyen, ne kelljen fél évet rászánni a megfelelő szintű kitanulásra, illetve nem utolsó sorban a nagyvállalati környezettel is kompatibilis tudjon maradni. Így esett a választás a Kotlin nyelvre, amellyel a vállalat több mint három éve kezdett komolyabban foglalkozni.

A Kotlin backend felhasználásával kapcsolatos tapasztalatokról Major Balázs, a HWSW free! 2021. június 9-én megrendezett Java/Kotlin online meetupon tartott előadásában számolt be. Balázs 15 éves fejlesztői múltjából az utóbbi két évet a Telekomnál chapter leadként töltötte, ahol egységes megoldásokkal igyekeznek standardizálni a fejlesztési folyamatokat - ennek megfelelően a Kotlin nyelvet is standard opcióként kínálták már az első perctől a fejlesztőcsapatnak.

KIPRÓBÁLNI ÉS MEGSZERETNI

A Kotlin használatának bevezetése a backend fejlesztésben tehát bő három éve kezdődött a Telekomnál, ekkor lehetőség nyílt egy alkalmazás teljes újraírására, Kotlinra támaszkodva. A szóban forgó szoftvert a csapat már microservice alapon kezdte felépíteni, ehhez pedig a Kotlin ideális választásnak bizonyult, miután az kompaktabb, tisztább kód írását tette lehetővé. A fejlesztők nagyon gyorsan átálltak a Kotlin fejlesztésre - az általános vélemény alapján a váltás semmiféle nehézséget nem jelentett. Olyannyira nem, hogy a Kotlin alap nyelvi elemeit megtanulni egy-két hét elegendő volt, ezzel a tudással pedig már biztonsággal neki lehetett állni a backend fejlesztésnek - persze ez az alapvető megértést jelenti, egy magasabb fejlesztési szint eléréséhez itt is több időre van szükség. A tapasztalatok szerint a fejlesztők olvashatóbb, kifejezőbb kódot tudtak írni Kotlinban, problémás területnek talán csak a Spring, illetve a reaktív integráció volt mondható - a csapat első kotlinos szárnypróbálgatásai során ez a terület még nem volt kiforrott.

A vállalatnak nem sokkal később a Kotlin és a Java közvetlen összehasonlítására is lehetősége adódott, mikor a Telekom egy másik fejlesztőcsapata két évvel ezelőtt, a webshop mögötti backend logikát kezdte fejleszteni. Miután nagy volt a hajtás, ehhez Javát kezdtek használni, hiszen abban már kényelmesen mozogtak, kiterjedt tapasztalatuk volt a nyelvvel - akkor a projekten dolgozó fejlesztők úgy vélték, túl sok idő menne el, mire a Kotlinnal megfelelően meg tudnának ismerkedni és hatékonyan tudnának vele dolgozni. A fejlesztést így akkor Javával is vitték végig, egy évvel ezelőtt azonban a csapat már kényelmesebb keretek között írhatta újra az alkalmazást, ekkor pedig már ők is a Kotlinhoz nyúltak. A visszajelzések itt is rendkívül pozitívak voltak, a fejlesztők nagyon megszerették a nyelvet, dicsérték annak jó formázottságát. Ezt követően több másik csapat is zökkenőmentesen át tudott állni a nyelvre, amelyben hatékony tömör kódot tudtak készíteni - Balázsék chapter leadként már az új fejlesztőcsapatoknak is a Kotlin nyelvet javasolják számos projekthez.

De a Javát nem is kell feltétlenül teljesen elereszteni a Kotlin felé történő nyitáshoz: a vállalatnál olyan projekt is volt, ahol az erős Java kompetenciával rendelkező csapat egyik fele nem akart megválni a jól bevált nyelvtől. Itt végül azokat a kisebb microservice-eket, amelyeket egy-egy Kotlinkedvelő fejlesztő el tudott vinni, utóbbi nyelven írták meg, míg a közös, nagyobb megoldásokat Javában - ez a vegyes modell is működőképesnek bizonyult. A Kotlin bevezetését a Telekom sikertörténetként könyvelte el, a nyelv számos erősséget fel tudott vonultatni, amelyeknek hála teljes mértékben alkalmasnak bizonyult a hatékony backend fejlesztésekhez.
Az egyik ilyen a teljes JVM kompatibilitás, remek átjárhatóság a Java felé, amelyet az IDE is támogat. Egy másik komoly erősség az Extensions , amelyek elősegíti a kód tömörségét azzal, hogy bonyolult örökléseket tudunk megspórolni, illetve az üzleti logikák egyszerű kifejezésének is teret enged. Ugyanígy a String Templates is komoly könnyebbséget jelentenek az átlátható kód írásában, továbbá az Smart cast is ott van a fegyvertárban, amivel a típus inteligens meghatározására is lehetőség van a feltételekben.

MÉG NINCS KOLBÁSZBÓL A KERÍTÉS

Persze még akadnak leküzdésre váró akadályok is a nyelv háza táján, ilyen a Gradle és a Kotlin nehézkes használata - a problémákra pedig a jól bevált Stack Overflow böngészése sem jelent garantált megoldást, a Kotlin nyelv köré épülő fejlesztői közösség még nem olyan kiterjedt és aktív, mint a Java esetében, ugyanakkor ez a terület is folyamatos javulást mutat a Telekom fejlesztőinek tapasztalatai szerint. A kódgenerátorok kapcsán is van tér a fejlődésre, a Kotlinnal használható megoldások zöme - például Swaggerből történő kódgenerálásra - még nem mondható százszázalékosnak, itt jellemző, hogy hibák bukkannak fel. Jelenleg a Data Class-ok öröklődésére sincs mód a Kotlinban, ami miatt szükség lehet bizonyos osztálystruktúrák újragondolására.

A felmerülő gyengeségekkel együtt a Kotlin népszerűsége a Telekom zászlaja alatt töretlen, amit jól mutat, hogy a fejlesztők nem csak magára a nyelvre, de annak holdudvarára is kitekintettek, és a Java mellől ismert megoldások helyett (például a nehézkes, de mára nagyrészt kisimított Spring kompatibilitás) natív, kotlinos frameworköket kezdtek használni. Ezek sok esetben jó alternatívák lehetnek, még ha nem is lehet egyelőre teljesen kiforrott megoldásokról beszélni - ugyanakkor komoly előny, hogy ha egy projektben valamiért egy-egy keretrendszer mélyére kell ásni, ott is ugyanúgy Kotlin dolgozik, mint az adott fejlesztés többi részén. Ilyen például unit teszteléshez használt Kotest vagy épp a kotlinban megírt, MockK névre hallgató mockolási keretrendszer. Szintén említést érdemel a Ktor, amely bizonyos esetekben a Spring Boot kiváltására is alkalmas lehet, pehelysúlyú, kotlin-natív alternatívaként.

A Telekomnál tehát a Kotlin backend fejlesztésben való bevetése komoly sikert aratott a fejlesztők körében, mára amire csak lehet, beleértve egy sor nagy kaliberű projektet, Kotlint használnak a csapatok. A cégnél a bevezetés fő tanulsága: aki egyszer elkezd Kotlinban fejleszteni, nem akar már Javára visszatérni.

A Telekom jelenleg is keres Java/Kotlin fejlesztőket, a Java kompetenciával érkezőknek pedig minden támogatást megad a Kotlin nyelv elsajátításához.

[A MagyarTelekom megbízásából készített, fizetett anyag.]

Hozzászólások

> A Kotlin használatának bevezetése a backend fejlesztésben tehát bő három éve kezdődött a Telekomnál, ekkor lehetőség nyílt egy alkalmazás teljes újraírására, Kotlinra támaszkodva.

Erdekel, hogy egy olyan cegnel, mint a Telekom, mik voltak a szempontok a nyelv valasztasakor? Miert Kotlin es miert nem Rust v. Go? (vagy barmi mas) Keszult erre vmi osszehasonlitas, amit meg lehet velunk osztani?

Wiki szerint:

Development lead Andrey Breslav has said that Kotlin is designed to be an industrial-strength object-oriented language, and a "better language" than Java, but still be fully interoperable with Java code, allowing companies to make a gradual migration from Java to Kotlin.[28]

van egy rakat java fejlesztojuk, igy a kotlin logikus valasztas, hiszen az atallas javaskent nem nagy effort. nehany het alatt egesz jol atlatod, par honap alatt teljesen belerazodsz. az is szempont volt, hogy volt egy nagy lelkesedes es erdeklodes a kotlin irant, igy onmegvalosithattak. nem vagyok biztos benne, de a videoban vannak errol reszletek.

az is szempont nyilvan, hogy az esetleges es torvenyszeru fluktuacio jol potolhato javasokkal. a go eseteben eleve az atallas is nehez javasoknak, a potlas pedig igazi aknamezo, mert itthon nagyon-nagyon kevesen foglalkoznak meg goval.

van egy rakat java fejlesztojuk, igy a kotlin logikus valasztas

Miért volt szükség a váltásra? Mit tud a Kotlin, amit a Java nem? Nem feltétlenül T-specifikusan kérdezem, illetve a JVM ökoszisztémában egyedül a Scalában vagyok valamennyire járatos, szóval nem kötekedés a cél.

Egy gyors Google keresés után ilyen szakmai összehasonlításokat találtam például:

Kotlin programs do not need semicolons in their program. This makes the programs easy to read and understand.

Én két helyen ismerem előnyét:

  • Android sokáig le volt maradva valahol a Java 6-7 (2006?) lehetőségei szinten
  • és Javas frontend frameworkökben kényelmesebb

Az elsőnél, amennyire követtem, az Android anno az Apache Harmony projekttel kezdett, ami egy Sun/Oracle független GPL Java implementáció volt, s mikor a Google ebbe beleszállt, ez valahol a Java 6 környékén járt. Utána még 1-2 Java 7 nyelvi feature (meg java API) belekerült (pl.: `List<Integer> intList = new ArrayList<Integer>()` kellett a hatosban, a hetestől elég a `List<Integer> intList = new ArrayList<>()`), de a Java 8 (stream api, lambdák, proper időkezelés, és későbbi, 2011 utáni fejlesztések) kb. mind elérhetetlenek voltak Androidon nagyon sokáig. Ha jól értettem anno, akkor az Oracle v. Google per miatt nem merte (akarta) a Google implementálni a frissebb Java featureöket.

Voltak rá különböző megoldások (retrolambda, ami Java 6 bájtkódra fordította a lamdákat, threetenbp ami a java.time csomagot backportolta, stb), de nyögvenyelős volt. Ez egy idő után megoldódott, amikor az OracleGoogle pernek vége lett, és a Google vállalta, hogy átáll OpenJDK-ra Androidon -> de ha jól tudom, ez valami Android update-ként ment ki a készülékekre, Androidon meg ez még mindig nyögvenyelős, szóval ki tudja, mikortól érhető el minden Android készüléken a friss Java API.

Cserébe jött a Kotlin, ami Java 6-os bájtkódra fordult, szóval gond nélkül ment minden Androidon, voltak benne minden XXI. százai nyelvhez illő dolgok, szóval Android körben hamar népszerű lett.

A másodikra (frontend) pl a Vaadinos példa, aki még használ ilyet:

VerticalLayout layout = new VerticalLayout();
Button button = new Button("Click me");
button.addClickListener(() -> Notification.show("Clicked"));
button.setWidth("100%");
layout.add(button);

helyett lehet ilyet írni

var layout = verticalLayout {
    button {
        label = "Click me"
        width = "100%"
        addClickListener { Notification.show("Clicked") }
    }
}

tldr: Könnyen össze lehet rakni Kotlinban type safe DSL leírókat, amikből ilyeneket könnyű építeni. Bár én nem kotlinoztam Androidon (s androidot is csak hobbiból láttam), de tippre ott is egyszerűbb type safe DSL layoutot leírni, mint XML-ben.

A Scala is tudott elméletileg egy csomó ilyesmi dolgot (Java 6os bájtkód szinten lambdákat, pl), de egyrészt ők hozták a saját toolingjukat (sbt), másrészt a Java interop ott szopás, amennyire emlékszem. A Kotlinnak az a nagy előnye, hogy egy meglévő, nagy projektbe is könnyen be tudod dobni, ha csak 1-1 új felületet írnál meg benne, vagy új kódot kell Androidon ebben fejleszteni. Az IDEA, de a Kotlin compiler is talán a mai napig félig Java, félig Kotlin, mert olyan seamless az interop, hogy nem éri meg nekik kipucolni a Java kódot belőle.

Cserébe ha egyszer bekerül egy projektbe, akkor kipucolni sokkal nehezebb -> amíg Java->Kotlin konverzió van automatán az Ideaban, addig fordítva már nem ad a JetBrains rá OOB megoldást. Plusz Kotlinban tényleg lehet mágiákat építeni, és junior jávásokat sokkal nehezebb egy-egy kotlinos dologra ráállítani, mintha mindenki maradt volna Javanál.

Jó összefoglaló, csak egy kiegészítés: Az Apache Harmony Apache licencű volt, és pont ezért választotta a Google, mert akkoriban a Linux kernelen kívül gyakorlatilag nem volt GPL licenszű kód az Androidban, userlandben pláne nem. Még egy busybox se, írtak helyette sajátot.

Ez azért volt így, mert meg kellett győzni a mobilgyártókat, hogy az Android miatt nem kell majd kiadniuk a kódjaikat, és a GPL-től féltek mint a tűztől. 

Pár évvel később, amikor jött az Oracle, hogy akar egy "kis" pénzt az Androidból, akkor már a gyártók is tök máshoz álltak hozzá (+ a csillió dollár amit már addig is kerestek az Androidon is segített), így kb. senkit nem izgatott, amikor a Google lecserélte OpenJDK-ra az implementációt.

Azokon kívül, amit leírtál, a Kotlin előnye, hogy új nyelv, könnyebb hozzányúlni, berakni - kivenni dolgokat, a process sem annyira lassú mint a Java-nál (bár ott is próbálnak gyorsítani).

a Kotlin előnye, hogy új nyelv, könnyebb hozzányúlni, berakni - kivenni dolgokat

Igeeen, ebben nem vagyok teljesen biztos, hogy mennyire előny, meg mennyire gyorsabb tényleg.

Múltkor hozzá kellett nyúlnom egy projekthez, ami 1-2 éve megállt, és voltak benne Kotlinos részek, hát, nem volt egy leányálom - mondjuk nem csak a Kotlin miatt. Ugyanitt, mintha a Java sok esetben átgondoltabb lenne, de a franc se tudja.

A Kotlin semmi olyat nem tud, amit a Java ne tudna. Üzleti logikák megvalósítása Kotlinban egyszerűen implementálhatók:

- adat map-elési, struktúra másolási logikák,

- null ellenőrzések,

- adatszerkezetek leírása - data class, itt mondjuk a Lombok is opció lenne Java-ban.

Egy hagyományos back-end kód tele van ilyen elemekkel, és amit a Kotlin hozott nekünk, hogy ezeket a kódokat tömören, közérthetően le tudjuk írni ebben a nyelvben.

Nem készült összehasonlítási tanulmány. JVM alapú nyelvvel szerettünk, tudtunk elkezdeni foglalkozni:

- mert a Java fejlesztőt találni 3 évvel ezelőtt könnyebb volt - szerintem ma is -, mint mondjuk Go, Rust fejlesztőt,

- Java tapasztalat megvolt a meglévő fejlesztők között,

- Spring megoldások is ismertek voltak.

Így a Kotlin, mint JVM alapú nyelv jó választásnak tűnt akkor.

Egyébként van Node.JS fejlesztési írány is nálunk, ami különböző típusú szolgáltatások fejlesztésére alkalmasnak tünt, például BFF jellegű képességekkel rendelkező szolgáltatásokra. Így ezen gondolkodás mentén Node.JS kompetenciát is építettünk.

Szerkesztve: 2021. 06. 21., h – 16:48

Nyúltam Kotlinhoz és mégis inkább a "sima" Java-ra szavazok. Kéremjaviccsaki.

Persze, ha nagyon muszáj, akkor beárazom a Kotlint a bérigénybe és mosolyogva fogom újságolni, hogy mennyire jó és nagyszerű, hogy vele dolgozhatok!

Mi visszaalltunk Java-ra mert a Kotlin egy darab sz.r, egyszer mar li is irtam itt valahol hogy mennyi minden baj van vele.... de erdemes megnezni a bug listat a legtobb szavazatot kaport evek ota nyitva allo bug-okat ajanlom foleg a "fogalmunk sincs hogy javitsuk igazabol nem is lehet"

nem ismerem a kotlin-t gyakorlatban, de többszöri nekifutásra olvasgatva nekem is "ellenszenvesnek" tünt
hozzáteszem én java rajongó vagyok, a hibái ellenére is

"egyszer mar li is irtam itt valahol hogy mennyi minden baj van vele...."
adsz egy linket? kíváncsi vagyok

szerk: megtaláltam

Szerkesztve: 2021. 06. 21., h – 18:24

miert is akarna visszaterni ? hiszen

"az igazi programozó akármilyen nyelvben is bír FORTRAN programokat írni."

 

tehat aki Javaban tudott Fortran programot irni, az Kotlinban is megoldja :D

HUP te Zsiga !

Kotlinhoz meg nem volt szerencsem. Javahoz viszont nyultam mar, es nem akarok hozza visszaterni (sose szerettem).

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Szerintem a Java reputációját egyrészt a (Hajbi, fogd be a füled) telebloatolt java SE telepítő másrészt a túlbonyolított keretrendszerek vágták el, amúgy csak a JDK egy kis Maven körítéssel kis projektekhez ma is gyors és hatékony, valamint jönnek értelmes fejlesztések, még ha késve is.

nyilvan van hr hozadeka, mert jo uzenet, de nem ez driveol egy ilyen valtast. volt egy modernizacios folyamat, nagyon sok rugalmassagot kaptak, lett sajat vanilla kuberbetes cluster, modern cicd meg miegymas, a javasok meg raizgultak a kotlinra. elmodasok szerint egyebkent joval hatekonyabb a melo vele, de ez nyilvan projekt es csapatfuggo is.

Én többször is nekifutottam Kotlin kapcsán annak, hogy mire képes backend oldalon és a hello world bonyolultságú dolgok valóban álomszépek, de amikor szembejön egy hiba egy Java library használata kapcsán valahonnan a mélyből és ki kellene deríteni, hogy ki a hunyó, akkor azért sokszorosát lehet elbaszni időben, mint amennyit meg lehetett spórolni a Java 11 kapcsán, amibe azért szépen belecsorogtak azok a dolgok, amik ott vannak Kotlin-ban.

Tudni érdemes, hogy a Kotlin a Java 6 és a Java 7 közötti röpke 7 éves szünetben keletkezett, két évvel azután, amikor a Sun megvevődött az Oracle által és mindenki travoltázott évekig, hogy akkor most mivel mi lesz. Na, azóta azért a Java is erősen fejlődött, én alapvetően nem tudok olyan backend dolgot mondani, ami nem lenne benne a Java 11 repertoárban és/vagy ne lenne rá valami egymillió felhasználós kvázi-standard library, Java 17-ről nem is beszélve, ami szeptemberben fog érkezni.

Ja, és persze a szokásos stateless kis fosokhoz van egymillió Kotlin backend library és framework, persze mindegyik félkész a maga módján, de ezen felül, ha felmerül, hogy akkor most kellene ebből a fasza kis szolgáltatásból egy stateful HA cluster, akkor megy a stand up meeting során az lassú egymásra nézés, hogy ki mondja meg a führernek főnöknek, hogy olyan nem lesz ebben, körbe kell azt tákolni, de úgyis le fog égni a picsába, szóval felesleges nekikezdeni.

Ehhez hozzájön az, hogy a Kotlin még mindig, ennyi év után is mozgó célpont, megírsz valamit és egy év múlva nem vagy nem úgy fordul, ami Android esetén azért elmegy, mert a Google miatt évente többször is hozzá kell nyúlni az alkalmazáshoz, különben kihajítják a picsába a Play-ből, szóval nem olyan fájdalmas, de amikor a Kotlin backend legacy kód lesz, megöregszik és óvodából iskolába megy, elmegy mindenki a cégtől, aki valaha azon dolgozott, akkor azért lesznek szerintem vérhugyozások ebből bőven néhány év múlva.

-

Android esetén egyértelműen megváltás a Kotlin, mert ugye ott még Java hét-és-egynegyed van nyelvi szinten, amiben programozzon eseményvezérelt többszálú dolgokat az, akinek két anyja van, ha amúgy ott a Kotlin, még azt is érdemes ezért bevállalni, hogy évente egy-két nagyobb mélytorkos szopás becsúszik.

Egy mondatban összefoglalva: Az egyén az önzőségből, sikervágyból elkövetett rövidtávú, agilis™ kényelmeskedését hosszú távon fizeti meg, illetve fizetik meg helyette mások.

Nincs ez másként a Bloatlin esetében sem.

Tudod, annyira sajnálom, hogy meghülyültél és nincs rá gyógyszer, mert írhatnál hatékony szoftvereket és beláthatnád, hogy a multik a fenntartható technológiai fejlődés ellenségei, de ehelyett magadon tartod a szemellenződ és balfaszozod azokat, akik megpróbálják rólad lerángatni.

A Bloatlin kényelmeskedés céljából íródott, amit te magad is elismertél az alábbi véleményeddel. [1]

Android esetén egyértelműen megváltás a Kotlin, mert ugye ott még Java hét-és-egynegyed van nyelvi szinten, amiben programozzon eseményvezérelt többszálú dolgokat az, akinek két anyja van, ha amúgy ott a Kotlin, még azt is érdemes ezért bevállalni, hogy évente egy-két nagyobb mélytorkos szopás becsúszik.

Ahogy feljebb azt is elismereted, mennyi bosszúságot okoz ez a kényelmeskedés és a legkisebb ellenállás felé való tendálás.

Az, hogy nem nevezed nevén, nem jelenti, hogy nincs ott.

Ahogy feljebb azt is elismereted, mennyi bosszúságot okoz ez a kényelmeskedés és a legkisebb ellenállás felé való tendálás.

Ha egy picit és értenél hozzá, akkor tudnád, hogy ugyanazon dex lesz a Java és a Kotlin eredménye is... de hát nem értesz te ehhez sem, csak belepofázol mindenbe felületes tudás nélkül is, ahol csak bekattan a rögeszméd.

ugyanazon dex lesz a Java és a Kotlin eredménye is

Ennek nem állítottam az ellenkezőjét.

Azt állítottam, hogy a Bloatlin egy kényelmeskedésre készített keretrendszer. Aminek az árát babzsákfejlesztőék hosszú távon fogják megfizetni. Ez egybevág az általad elmondottakkal.

Azt állítottam, hogy a Bloatlin egy kényelmeskedésre készített keretrendszer. Aminek az árát babzsákfejlesztőék hosszú távon fogják megfizetni. Ez egybevág az általad elmondottakkal.

Ha lenne két ásód, az egyik életlenebb, mint a másik, ezért azzal fele annyi négyzetmétert tudsz felásni egy óra alatt, akkor melyiket használnád?

Látom, a te kezedben pont annyira nem volt még ásó, mint Kotlin és Java projekt, de ugyanolyan tűpontosan tudod mondani a hülyeségedet, mint Kotlin és Java kapcsán... :D

A kérdésre, ha válaszolnál: ha lenne két ásód, az egyik életlenebb, mint a másik, ezért azzal fele annyi négyzetmétert tudsz felásni egy óra alatt, akkor melyiket használnád?

A kérdésre, ha válaszolnál: ha lenne két ásód, az egyik életlenebb, mint a másik, ezért azzal fele annyi négyzetmétert tudsz felásni egy óra alatt, akkor melyiket használnád?

https://a.te.ervelesi.hibad.hu/allito-kerdes

Van egy ásó, ami 20 év múlva is ugyanolyan életlen lesz, mint most (Jávád). Meg van egy másik, ami most éles, de 20 év múlva sokkal életelenebb lesz, mint az egyik (Kotlin). Én azt választom, amivel 20 év alatt változatlan minőségben tudom felásni a kertet, akkor is, ha ez pillanatnyilag (értsd: rövidtávon) nem a legjobb™, legtrendibb™, leghatékonyabb™. Végső soron pedig több kertet tudok vele felásni összesen 20 év alatt, mintha kényelmes rövidtávú célokat hajhászó, mindent azonnal akaró óriáscsecsemő babzsákkertfelásóként viselkedtem volna. Fura, hogy nem érted, hiszen te is leírtad. [1] De akkor beidézem, mert a személyem ócsárlása olyan e-orgazmusokat okoz nálad, hogy hajlamos vagy elfelejteni.

amikor a Kotlin backend legacy kód lesz, megöregszik és óvodából iskolába megy, elmegy mindenki a cégtől, aki valaha azon dolgozott, akkor azért lesznek szerintem vérhugyozások ebből bőven néhány év múlva

Már írtam, hogy ha egy kicsit is értenél hozzá, amihez hozzászólsz, akkor nem írnál ilyen hülyeségeket mint ebben a bekezdésben... de hát egy kicsit se értesz hozzá, ezért egyes szavakra bekapcsol a rögeszméd, és csak úgy fosod a hülyeséget.

egyes szavakra bekapcsol a rögeszméd, és csak úgy fosod a hülyeséget.

Valójában neked kapcsol be a "nem értesz hozzá", a szokásos elitista lózungok és a személyeskedés. Érdemi hozzászólást nem láthattunk tőled, azonkívül, amire reagáltam, és amivel egyébként egyetértettem. [1] Azóta folyamatosan csak az én általad vélt elmeállapotomról alkotott kényszerképzeteid és a személyem ócsárlása tették ki a hozzászólásaid.

Meghívsz Kotlin kódból egy másik Kotlin library-t, ami használ egy Java library-t és átadsz egy Java library-ból származó adathalmazt, benne Kotlin adathalmazzal, aztán valahol eltörik a kényes és törékeny 1:1 megfeleltethetőség, mert kicsit más a generics Kotlin esetén vagy megváltozik, ami elvileg konstans, ilyesmi, és a hiba helye vagy a stack trace semmit nem segít, mert olyan sorokra mutat, ami nincs is a kódodban, mert a kapt szétszedte és újra összerakta, pláne, ha a Java library-t egy elszánt Lombok specialista írta.

Legacy Android cuccoknál is ez a legnagyobb szopás, hogy az új dolgok Kotlin nyelven vannak, a régi dolgok Java nyelven és a kettő között nincs mindig tökéletes összhang, ami általában komoly szopásokat támaszt csendesen az ember asztala mellé. Tisztán Kotlin biztos jó lenne, de egyelőre nincs ilyen és nagyon-nagyon-nagyon távoli jövőben lesz talán.

Ha cross-platform a cél, nincs semmi speciális igény és van pár JavaScript fejlesztő, akik nem félnek a mobiltól, akkor jó irány lehet a React Native, de nagyobb az erőforrás igénye, mintha ugyanaz Kotlin lenne, illetve ami nincs még a platformon megvalósítva, az nincs (jó, vannak trükkök, de eh).