Varför Kotlin är fantastiskt, men du kommer ändå att fortsätta med Java

Oavsett vilken grupp du tillhör finns det en anledning till att du stannar kvar hos Java. Och jag klandrar inte dig. Det har utan tvekan det mest utvecklade, universella och kompletta ekosystemet i hela världen. företag världen. Språket har en väl avvägd uppsättning funktioner, någonstans i den rätta zonen mellan för mycket och för lite. Och nya funktioner läggs sakta men säkert till, vilket gör att det i stort sett är uppdaterat med nyare trender i programmeringsvärlden.

Känner du till Lombok Men? Om du inte gör det rekommenderar jag starkt att du provar. Om du gillar det, så har jag något bara för dig att prova. Ett helt nytt språk, som genom sina funktioner gör Lombok föråldrat. Det heter Kotlin.

Kotlin? Du menar Android-språket?

Kotlin på Android blev välsignat av Google själv till den grad att det blev det de facto språk som valdes för plattformen. Det här är inte vad jag kommer att fokusera på i den här artikeln, men Android är verkligen den plats där jag träffade Kotlin för första gången.

Min arbetskollega höll på att utveckla en app för ett då aktuellt projekt...på egen hand. Tidsfristerna närmade sig dock snabbt, så jag fick i uppdrag att hjälpa honom att uppfylla dem. Låt mig nu förflytta mig tillbaka i tiden till det ögonblicket. Aaaand... YUCK! Varför använder han något konstigt språk som låter som en ketchup varumärke!? Det ser hemskt ut!

Varför står det "fun" före varje funktion? Som om jag inte redan vet vad det är. Dessutom har jag redan kul med Java Hur som helst. Och var är returtypen? I slutet? Är du galen? Vad är det, tilldelar du något till en funktion? Det är ju helt obegripligt! Det hela ser bara ut som Java med extra steg! Vänta, var är klassen som den här metoden tillhör? Var gömde du den din ketchup-klingande, Java imiterande ursäkt för ett programmeringsspråk? Åh nej, det gjorde du inte. Åh nej, det gjorde du inte. ÄR DET DÄR EN GLOBAL FUNKTION? Det räcker, jag är klar, jag ringer polisen.

Spoilervarning: Jag ringde inte polisen. Oavsett om jag gillade det eller inte var jag tvungen att anpassa mitt Java-centrerade tankesätt för att passa ett annat språk. Det kommer dock inte att vara så illa, eller hur? Det är fortfarande ett JVM-språk, det är säkert bara ett annat Java. Kanske till och med med några coola extrafunktioner? Motvilligt började jag arbeta med projektet.

Java med extra steg

Om Java är så bra, varför finns det ingen Java 2? Skämt åsido, det var vad jag tänkte för mig själv. Jag ska bara låtsas att Kotlin är Java 2. Ny syntax och allt, men jag behöver bara lära mig tillräckligt mycket av det för att avsluta projektet. Oj oj oj, vad jag hade fel.

Efter att ha provat det i bara en dag eller två insåg jag snabbt att både Kotlin och Java är inte så elastiska. Att försöka böja dem mot varandra slutar oundvikligen med att en av dem knäcks på mitten. Det blev uppenbart att Kotlin är en sak för sig, och det faktum att det fungerar på en JVM betyder nästan exakt ingenting ur en programmerares synvinkel. (På en sidoanteckning kan det också transpilera till JavaScripteller kompileras till en inbyggd binär fil).

Plan B då. Lär dig faktiskt känna språket. Att läsa dokumenten för första gången skickar några rysningar genom en erfaren Java-programmerares ryggrad. Till exempel:
- tidigare nämnda globala sammanhang på högsta nivå
- parameter- och funktionsreturtyper som anges i slutet

fun sum(a: Int, b: Int): Int {
   returnerar a + b
}

funktionens kropp kan vara ett uttryck (med hjälp av likhetstecken)

 fun sum(a: Int, b: Int) = a + b

om uttalandet kan ge ett resultat

 val y = if (x == 1) {
 "ett"
 } else if (x == 2) {
 "två"
 } else {
 "andra"
 }

Okej, jag måste bara vänja mig vid det. Bara en annan syntax. Vad mer har du att erbjuda, herr Kotlin?

 värde?.metod() // exekvera om inte null

Okej, att bli av med if (värde == null)...en poäng till dig. Vad har du mer?

fun check(list: List, alternative: Boolean) = when {
 list är LinkedList -> print("linked")
 alternativ -> print("alternativ")
 list.size > 50 -> print("big")
 annat -> print("annat")
 }

Hmm trevligt, kan vara praktiskt att undvika om andra blockerar, verkar dock fortfarande som en gimmick.

 objekt SingularObject: Counter() {
 var a = 14
 fun test() = if (a > 10) "mer" else "mindre"
 }

Ok, den där ser faktiskt användbar ut, jag gillar den! Å andra sidan kan jag skapa en singleton i Java också. Kanske blir det inte så elegant, men det är inget riktigt nytt. Har du några ess i rockärmen? Typ, riktiga tungviktare?

 var s: String = null // kompilerar inte, icke-null-typ

Vänta... Vad?

Misstag som kostar miljarder dollar

Föreställ dig en kodbas där du inte behöver oroa dig för null-säkerhet. Tänk dig att bara ta för givet att varje referens faktiskt innehåller något meningsfullt. Tänk dig att vara säker på att varje null-relaterat problem hanteras i förväg.
Föreställ dig inte mer. Alla referenser i Kotlin är inte nullable som standard. Om du vill göra den nollbar måste du medvetet fatta det beslutet, och uttryckligen ange det i kod:

 var s: String? = null

Jag förstår att du kanske är skeptisk till hela idén just nu. Du är van vid nullable-referenser. Du har det i bakhuvudet när du kodar. Du lärde dig var du behöver vara försiktig. Mina tankar exakt. Kommer från JavaDet kändes konstigt först. Som, vad är poängen? Det kommer inte att magiskt få alla relaterade problem att försvinna. Jag kommer bara att behöva lägga till "?" överallt, låter som en syssla.

Men jag bestämde mig för att dyka djupt in i språket, eller hur? Låt oss få det på ditt sätt mister Kotlin. Jag började anstränga mig för att eliminera så många nollställbara variabler, fält och parametrar som möjligt. Steg för steg lärde jag mig att använda språkfunktioner som gjorde det lättare att eliminera nollställbara referenser, t.ex. operatorn safe call "?.", operatorn elvis "?:", delegerade egenskaper, "let"-metoden m.m.

Med tiden lyckades jag få vissa klasser att bara innehålla icke-nullfält och metodparametrar. I grund och botten visste jag att om en klass instantierades framgångsrikt kunde jag nästan glömma bort nullability i metodkroppar. Det var en lycka. Med tiden uppskattade jag detta mer och mer. I slutändan tänkte jag dock inte på det som en mördande funktion, Java kändes fortfarande som hemma. Ända tills...

Comebacken

Projektet närmade sig sitt slut. Jag lärde känna Kotlin mer och mer, och med den kunskapen blev koden allt mer prydlig, läsbar och koncis. Man kunde se förbättringarna med blotta ögat i commit-historiken. Men nu är det äntligen dags. Med oväntat goda minnen av det nya språket var det dags att säga adjö och återvända till den ljuva komfortzonen i Java. Det trodde jag i alla fall.

Känner du igen den där känslan när du börjar uppskatta något i samma ögonblick som det försvinner? När man inte inser hur mycket man förlitar sig på något förrän man inte kan använda det längre? Det var det allra bästa exemplet på den känslan som jag förmodligen någonsin har upplevt i mitt liv.

När jag återgick till att skriva koden i JavaJag blev nästan livrädd för att vissa funktioner saknades. Det var som om min hjärna omedvetet, felaktigt eftermonterade Kotlin-funktioner i Java. Jag upplevde situationer där jag faktiskt började implementera något, bara för att inse att det inte kommer att fungera i det här språket. I bästa fall kunde jag skriva det Kotlin-liknande, men det skulle vara skrymmande, oläsligt och/eller kräva för mycket boilerplate.

Null safety var naturligtvis den funktion jag saknade mest. Men jag blev förvånad över hur många mindre saker som blev naturliga för mig: namngivna parametrar, properties istället för getters och setters, "==" som equals och "===" som referential equality, kvalificerade "this", extension functions, implicit singular lambda parameter, "_" för oanvända lambda parametrar, dataklasser, scope functions, andra Kotlin stdlib funktioner, operatorer och mycket mer. Och hur allt passar ihop på ett snyggt sätt. I jämförelse kändes Java ... primitivt.

Det kändes faktiskt så illa att jag började fundera på att byta till Kotlin helt och hållet. Teoretiskt sett är det helt interoperabelt med Java, du kan bara lägga till Kotlin-stöd i ett befintligt projekt och börja skriva nya klasser. Kotlin-sidan vet hur man "pratar" med Java, och Java-sidan vet inte ens att den "pratar" med ett annat språk. Och efter kompileringen till bytecode gör det egentligen ingen skillnad för JVM.

Verklighetskoll

Så vad väntar du på? Om språket är så bra som du säger är det bara att använda det! Kanske inte i befintliga projekt dock, jag vet att det ska vara interoperabelt, men att blanda två olika språk på det här sättet låter fult.

Ok, så för nya moduler - Kotlin är det. Eller är det så? Du arbetar i en Team. Du måste rådfråga dem och övertyga dem om det nya språkets förträfflighet. Vad är det? Tycker de inte om det? Låter som om de inte vill anstränga sig för att lära sig det. Du kan inte klandra dem, du var också skeptisk till en början.

Projektledaren! Ja, det är han! Han kommer säkert att förstå det stora värde som Kotlin skulle tillföra vårt team. Åh, den storhet som kommer att komma!
-Nej
-Varför? -Vänta, varför?
-Teamet vet inte om det.
-De lär sig! -De lär sig!
-De vill inte lära sig. -De vill inte lära sig.
-Du kan göra dem! -Ja.
-De behöver inte lära sig.
-Jag menar, det är sant, men tänk på möjligheterna!
-Ja, tänk på problemen först. -Ja, tänk på problemen först.

Legenden säger att det finns ett projekt. Ett projekt som är stort och komplext, men snyggt skrivet i varje del. Ett projekt där alla utvecklare är eniga om de lösningar som används. Där nya funktioner bara flödar smidigt från programmerarnas tangentbord. Där buggar är sällsynta och lätta att åtgärda.

Har du sett ett sånt projekt? Nej, det har jag inte. Vissa kom nära, men de flesta av dem är en stor röra av äldre kod. Och om de inte är det, kommer de förmodligen att bli det någon gång i framtiden. Föreställ dig nu att du slänger in ett annat språk i mixen. Det introducerar nya sätt att göra misstag. Det kräver att utvecklarna vet vad de gör. Det är en risk, minst sagt.

Tänk nu också på rotation av utvecklare. Människor kommer och går. Ska du tvinga varje ny utvecklare att lära sig ett helt nytt språk? Nej, det är kontraproduktivt. Kommer du att anställa Kotlin-utvecklare i första hand? Lycka till med det, att anställa en bra Java-utvecklare är svårt nog.

Folk har försökt. Jag måste säga att jag inte håller med om de flesta anklagelserna i den artikeln. Det finns en del giltig kritik där, men jag tror att de inte använde Kotlin tillräckligt för att faktiskt förstå "Kotlin-sättet". Många kommentatorer under den artikeln verkar tänka på samma sätt.

Det spelar dock ingen roll. Jag slår vad om att det här skulle hända i ditt projekt också. "Provade det, gillade det inte". Du kommer inte att få dem att spendera mer tid på det. Du kommer inte att tvinga dem att försöka igen. Du kommer inte att få dem att ge det en chans till. Och ur en praktisk synvinkel kan de ha rätt. Java är så populärt att det känns överflödigt att använda något annat på JVM:en.

Varför denna artikel då?

Du har just ägnat en hel del tid åt att skriva en artikel som inte verkar ha någon poäng. Varför skulle jag försöka lära mig ett språk, om du säger att det ändå är meningslöst?

Tja, jag tycker inte att det är meningslöst. Jag tycker fortfarande att Kotlin är fantastiskt. Jag vill fortfarande faktiskt använda det (och det gör jag faktiskt för mina privata projekt). Om jag kunde skulle jag bara byta till det och glömma bort begränsningarna med Java. Men den nuvarande verkligheten säger att jag inte kan det. Och jag vill försöka ändra på det.

Min avsikt är att du, kära läsare, åtminstone ska överväga möjligheten att lämna den mysiga Java-komfortzonen. För kanske, bara kanske, kommer du att älska Kotlin lika mycket som jag gör. Och om du gör det, är det ytterligare en Kotlin-kunnig utvecklare på marknad.

Läs mer om detta:

Den bästa typen av projekt för Java

3 Vanliga utmaningar för nystartade företag inom mjukvaruproduktutveckling

Rätt sätt att hitta de bästa Java-utvecklarna