Bene e benvenuti su github.Siamo su github vero? Penso di sì.Ho anche fatto la respirazione prima di dire bene e benvenuti quindi adesso siamo tutto a posto.Anche oggi abbiamo un ospite speciale, un ospite speciale che già conosciamo, conosciamo molto bene visto che ormai il github non è fatto solo di avventori che vengono a raccontarci la loro storia ma anche di assidui frequentatori.E non sto dando degli alcolisti mi raccomando ci tendo a precisare frequentatori di bar non necessariamente beoni in questo caso vediamo No in realtà scherzo prima di presentarvi le ospite Il mio compito quello un po rompi scatole di ricordarvi i contatti quindi infochiocellagatebar.it Via email o @brainrepo su twitter oppure il nostro gruppo telegram frequentato anche dall'ospite di oggi.Quindi piccola pausa e ritorniamo subito col nostro ospite Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer I mezzo artigiani, i mezzo artisti, che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo Eccoci qua eccoci qua oggi abbiamo con noi Mattia Tommasone che è già venuto nell'episodio 48 quando abbiamo parlato di CodeReview ma è ritornato perché oggi parliamo di una cosa molto figa ciao Matteo! Sì, tra l'altro non solo sono stato qui e cioè mi sono trovato bene, come tu ma anche tutti gli affezionati del bar e del gruppo Telegram piuttosto attivo nel gruppo che mi trovo molto bene.Proprio appunto come dicevi tu è un bar in cui ci si trova bene non solo per gli alcolici di cui comunque io non nego di essere praticato.Bellissimo.Oggi vieni da noi a chiacchierare di una tecnologia che utilizzi tutti i giorni che è Kotlin con due t o con una t? perché si scrive con una t ma io l'ho messo doppia dappertutto vogliamo fare dell'ironia sulla tua origine sarda rispetto a questo e sul tuo raddoppiare le consonanti, sarebbe sportese.No ma io sarei in grado anche di raddoppiare le vocali quindi no sì allora Kotlin è in questo momento il linguaggio con cui lavoro per il per un 90% abbondante del tempo nel senso che l'azienda in cui lavoro e il team in cui lavoro come applicazioni che gestiamo ha un ecosistema di servizi iscritti appunto in Kotlin salvo poche altre cose però diciamo che siamo quello che si potrebbe definire un Kotlin shop, siamo un team che fa Kotlin Fantastico.Prima domanda brucia a pelo.Come si è arrivato a Kotlin? Qual è il percorso? Io ci sono arrivato da anni di Java.Io ho una lunga esperienza di Java.Sono stato un Java per la maggior parte della mia vita lavorativa, nel senso che salvo alcune rare deviazioni, alcune piacevoli, alcune meno.Non posso negare di essermi guarniato da vivere, come molti di noi scrivendo ZP, ma per il grasso del tempo sono stato un giavista.Che significa poi, negli ultimi anni, non solo scrivere Java, nel senso che ormai da una discreta quantità di tempo l'ecosistema Java è fatto di linguaggi anche diversi dal Java.Da quando il signor Scala, che tu conosci bene, ha avuto l'intuizione di avere un altro linguaggio che compilasse nell'assembler della Java Virtual Machine, hanno iniziato a nascere una serie di altri linguaggi che compilano sopra la Java Virtual Machine.Kotlin è uno di questi.Io ci sono arrivato in realtà perché, quando ho cambiato lavoro e sono arrivato al lavoro che faccio adesso, loro avevano già una serie di applicazioni scritte in Kotlin, per cui non è stata una mia scelta usare Kotlin, ma me lo sono trovato.Se posso ipotizzare i motivi alla base di questa scelta, che sono i motivi per cui poi la stessa scelta la rifarei io oggi, qualche anno fa probabilmente Kotlin era una cosa...beh, potrebbe essere un futuro interessante per la Java Virtual Machine, proviamolo e vediamo cosa succede.In questo momento Kotlin non è più, secondo me, una cosa futura, ma è assolutamente il presente dell'ecosistema Java.Ti faccio? Scusa, no.No, siccome ho studiato prima di questa puntata e mi sono preparato, c'è Nistorici, nel senso che Kotlin è un linguaggio assolutamente nuovo, se vuoi, la 1.0 del 2016.L'inizio del progetto Kotlin, che è un progetto che nasce da IntelliJ e Diget Brains, quindi, è del 2010, ma la 1.0 del 2016, che sono quattro anni e poco, dipende da come la guardi, nel senso che per alcune parti dell'industria informatica sono un'era geologica, per alcune parti, comunque per la stabilità di un linguaggio, l'adopzione di un linguaggio è veramente pochissima.Beh, se il tuo righello è Java, ai 4 anni sono pochissimi.Sono nulla.Però in questo lasso di tempo tutto sommato breve ha avuto degli endorsement non banali, Nel senso che qualche anno dopo la 1.0, anzi molto poco, nel 2017, Google ha annunciato che Kotlin aveva quello che loro chiamano "first class support", quindi che tu potevi scrivere applicazioni Android in Kotlin esattamente come le facevi in gioco.E questo magari poi è un tema su cui possiamo approfondire più tardi, quando abbiamo finito i cenni storici.Perché poi invece nel 2019, diciamo, il grosso boom è stato che sempre Google ha annunciato che Kotlin è la scelta principale, la prima scelta per scrivere applicazioni Kotlin ed è quella che loro stessi supportano su Android.Quindi la documentazione di Android, i talk dei developer advocate di Android e, diciamo, android sono in kotlin che però non è quello che ci faccio io.Io faccio tutt'altro in kotlin.Tu fai backhand no? Io faccio backhand in kotlin.Però facciamo un passo indietro.Ancora prima di parlare di kotlin mi piacerebbe con te provare a fermarmi un attimo su quella che è l'esperienza del passaggio da Java, tecnologia che è il linguaggio che è utilizzato per tanti anni, a Kotlin.Com'è stato, non tanto a livello tecnico di linguaggio, ma a livello visto dal professionista, questo passaggio di linguaggio? Allora, è una bellissima domanda.Anzitutto è importante dire, in questo caso, secondo me, che Kotlin non è il mio primo linguaggio non-Java sulla virtual machine.Nel senso che io, tre lavori fa ormai, ho lavorato per un anno in Groovy.Quella è veramente una cosa esoterica.Per cui diciamo che non solo ci arrivavo da già visto ormai esperto, nel senso che è la prima volta che ho scritto Java ormai sono quasi 15 anni fa, ma anche da esperto di linguaggi non Java sulla JVM.L'impatto però è stato fantastico.Anzitutto diciamo che l'ergonomia del linguaggio, proprio quando ti ci senti comodo quando quando ti ci siedi dentro è secondo me fantastica.In primo luogo perché puoi tranquillamente scrivere, diciamo scrivere Java in Kotlin se vuoi, perdonami la semplificazione, nel senso che al di là di qualche piccolo quirk di sintassi tipo il "non obbligatorio" o dettagli minori che comunque l'IDE stesso ti aiuta a gestire, nel senso che se tu copi del codice Java e lo incolli in una finestra di IntelliJ, lui ti dice "stai incollando del Java, vuoi che te lo converta in Kotlin?" e fa le semplificazioni di base del caso, quindi ti taglia il punto e virgola.Ma ti chiede se ne sei sicuro, vero? Ovviamente come ogni brava persona che si rispetti a domanda tu rispondi di te stesso.Quindi diciamo che non ti dà nessuna sensazione di spaisamento, di non capire cosa fare.Però, quindi di fatto io quando ho iniziato questo nuovo lavoro non ho avuto nessun problema di curva di apprendimento prima di diventare produttivo.Però a mano a mano, che invece un po' con i suggerimenti dell'IDE, che è molto molto efficace in questo nel suggerirti la forma più idiomatica e e più, diciamo, kotlin-ish per fare le cose.Un po', leggendo documentazione, il Gino Staccaro Florio, prendendo confidenza con il linguaggio, la sensazione è che veramente Kotlin sia come vorrei che fosse Java nel 2021.Ci sono tante cose piccole e grandi che un po' Java ha imparato a fare con dei tool on top nel corso degli anni e che invece adesso sono native del linguaggio.E un po' si vede che sono fatte da gente che ci ha lavorato per tanto e che ci ha sbattuto la testa per tanto e che invece adesso semplificano la vita.La più grossa e la più evidente è la questione del billion dollar mistake e della gestione dei null, che in Java è un tema colossale Ed è appunto...Il tizio di Sam stesso l'ha definito il "billion dollar mistake" perché è forse il problema principale di chi approccia Java che è quello che succede quando tu dichiari una variabile che è un riferimento a un oggetto, è quello che noi anziani chiamiamo un puntatore.Di fatto in Java tutte le variabili di tipi non punitivi sono puntatori e non le hai allocate alla memoria.Quindi per default le variabili in Java sono null.e le devi inizializzare e tutte le volte quindi quello che devi fare ogni volta che hai a che fare con una variabile in java è fare if variabile=null e farci cose altrimenti quello che succede è che la virtual machine tira un null pointer exception e quindi l'esecuzione del tuo programma si interrompe in kotlin le variabili per default sono non nulle e se una variabile è nullabile, lo devi dichiarare esplicitamente.Quindi quando tu dichiari una variabile, scrivi il nome della variabile e tipo.Se tu scrivi solo il nome della variabile e tipo, questa variabile sai che è non nulla, quindi la devi inizializzare quando la dichiari.Se la dichiari tipo punto di domanda, sai che è nullabile, ma lo fai esplicitamente.E questo risolve in buona parte il billion dollar mistake, nel senso che hai un bel po' di garanzie in più sul fatto che le tue variabili non siano nulle e quindi non devi scriverci di attorno, non devi cercare di circondnavigare le null pointer exception.Vero, hai parlato di tipi, ci sei passato tangente in questo argomento, però voglio per un attimo fermarmi.Oggi il panorama dei linguaggi è ricchissimo, il panorama dei linguaggi back-end è ancora più ricco.Abbiamo Python, JavaScript che fino a qualche anno fa non avremmo mai immaginato di portarlo nel back end.Forse sono vecchio io, ma comunque non ci avremmo mai pensato.Perché oggi davanti a questo ventaglio scegliere Kotlin e poi subito dopo, perché scegliere nel back-end un linguaggio staticamente tipizzato? Ti rispondo prima alla seconda domanda, nel senso perché un linguaggio staticamente tipizzato? Diciamo che quello che fa un type system statico e in generale anche un linguaggio compilato che ha interpretato è che ti fa emergere a monte una serie di bug che probabilmente vorresti che non emergessero a runtime, te ne accorgi prima.È limitante.Io mi ricordo quando ho lavorato in PHP, invece non ha il type system stretto, parlavo con un mio collega che era PHPista dalla nascita e mi diceva "Ma che noia questa cosa che fai tu in Java, che devi dichiarare il tipo delle variabili".Io nelle variabili ci voglio mettere quello che voglio, non devo dover dichiarare il tipo.Per cui è effettivamente un limite, è un constraint, niente di più e niente di meno.Nel senso che devi essere tu stretto come il type system nell'assegnare a ciascuna variabile esattamente quello che hai dichiarato che c'è in grazie.una variabile da dichiare come stringa e provi ad assegnarci un intero, il compilatore si rifiuta.Cosa che invece in JavaScript puoi fare, o puoi fare in PHP, puoi farla anche in Python, credo che è adaptive.Mentre in Kotlin o in Java, in un linguaggio staticamente tipizzato, non puoi.Per cui, ok, sei limitato in quello che puoi fare.Per come la vedo io, essere limitato in quello che puoi fare è non necessariamente una cosa negativa, anzi, nel senso che io per primo non sono perfetto e non scrivo sempre esattamente quello che ho in mente e quello che dovrebbe fare il codice.Se ho qualcuno che controlla quello che scrivo, che può essere il compilatore che mi dice "guarda che stai assegnando un intero a stringa", mi fa un favore.Per cui più che un limite io lo vedo come invece un controllo in una fase molto iniziale.Hai presente quel grafico che ti dice quanto costa ciascun errore a seconda di quanto tempo dopo averlo fatto lo scopri? Se tu assegni un valore a una variabile a cui non dovevi assegnarlo e te ne accorgi quando hai lasciato il codice in produzione, aggiustarlo costa una certa somma.Se te ne accorgi quando stai compilando il progetto sulla tua macchina e l'hai appena scritto, costa infinitamente meno.Per cui io sono appassionato dei type systems statici per questo motivo.Oltre a questo, cotlin, nello specifico, nella famiglia dei linguaggi staticamente tipizzati, comunque è piuttosto elastico, nel senso che si porta dietro una serie di innovazioni che io ho visto succedere negli anni, nel senso che se penso per esempio a Java 1.4, che non aveva le classi parametriche, non aveva le funzioni come First Class Citizen, quindi non aveva neanche per esempio il Lambda, o non potevi passare le funzioni all'oggetto, ma dovevi crearci una classe attorno apposta.Kotlin tutte queste cose le ha, per cui è staticamente tipizzato, ma ti permette anche di essere molto conciso e molto espressivo.Non ha quel problema che ha Java tipicamente, che per fare una cosa anche semplice ci vogliono 50 righe di codice.Perché devi incastrare quello che vuoi fare all'interno di un type system molto stretto e al contempo anche molto limitato.Per cui Kotlin i limiti di un type system statico ce li ha, ma anche molte feature che ti consentono di essere espressivo.Sì, io credo che al di là del fatto che sia un type system statico, di già il concetto di type system aiuti nel prendere consapevolezza degli elementi, quindi delle strutture di dati che trattiamo.Io ho sempre sviluppato con linguaggi di scripting, dal PHP al JavaScript, linguaggi che comunque fino a qualche anno fa il type system lo vedevano da molto lontano, no? E mi ricordo, o comunque fa parte di me, questa leggerezza nel trattare le strutture di dati e questo focus sulle operazioni, cioè tu sei più concentrato su quello che devi andare a fare che sui dati che stai trattando.Invece già con l'utilizzo di TypeScript esperienza personale, un po' questo mindset va a modificarsi per quanto il TypeScript sia una una costruzione, un castello di stecchini sopra il Java, su questo potremmo rimanere a parlarne per ore, però in realtà l'utilità è proprio quella, quella di prendere con consapevolezza dei dati che stanno passando da una parte all'altra.Prima abbiamo parlato di Kotlin sul back-end.Ad oggi quali sono le feature più fighe che ti hanno spinto a dire "sul back-end sì, Kotlin ci sta da dio"? Allora beh, te ne posso...quante settimane hai per parlarne? Dipende da quante birre ci sono.No, ce ne sono molte.Alcune sono assolutamente eye candy e non spostano poi tantissimo se non appunto un pochino di quell'ergonomia del linguaggio di cui parlavamo prima.Per esempio, la prima che mi viene in mente di questo tipo sono le data plus.Java ha un framework storicamente molto molto adottato che si chiama Lombok, che serve a ridurre in una grossa parte tutto il boilerplate che già lo sporta storicamente dietro.Per esempio, ti faccio un esempio per i non già visti, quando tu dichiari una proprietà di una classe, devi dichiarare anche la funzione che la getta e la funzione che la setta.Ed è una roba così veramente da scimmia, che l'idea te la genera di solito di solito, perché nessuno lo deve scrivere a mano, ma quello che fa Lombo, è che se tu annoti una classe con chioccio la data, te li genera automaticamente a compile time senza che debba scriverli tu.Ed è una roba che veramente ormai chi scrive Java non ne fa a meno.Kotlin questa cosa ce l'ha nativa del linguaggio, nel senso che tu puoi scrivere una classe come classe data e quello che hai è che hai gratis i getter e i setter delle proprietà, anche dei metodi di utilità che di solito, appunto, li ti fai autogenerare dall'Ide o dall'Homebook, come ad esempio il metodo Ipols e il SelfString.Per cui diciamo che in ambito back-end, o comunque in generale Kotlin, ti aiuta o si porta dietro l'esperienza di cose fatte on top a Java e le rende native del linguaggio.Però, oltre a questo, fa anche delle cose che Java fa, diciamo con margini di miglioramento, le fa in maniera molto semplice.Una cosa che Kotlin fa davvero bene è la programmazione asincrona.Kotlin ha le coroutines, che sono...la documentazione te le vende come dei thread lightweight, quindi dei thread leggeri, e in effetti, avendo lavorato in ambito Java con i thread che sono, come si dice, un paleo nel posto.Un pain point! Va bene, sono un pain point, grazie per il suggerimento.Avendo lavorato così invece le coroutines di Kotlin sono molto molto belle e sono veramente una cosa del 2021, nel senso che hanno delle strutture di controllo dei flussi asincroni molto moderne e molto efficaci, che sono anche, se vuoi, simili a quelle di linguaggi moderni come JavaScript, come Dolang, che fanno della programmazione asincrona un po' il loro cavallo di battaglia.Per cui, per esempio, Kotlin ha concetti come Flow e Channel, che sono molto simili a quelli di Dolang, in cui tu hai un oggetto che in maniera asincrona emette degli eventi a cui ti puoi registrare e a cui puoi rispondere.Fare la stessa cosa con i thread di Java è mezzo suicidio, invece in Kotlin questa cosa c'è la nativa del linguaggio.Per esempio, per quello che facciamo noi lato back-end, è una manna dal cielo, nel senso che ci capita spesso, per esempio, di ricevere una richiesta HTTP o un messaggio su Robin10Q in corrispondenza del quale devono partire diverse operazioni in contemporanea, anche piuttosto onerose, e poter gestire la weight di tutte queste operazioni o decidere di lanciarle in parallelo senza aspettare che completino e farlo in mezza riga nativa del linguaggio, senza dover usare una libreria, senza dover sbattersi a capire come puoi sincronizzare di nuovo tutto quello che hai lanciato in seguito, perché ti arriva gratis anche quella per noi è manna dal cielo.Ed è una cosa che funzioni così bene, lato backend è un po' un inside effect, nel senso che il motivo per cui Kotlin ha questa cosa è proprio perché ci arriva da Android, nel senso che nell'ecosistema Android gestire la programmazione asincrona è estremamente importante, perché se tu lanci un task computazionalmente molto intenso rischi di bloccare l'interfaccia del telefono, che è una cosa che la tua utente fa piuttosto schifo.Quindi poter lanciare delle operazioni asincrone ma mantenere sbloccato il thread dell'interfaccia grafica in quel contesto è estremamente importante e quindi è una cosa che Kotlin fa dalla 1.2, credo.Però come effetto collaterale a noi backendisti ha veramente tolto molte castagne dal fuoco.Assolutamente sì.Ti faccio ancora una domanda sulla parte riguardo il back-end, semplicemente perché mi incuriosisce.Abbiamo sempre detto, perlomeno io, che mi sono sempre tolti gli esami all'università di ambienti distribuiti.Io mi mi son tenuto sempre abbastanza alla larga da Java, non so perché, probabilmente un po' mi spaventava, ma si è sempre detto che la JVM è voracissima di risorse, questo può essere un luogo comune come può non esserlo.Ad oggi l'esosità delle risorse della GWM può essere una discriminante nell'utilizzo di questi tipi di linguaggio nel back end per i piccoli progetti? Allora ovviamente non posso risponderti dipende Nel senso che sì, è assolutamente vero ed è tuttora vero, anche se la situazione è molto migliorata che un'applicazione java che si tira dietro una virtual machine è molto più onerosa in termini di risorse proprio sulla macchina rispetto a un v8 che esegue node, rispetto a un python compilato in binario, rispetto a golang che compila in binario, assolutamente sì questo è, è inevitabile.La JVM ha fatto una quantità di strada colossale da quando ho iniziato a usarla io ed è molto meno onerosa di quanto fosse in passato e anche molto più semplice da tweakare, nel senso che ci sono alcune opzioni e anche alcuni sensible default, se vuoi, che la rendono molto più gestibile di quanto non fosse in passato.Per farti un esempio concreto, molti dei nostri servizi girano sul livello più basso possibile dei container che offre Roku, per cui comunque non hanno bisogno di macchine supercarrozzate per girare.Per cui è vero che potresti far fatica a far girare un'applicazione sulla JVM su un Raspberry Pi, probabilmente.L'ho visto succedere e ormai anche i Raspberry Pi comunque sono delle macchine discretamente carrozzate.Però sicuramente richiede più risorse, soprattutto in termini di RAM, di un node o di un'applicazione compilata in Google.È vero anche che a oggi, la questione della gestione dell'infrastruttura su cui girano le tue applicazioni è molto cambiata rispetto a 10 anni fa.questo problema è anche un po' meno sentito, nel senso che per me, quando è capitato che la mia applicazione andasse in auto-memory error perché la macchina su cui gira è troppo poco carnezzata per far girare una gialla del tool machine, quello che faccio è trascinare il cursore di Heroku sulla dimensione del container e prendere quello più grosso beh, pazienza.Lo pago un pochino di più, ma non è come se dovessi aprire il mio server e aggiungerci un banco di RAM a mano.Quindi dici i vantaggi nell'esperienza di programmazione sono maggiori rispetto al costo che ne hai nell'utilizzare altri linguaggi fondamentalmente.Assolutamente sì, poi sai io mi rendo conto che per il mio bagaglio storico e per la mia esperienza faccio fatica a essere 110% obiettivo.Io l'ho messo in chiaro fin dall'inizio, sono venuto a vista di lunga data e non so dirti quanto pesi la mia confidenza con l'ecosistema e con il linguaggio rispetto all'effettiva ergonomia dell'ecosistema.Non so dirti perché non sono nella posizione di dirtelo quanto mi ci trovi bene io perché ho la mia esperienza passata e quanto invece sia oggi, davvero molto più comodo di programmare il linguaggio sopra la J2M rispetto a un linguaggio senza la J2M.Ti faccio un'altra domanda sempre stando su Kotlin.Kotlin nasce per...adesso passamela, io non...Kotlin la prima volta che ne ho letto è per cercare di capire qualcosa prima di questa chiacchierata quindi veramente all'attivo minuti di lettura.Pensavo fosse perché c'è uno nel gruppo Telegram di BeatWalker che asciuga sempre tutti e dice che Kotlin è bellissimo.Anzi su quello sei abbastanza contenuto, dici solo che PHP è brutissimo, non dici che Kotlin è bellissimo.No, la mia domanda è...me la sono dimenticata...ah no, ok.Scherzo.La mia domanda è, di linguaggi sulla JVM ce ne sono diversi.C'è Scala, c'è Kotlin...e perché scegliere proprio Kotlin contro per esempio uno Scala della situazione? Infatti è una cosa che mi sono dimenticato di menzionare durante i cenni storici, nel senso che il motivo per cui il team di JetBrains ha messo in piedi il progetto Kotlin era non solo per avere un linguaggio bello, ma perché il compilatore di scala è lentissimo.Invece il compilatore di Kotlin ha dei tempi di compilazione assolutamente paragonabili a quelli del compilatore Java base, diciamo.Ed è una cosa che tra l'altro su cui il team di Kotlin punta tantissimo, nel senso che l'anno scorso è uscita la 1.4, che non è una major release, però non è neanche una super minor bug, quindi una release non banale.E il tempo di compilazione mi sembra che loro lo pubblicizzassero come broccato del 20%, una cosa così.Per cui loro puntano tantissimo sul tempo di compilazione che in effetti è, soprattutto per chi approccia magari l'ecosistema Java da un ambito di linguaggio interpretato e di scritting, è un grosso ostacolo iniziale.Tra quando io scrivo il codice e quando lo vedo eseguire passano...sai, se passano due secondi è ancora accettabile, se ne passano 20, 30, Io stesso, pur essendo un long term compiler, pur avendo esperienza di linguaggi compilati da un po', mi annoio in fretta.Soprattutto quando è molto difficile, mi rendo conto con lo scoglio di linguaggi compilati è che quando tu schiacci Ctrl+R dentro IntelliJ se devi aspettare 20 secondi e hai Facebook dietro l'angolo, il rischio è che perdi 3 ore o finisci in un tunnel di Wikipedia o vieni rapito dai preferiti di YouTube.Se invece il tempo di compilazione, comunque il tempo tra quando scrivi il codice, schiacci Ctrl+R quando lo vedi eseguire è sotto il secondo o sotto i due secondi già non riesci ad distrarti io metto di avere una soglie dell'attenzione estremamente bassa per me questo fa una differenza gigante.Guarda in un attimo sei riuscito ad accendere un flashback nella mia testa e di portarmi indietro, Bohdi forse 15 anni, quando scrivevo ActionScript e sviluppavo applicazioni flex ricordo che sviluppammo un'applicazione molto grossa ti parlo di enorme, 4 anni di sviluppo su flex quindi puoi immaginare all'inizio compilava che era bellissima calchi play, appariva sullo schermo dopo un paio d'anni questa questa questa cosa perché era difficile definirla non se ti ricordi Slimer, per me era un'impresa gigante.Questa cosa ci metteva diversi minuti, fino a 15 minuti a compilare.Io ricordo quanto poteva essere frustrante questo tipo di attesa, tanto che poi dei linguaggi interpretati non ne sono più uscito.Cioè io faccio qualcosa e ho una risposta in modalità live reload che mi appare subito e mi chiedo il fatto di usare dei linguaggi compilati in qualche modo inficia sulla produttività da questo punto di vista del feedback immediato o l'utilizzo dei tipi aiuta anche in quello? È una buonissima domanda perché appunto è un po' un compromesso nel senso che hai il panettaggio del type system statico e appunto di tutti i chat a compile time di cui parlavamo prima, questi chat ovviamente richiedono un tempo.Quel tempo lì quanto impatta sulla produttività è una domanda fantastica.Io credo che appunto lì sia tutta una questione di equilibrio e di quanto effettivamente è quel tempo.Secondo me Kotlin c'entra uno sweet spot abbastanza ben calibrato proprio per il fatto che compila molto in fretta e ti permette anche di costruire i tuoi progetti in modo che compilino molto in fretta.Ha un sistema di gestione dei moduli molto carino e molto ben fatto per cui puoi compilare solo la parte su cui effettivamente stai lavorando il tempo di compilazione molto molto molto rapido e quindi avere un feedback molto rapido.Oltre a questo tieni conto che è un linguaggio sviluppato da gente che di mestiere fa l'idea.Esatto, infatti era la domanda immediatamente successiva.L'integrazione con IntelliJ fa sì che, appunto, Ctrl+R dentro IntelliJ che ti lancia tipo con lo unit test della classe su cui stai lavorando è una roba veramente istantanea perché loro stessi il team di Kotlin stesso ha interesse che funzioni bene su IntelliJ e poi su Android Studio che è un forte di IntelliJ più o meno però è molto integrato con l'idea e questo fa sì che ci sia anche se vuoi anche un tema di ergonomia dello sviluppo molto forte nel senso che ok è vero che puoi o puoi ma non è consigliato usare un ID diverso da IntelliJ per sviluppare un co-op team, però se lo fai e non c'è niente di male funziona tutto molto bene, IntelliJ e co-op team sono veramente ben integrati.Una cosa che riesce a fare davvero JetBrains è quello di creare degli ID e degli ambiti sviluppo della Madonna.Io per anni ho utilizzato PHP Storm, ho ancora la licenza e lo utilizzo per scriverci il JavaScript.Ma credimi, mai una roba del genere, un'integrazione assurda.Io, che vengo dai tempi in cui si utilizzava Eclipse e devi girare la manovella, e insieme a Eclipse c'era Aptana, non so se qualcuno se lo ricorda, l'idea che praticamente trovavi facile con Ubuntu, con le prime ubuntu.Era un set di plug-in per eclipse.Esatto, però l'evoluzione è stata assurda e per quello che secondo me, visto da fuori, tutti gli sviluppatori kotlin raccontano kotlin quasi per dire io programmo sul divano.Nel senso questo comfort, questa questa ergonomia del linguaggio secondo me molto viene dall'esperienza che JetBrains è riuscita a portare nel linguaggio anche se te lo dicevo in vie private ho visto che non mancano i detrattori di Kotlin e tra l'altro sono davvero tanti io ho fatto la battuta sul gruppo telegram e tu mi hai risposto un po' alla git fighter e ci sono molti che parlano di inconsistenza nel linguaggio adesso c'è qualcuno che dice che un elemento che evidenzia questo tipo di inconsistenza è l'utilizzo di fun per definire le funzioni e della parola intera interface per definire le interfacce adesso questa può essere una provocazione però tu hai trovato dei lati negativi su Kotlin? Devo veramente spremermi le meningi su questa cosa e faccio un po' fatica.Il motivo banalmente per cui credo che usi Fun per le funzioni e Interface intero per le interfacce è perché Int è un titolo, quindi non puoi usarlo per le interfacce.È molto semplice.Però no, se devo pensare a dei pain point specifici del linguaggio che mi vengono in mente, sono tutti legati al suo essere ancora molto giovane e ancora molto in evoluzione.L'unica cosa su cui ho sofferto un pochino di recente è che dalla 1.3 alla 1.4 sono cambiati alcuni comportamenti interni, nemmeno troppo banali e in modo non retrocompatibile.Per cui io tra le altre cose entrei a fare il mio lavoro quotidiano di defender sono anche nel tenore di una libreria di risorse scritta in kotlin con un'adoption anche piuttosto grossa e a un certo punto una delle cose che ho fatto è stata compilarla con kotlin 1.4 anziché con kotlin 1.3 e il giorno dopo che ho rilasciato questa cosa ho ricevuto una serie grossa di suspitab di gente impizzarrita che aveva ancora la 1.3 su cui aveva errori di compilazione o errori runtime disparati perché alcune cose della 1.4 non sono compatibili con la 1.3.Quindi questa cosa è stata un po' dolorosa.Alla fine quello che è successo è stato che l'ho ricompilata con la 1.3, l'ho rilasciata così e ho rilanciato l'upgrade alla 1.4 per adesso perché è un linguaggio molto giovane con alcune feature e alcune classic core della libreria standard che ancora non sono troppo stabili.Detto questo, puoi vederla anche come una cosa positiva, nel senso che uno degli ambiti del linguaggio che è in evoluzione più rapida, che è proprio quello della programmazione asincrona e del coroutine, Non ti dico che migliora di settimana in settimana, ma già nell'anno e mezzo di esperienza che ho io con l'ecosistema Kotlin è migliorato sensibilmente.Per cui credo che il problema di avere fun per le funzioni e non int per le interfacce non si risolverà mai.Però sono ragionevolmente convinto che molti di quelli che i detrattori vedono come pain in questo momento, se sono effettivamente dei pin point e se sono anche molto sentiti dalla comunità di sviluppatori, verranno, come dice in italiano, "addressati" prima di possibile.Una cosa, tra l'altro, che a me piace molto di Kotlin come ecosistema e che si lega un po' a questa cosa che ti ho appena detto, è che Kotlin è un linguaggio con molta faccia.Molte persone del team di Kotlin ci mettono la faccia e fanno advocacy del linguaggio.C'è questo personaggio che è stato il team lead, il "signor Kotlin", fai conto, il Guido Van Rossum di Kotlin, fino a poco tempo fa, che si chiama Roman Elisarov, che è molto molto bravo e ha cambiato ruolo da poco, ma lui per anni, dall'inizio del progetto è stato la faccia di Kotlin e ha fatto advocacy e evangelismo del linguaggio per un bel po' ed è davvero bravissimo.Oltre a essere il signor Kotlin, quindi il dominus e il benevolent dictator di Kotlin, per un po' è molto bravo anche sul fronte comunicativo e sul fronte dell'evangelizzazione del linguaggio.E questa cosa vale non solo lui ma per tante persone che veramente ci mettono la faccia sui progetti Kotlin-based.Questa cosa secondo me è molto positiva, nel senso che ti dà l'idea del fatto che ci sono persone che usano Kotlin, ci sono persone che quando hai un pain point magari ci mandano anche loro, ci sono passate e l'hanno risolto in qualche modo.Per dirti, Kotlin è l'unico linguaggio di cui ho l'esperienza recente che ha uno slap del linguaggio.Cioè, uno slap di Kotlin in cui il team di JetBrains è molto attivo, Roma e Lizzarop stesso sono molto attivi e loro fanno addirittura attività proattive, nel senso che mi è capitato, in qualità di maintainer di una libreria open source in Kotlin, che un tizio di JetBrains mi scrivesse su Slack dicendo "guarda, abbiamo rilasciato una versione nuova di Kotlin.js, quando pensi di aggiornare, come posso aiutarti? Hai bisogno di supporto da parte nostra come JetBrains?" Quindi diciamo che non solo ci mettono tanto la faccia, ma sono molto molto d'aiuto.Questa cosa io in altre linguaggi non l'ho vista.E se lo paragoni all'ecosistema Java è quasi l'opposto.Anche credo che questa disponibilità un po' venga dal fatto che Kotlin è abbastanza giovane quindi abbia necessariamente bisogno di questo push, di questa presenza che un po' fa da garante per chi vuole introdurlo nel proprio stack.Anche perché Kotlin deve emergere in un ecosistema della Java Virtual Machine dove altri linguaggi hanno ecosistemi a loro volta è enorme, parlo di framework, di librerie, di tool di sviluppo.Come si pone Kotlin in questo ecosistema? Cioè ha il suo ecosistema, il suo ecosistema si sta sviluppando, può attingere dall'ecosistema dei cuginoni e dei cuginetti? È una domanda fantastica, perché la risposta è sì a entrambe le cose.Nel senso che Kotlin, a differenza di alcuni altri linguaggi sulla JVM, è completamente interoperabile con Java.Per cui, per farti un esempio concreto, le applicazioni su cui lavoriamo noi sono applicazioni che usano Spring e Spring Boot, che è, diciamo, il framework Java, se vuoi.un bacignone, ha una quantità di anni di vita e probabilmente se sommi tutti gli anni di sviluppo che ci hanno messo assieme, gli anni uomo che ci stanno dietro, è credo più della storia dell'umanità.Fa tutto, fa un sacco di cose, però veramente si porta dietro una quantità di esperienza, di documentazione già scritta, di problemi già risolti giganti.per cui tu da Kotlin puoi usare tutte queste cose e puoi avvantaggiarti del dolore dei sviluppatori prima di te.Però ci sono anche un buon quantitativo di librerie, di framework, di tool, diciamo, nativi di Kotlin.L'equivalente Kotlin nativo di Spring si chiama Ktor, è un framework di dependency injection e fa più o meno tutto alla Spring quindi ti fa fare le applicazioni web, ti fa fare le applicazioni backend e quant'altro ma è Kotlin nativo quindi è un pochino più idiomatico ovviamente non ha anni di esperienza di Spring alle spalle ma se vuoi puoi usarlo e funziona molto bene La stessa cosa succede ad esempio con un tema che mi è caro, le libreie di Mocking.Tu puoi usare Mockito o PowerMock, che sono assolutamente standard in ambito Java, oppure puoi usare Mockplay, che è la libreia che mantengo io.- Che mettiamo nelle note dell'episodio, tra l'altro.- Esatto.Non ho scritto io, perché la scritta è in buona parte un altro tizio, ma io sono diventato un po' un era posteriore.però è di fatto il framework di mocking standard di Kotlin.Per cui è vero che puoi usare Mockito, ma Mockkey è estremamente Kotlin idiomatico.Sembra che faccia promozione, ma a me piace un sacco.Secondo me è un framework di mocking stupendo.Non perché lo mantengo io, ovviamente.Per cui, diciamo che scrivendo Kotlin hai un po' i vantaggi di ombra delle cose.Hai, se vuoi, puoi avvantaggiarti di tutto quello che è stato scritto in 30 anni di Java.Per esempio, a noi è capitato di usare le librerie di Apache Commons.Usiamo Retrofit per fare le richieste HTTP.Usiamo diverse librerie Java che puoi tranquillamente usare da Kotlin, ma ci sono altrettante librerie Kotlin native che fanno la stessa cosa o meglio in maniera più corto di idiomatica.C'è una molto bella per esempio che si chiama Arrow che è un layer funzionale on top a Kotlin.- Me ne avevi parlato nel gruppo Telegram, se non ricordo male.- È davvero molto bella perché ti permette proprio di fare...ti trasforma, se vuoi, Kotlin in un linguaggio funzionale.Kotlin, tra l'altro, molto più di Java si presta a questa cosa, nel senso che, a differenza di Java, ti permette di scrivere funzioni...diciamo, first class, al di fuori di una classe, per cui non hai bisogno di avere tutto il...come si dice...l'overhead, di avere delle classi per poter scrivere funzionale.Di fatto quando scrivi funzionale in Java ti sembra sempre un po' di incastrare, sai, un cubo dentro un buco quadrato, no? - Vero.- No, dentro un buco tondo, scusami.- Verissimo.- Cioè, di fare...di usare tipo un cacciavite per piantare un chiodo, una roba così.- Vero, vero, vero.Io ricordo...di scrivere oggetto rientri in php.Che cattivo che sei, non lo reggi proprio.Prima o poi ti farò fare un git fighter con Rasmus Lerdo.In cui io difendo php e lui dice che è sbagliato.Ma sai l'ultima volta che ha fatto una dichiarazione su php cosa ha detto? Bellissima, l'ho già detto detto in uno degli episodi di Gitbar ha detto una cosa splendida ha detto PHP è migliorato tantissimo da quando io ho smesso di scrivere codice.Ah sì sì mi ricordo che l'avevi scritto nel gruppo Telegram.E' bellissimo una frase che il creatore di un linguaggio racconta la presa di consapevolezza del creatore di un linguaggio ed è filosoficamente altissima.Detto questo è fatta questa parentesi sul php voglio ritornare per un attimo a farti un'altra domanda rimanendo sempre sul sul kotlin cosa pensi di questo ragionamento magari io mi sbaglio kotlin è un linguaggio molto giovane questo vuol dire che nel mondo open source ci sono ancora tanti spazi Costruire una carriera nell'open source usando Kotlin può essere un'opportunità, cioè mi spiego meglio, di spazi per scrivere una libreria di open source, una libreria open source figa in Java non ce n'è più tantissimi ormai è abbastanza saturo.In Kotlin che spazio ha un programmatore, passatemi il termine, cazzuto, abbastanza bravo che si dedica il tempo per creare qualcosa per quell'ecosistema? Secondo me c'è, allora, anzitutto c'è sicuramente molto spazio, nel senso che appunto come hai detto giustamente tu, è un ecosistema molto meno saturo.Oltre a questo io credo che sia probabilmente una buona idea per un programmatore che vuole acquisire più skill e anche se vuoi più status, nel senso che è inutile che che ce lo neghiamo essere ma intendo di una libreria open source piuttosto usata, ti dà un po' di status, ti dà un po' di reputazione.Se un programmatore è cazzuto, come dici tu, vuole acquisire più skill, vuole più skill non solo tecniche ma anche tutte quelle skill che acquisisci quando hai a che fare con un progetto open source.Gente che ti punta le pistole e la gente che ti spare, esatto, gente che ti vuole aspettare sotto casa, quasi così, ma anche, sai, avere a che fare con progetti con source ti costringe a scrivere il miglior codice possibile, ti aiuta a farlo, ma ti aiuta anche molto e ti costringe a imparare a gestire le priorità.Io Io sono ok in questo momento, ho cento e passa i shoe aperti.Decidere su quali lavorare per primi è veramente un balancing act, perché ce ne sono alcuni che sono semplici per me e magari hanno meno impatto, ce ne sono alcuni per cui devo studiare tre giorni per capire cosa succede, ma magari migliora la vita di diverse persone, ce ne sono alcuni che costano poco e hanno grosso impatto, ce ne sono alcuni che costano tantissimo in termini di tempo che ci devo mettere e hanno poco impatto e impari a fare questo tipo di valutazioni, che secondo me è una skill che poi serve tantissimo anche in altri contesti.Per cui Diciamo che costruirsi una carriera nell'open source in Kotlin, secondo me, è una buona idea.Anche perché è vero che è un linguaggio giovane, ma non penso che sia un linguaggio senza sbocchi.Per dirti, io, come ti dicevo prima, ho lavorato in Ruby, che è un po' dietro, e lì invece ho avuto la sensazione di dire "sto finello un po' in un pull the sack".Nel senso che l'adoption del linguaggio è in talo.le skill che usi non te le ricicli poi più di tanto altrove e ok, lì forse non è una buonissima idea.È un tema che tra l'altro per me è importante nel senso che in questo momento noi come azienda stiamo facendo hiring e stiamo cercando persone e c'è un tema di dire "sì, però usare Kotlin ci frena un po' al trovare persone" Forse sì, ma secondo me no.Nel senso che, appunto, come ci siamo detti prima, se hai una conoscenza di Java e dell'ecosistema Java, Kotlin lo impari in un quarto d'ora.Per cui, diciamo che non è vero che ti perdi tutti i già visti.Anzi, il fatto che siano così interoperabili e così semplici da integrare, fa sì che tante antiaziende, diciamo, sai, in Java spesso le usano aziende un po' falludate, un po' enterprise, però molte aziende di questo tipo stanno iniziando a scrivere parti di applicazioni in Kotlin, che è una cosa che puoi fare, puoi avere il tuo monolithe che sta lì da 15 anni, ma ci puoi aggiungere delle feature in Kotlin quasi gratis.Oltre a questo, Kotlin è un linguaggio con molti svuoti, nel senso che abbiamo citato Android e Backend, che sono due cose che puoi fare con Kotlin.Ma una cosa molto figa che si può fare in Kotlin è compilare Kotlin in JavaScript, quindi fare il frontend web o i backend o stati su Node scritti in Kotlin, e anche le applicazioni native.È una roba relativamente recente, è ancora in alpha, ma Kotlin native è molto bello, una roba per cui tu compili un'applicazione Kotlin e il compilato gira, è un binario che non ha bisogno della java che puoi uscire.Loro te lo spacciano, il team di Kotlin te lo spaccia come un tool in cui tu puoi scrivere almeno la business logic una volta sola e farci le applicazioni Android e le applicazioni iOS, perché tra i target del compilatore di Kotlin/Latex c'è anche iOS, oltre a Intel, MbE, e taltro.Per cui di fatto è, per come la vedo io, Kotlin oltre ad essere un linguaggio con ampi spazi di virginità e spazi dove potersi inserire, come dici giustamente tu, è un linguaggio anche con molti sbocchi.Non è un linguaggio in cui ti trovi la tua nicchia ma poi non ne esci mai più.È un linguaggio in cui, secondo me, è un ecosistema in cui se per caso sbagli nicchia comunque hai acquisito le skin per riuscire a utilizzarla.Guarda non ti nascondo che questi giorni ho buttato un po' l'occhio qua e là e ho visto che come dicevi tu alla fine puoi mettere come target di compilazione anche il web.Io non ti nascondo che come ho letto quelle righe per un attimo mi sono tornate alla mente le applet e ha risvegliato un passato abbastanza attormentato credimi qui non viene fuori che siamo due anziani esatto però per un attimo ho avuto avuto paura quindi mi rassicuri sul fatto che kotlin sul web non sono le applet no no no no compila in javascript La cosa figa di Kotlin Native e di Kotlin JavaScript è che è fatto in modo che il compilato non ha quel layer intermedio, quindi non sono le applet.Ti faccio un'altra domanda, visto che ci stiamo avvicinando al ragionamento sul multiplattafono e poi voglio fare un passaggino su Android che è sicuramente molto interessante.si può parlare di Kotlin senza necessariamente parlare di Android.Io in questa chiacchierata ho cercato di spingerti di più a parlare del back end perché la parte meno coperta probabilmente.E' anche quella che conosco meglio.Si ma capisci che ha meno hype parlare di back end con Kotlin rispetto e quindi per noi è importante anche andare a prendere quella parte della tua esperienza e condividerla perché del resto se ne legge ovunque.Però quello che volevo chiederti è oggi, oggi è giovedì quindi ci state ascoltando con una settimana di ritardo, è uscita la puntata di France dove si ragionava sul numero di astrazioni sopra la quale lo sviluppatore è seduto.Tra l'altro andando a spulciare un po' gli attacchi che si fa a Kotlin, uno degli attacchi è che si siede su una montagna di astrazioni.Come vedi questa cosa? E' vero, è vero che tra il codice Quarking che scrivi e il processore che lo esegue ci sono diversi livelli ed è in effetti anche un livello in più rispetto a Java.Questa cosa è assolutamente innegabile ma per come la vedo io è innegabile anche che sia una cosa positiva, nel senso che adesso mi metto il cappello del Geet Fighter e uso degli argomenti forti...Lo sapevo che ti avrei triggerato! Ma è vero che oggi, giovedì 4 febbraio 2021, nessuno di noi, per fortuna, per scrivere le applicazioni web scrive in Send.È vero che nessuno di noi ha bisogno, in gran parte dei casi di scrivere in C.Quando noi scriviamo un pezzo di codice che risponde a una richiesta HTTP, quello che stiamo usando sono delle astrazioni, nel senso che non dobbiamo stare a capire come funziona il socket, su quale porta è stato aperto e tutti e sette i livelli della pila ISO-OSI, a noi interessa sapere che c'è un'applicazione a cui arrivano dei dati.Questo payload noi lo leggiamo come una stringa e ritorniamo una stringa dalla nostra funzione e poi questa stringa riattraverserà i 7 livelli della pila ISO-OSI.Ci saranno dei bit che passano dal cavo Ethernet o dalla rete Wi-Fi e non ci interessa sapere come fanno a farlo.Arriveranno al client a a cui abbiamo restituito la risposta.Il client farà il parse della risposta HTTP, eventualmente se abbiamo mandato del JSON ci sarà del Java.Ma a noi questa cosa non interessa.Le astrazioni sono una cosa bella, perché ti permettono appunto di concentrarti sui dettagli che ti interessano, su quello che fa effettivamente la tua applicazione.Nel 2021, che un'applicazione web risponda sulla porta 80, è una cosa che ci arriva gratis e non dobbiamo stare a pensare a come farle.È vero che ci sono i casi in cui si rompe e forse devi guardarci dentro e sapere come funziona la quantità di ti torna utile.Sì, questi casi sono una percentuale molto ridotta del lavoro che fa tutti i giorni ognuno di noi.Tra l'altro, la cosa bella del fatto che Kotlin sia effettivamente un layer di astrazione in più sopra la Java Virtual Machine è che Kotlin di fatto ha sganciato l'evoluzione del linguaggio, le feature del linguaggio, dall'evoluzione della Virtual Machine.Java e la JVM sono sempre stati molto, molto legati tra loro.Quindi quando usciva una versione nuova del linguaggio, usciva una versione nuova della Virtual Machine.Kotlin tu puoi compilarlo per il JDPI 11, 13, 15, 8 e funziona esattamente allo stesso modo per cui quando esce una versione nuova della virtual machine che magari ha delle utilizzazioni di performance anche grosse questa cosa non ha nessun impatto e nessun rischio sul tuo linguaggio perché hai aggiunto un layer di astrazione in più che fa sì che tu di questa cosa ti possa avere un po' di disinteressare E ti prenda le evoluzioni dei layer sottostanti gratis Assolutamente messaggio ricevuto immagino sia arrivato anche a franz che a questo punto io credo invitiamo invitiamo a un kit fighter esatto dove mattia sosterrà la parte esattamente Opposta di quello che ha appena detto e franz sosterrà il fatto che le astrazioni e viva più ce n'è meglio è scherzo su questo.Intanto che ho fatto un Geekfighter a sincrono.Infatti tra l'altro probabilmente ho anche travisato un po' la posizione di Franz.Io ammetto che la puntata di oggi non l'ho ancora sentita.Ti divertirai, è stato grandioso.Lo risalutiamo con con tanto affetto.Spostiamoci, torniamo anzi nel tuo vecchio posto di lavoro.Ritorniamo a Google.Google è stato un player importantissimo per Kotlin perché ha fatto un gioco di carte tale per cui ha abbracciato...a me piace immaginarlo così...Google stava con una donna sulla quarantina...che bella assolutamente...però poi cosa succede? Questa donna sulla quarantina aveva un problema la suocera ora col si cosa succede quando la suocera diventa troppo pressante e la donna comunque inizia ad avere un'età google scarica la l'ex moglie e si diciamo trova la nuova bellissima ragazza molto giovane nel frattempo l'ex moglie come tutte le ex mogli si cura di più, si evolve, diventa molto più carina di quello che era però adesso google abbraccia questa ragazza giovanissima.Facendo questo tipo d'azione io credo che il linguaggio ha avuto un boost allucinante perché un endorsement di questo tipo dà un boost al linguaggio quindi ti chiedo se conosci qualche retroscena o se puoi darci qualche informazione un po' da chiacchiera da bar come piace a noi su questo fidanzamento.E poi cosa in realtà Kotlin ha portato nell'ecosistema Android? Ma allora purtroppo di retroscena non ne conosco nonostante effettivamente la notizia di Kotlin come scelta privilegiata per le applicazioni Android sia del periodo in cui io lavoravo in Google.Io ero un developer advocate per un'altra cosa e i developer advocate di Quaframe erano seduti letteralmente dietro di me.Per cui sono stato vicino a loro anche fisicamente.Però credo appunto che il retroscena effettivo sia un po' come l'hai raccontato tu, nel Nel senso che Google ha voluto sganciarsi da Oracle.Banalmente perché in termini di peso specifico dell'azienda credo che Google possa impattare molto più facilmente sulle scelte di JetBrains che di quelle di Oracle.Con tutto il bene che possono volere JetBrains, credo che siano in termini di peso un po' più leggeri di Oracle.e quindi un po' più facili per Google in terreno di trattativa.Però, detto questo, diciamo che Google all'epoca, ma tuttora, ci crede tantissimo in Kotlin, non solo per questioni aziendali e politiche, se vuoi, ma proprio perché davvero la sensazione che avevo io che ho attualmente dall'esterno, è che secondo Google sia una buona idea oggi scrivere applicazioni Android o scrivere Java in Kotlin.Per cui io da sviluppatore è vero che decido con il mio gusto personale e a me a Kotlin mi piace e credo che sia una buona scelta.Però, come hai detto tu giustamente, l'endorsement di un player grosso come Google fa.Con tutto che Google ha una storia piuttosto lunga di endorsement dati e poi tolti, nel senso che ci sono stati diversi framework e diversi linguaggi interni di Google o endorsed by Google, che poi sono spariti nel nulla.tipo a Google Dove Toolkit, che era onestamente una mezza borcheria.Era una cosa per cui si scrivevano le applicazioni web frontend in Java e che compilava in JavaScript inguardabile, super offuscato, con cui Google faceva tutti i suoi tool interni all'epoca e che appunto indorsavano a missile e poi hanno...Ho trovato questo risultato su wikipedia.Ho detto Google tante volte e il mio telefono ha reagito.No, però appunto diciamo che l'indorsement di un'azienda come Google con tutta la storia dell'indorsement di Google comunque fa.Credo proprio di sì.La cosa che però in realtà non mi spiego è che Google non è la Jacobelli SRL che fa il gestionale che usano due aziende, cioè Google ha anche una certa esperienza nel creare linguaggi di programmazione.Guardate un Dart.Perché ha abbracciato Kotlin piuttosto che andare a creare qualcosa in casa? È una buona domanda, nel senso che appunto Dart che tu hai citato per certi versi ha molto spazio di sovrapposizione con Kotlin e Kotlin Native, nel senso che Flutter si propone esattamente la stessa cosa di scrivere le applicazioni mobile una volta sola e compilarle per Android e iOS.Credo che il ragionamento che ha fatto Google sia proprio una questione di bilanciare un linguaggio integrato con un'idea che Google già usava e supportava per Android, perché Android Studio, che è l'editor di default di Android, è comunque intelligente e rischianato.E quindi con una base di adoption un po' più grossa di quanto potessi avere ad Artifex.Credo che, cercando un po' di mettermi nei panni del signor Google che ha fatto questa scelta di indorsare Kotlin, credo che sia stato perché rispetto a crearsi un linguaggio nuovo non si partiva da zero.Nel senso che hai già un'idea di riferimento, hai già con cui il linguaggio si integra molto bene, hai già il supporto dell'azienda che lo fa a Lidl, per cui diciamo che hai una mezza garanzia che l'evoluzione del linguaggio sarà seguita da Lidl.Hai già della gente che lo usa, nel senso che è un linguaggio che non si è inventato da zero.è vero che è molto giovane, però qualcuno che usava Kotlin prima dell'indossamento di Google sicuramente già c'era.Quindi credo che sia per quello e poi obiettivamente credo che costi anche meno, nel senso che il team di Kotlin non è un team di Google.Quindi al di là dei developer advocate, la gente che materialmente scrive il compilatore, scrive le specifiche del linguaggio, le tale intelligenti.tra la gente che scrive da arte.Ma una domanda, non hanno fatto un consorzio per il sviluppo? Sì c'è un consorzio, però credo che Google sia minoritaria rispetto a JetBrains, nel senso che a oggi credo che comunque la maggior parte dell'ownership del progetto Kotlin sia ancora in mano a JetBrains.Interessante, interessante anche perché JetBrains tra l'altro manteneva, se non ricordo male, mantiene anche uno dei maintainer di PHP che è Nikita Popov.Prima al soldo di Zend, non vorrei dire fesserie, potrei sbagliarmi quindi mi raccomando se dico qualcosa di non corretto lanciatemi la scarpa nel gruppo telegram però se non sbaglio è JetBrains che paga Nikita Popov.Interessante anche perché JetBrains ha ritagliato tra uno e l'altro progetto davvero una posizione importante nel panorama dello sviluppo.Credimi non immaginavo in tutto sommato non tantissimi anni perché quanto va 15 anni 20 anni di operatività arrivasse a assumere quella posizione.Cioè detto con tanta chiarezza io non mi immaginavo che uno sviluppatore pagasse un abbonamento per usare un IDE invece sono oggi il primo che lo fa.Io ogni anno pago l'abbonamento.Io ho la whole products di JetBrains mi fa piacere.Si, ti volevo...Tra l'altro i prodotti costano in effetti molto poco, quella di un prodotto.Io pago mi sa 130 euro qualcosa del genere.160 per tutto, perché quando la rinnovi costa meno.Sì sì, ma anche io la sto rinnovando tanto di anno.il rinnovo quest'anno.Tra l'altro hanno il sistema delle licenze molto interessante perché dopo tre anni se non sbaglio è la perpetua della versione di tre anni prima.E' comunque interessante perché comunque hai un fallback nel momento in cui dici non mi interessa più rinnovarla.Anche se...Sì, qui hanno anche le community edition dell'IDEA, anche se non sono dei rottavi, comunque la versione free dell'IDEA non la userei per il lavoro di tutti i giorni, però diciamo che se tu dici "voglio provare un linguaggio scarico alla community dell'IDEA", tra l'altro loro hanno ideatamente tutti i linguaggi del mondo, funziona, fa.Sì, io naturalmente devo fare il bastian contrario come sempre.I sottovoce, non posso dirvi il nome della compagnia, ma immaginate una multinazionale se non grande come Google quasi, che in realtà fa usare agli sviluppatori la community edition dell'IDE di IntelliJ.naturalmente non dirò il nome ma significa che la community funziona bene esatto giusto per così.Beh io credo che abbiamo un po' tolto un po' di dubbio dialone di mistero dietro questo questo linguaggio quindi l'ultima domanda sempre rimanendo in mondo nel mondo multi platform cross platform in un un Geat Fighter tra Kotlin e Flutter.Chi vedi vincere e perché? Allora è un Geat Fighter in cui farei molta fatica perché a me Dart piace tantissimo come linguaggio.Non lo seguo da tanto ma quando scrivevo JavaScript per non andarmi da vivere ho iniziato a guardare Dart e mi piaceva molto.Mi sembrava un linguaggio molto molto bello.Il problema è che adesso veramente però non lo usa nessuno.Ha un adoption molto bassa e non ha nessun endorsement se non quello di Google, che tra l'altro per le applicazioni mobili endorsa anche Kotlin.Quindi diciamo che a livello di endorsement grossi sono alla pari.A livello di adoption vince Kotlin, a livello di gusto personale conosco meglio Kotlin e mi trovo molto bene.Vince Kotlin anche lì.A livello di versatilità, vince Kotlin, per quello che ci dicevamo prima, nel senso che se io inizio a farne una parriera in ambito multiplattaforma su Kotlin e poi a un certo punto voglio fare il detentista e poi a un certo punto voglio fare il data scientist, è una cosa relativamente recente, ma Kotlin sta spingendo molto anche sotto il fronte lì, è uscito un framework di deep learning che si chiama Kotlin DL, è praticamente un porting di Keras fatto in Kotlin.È uscita di recente l'integrazione con Jupyter Notebook, per cui tu puoi scrivere i Jupyter Notebook in Kotlin anziché in Python, e stanno cercando un po' di, diciamo, di scalfire il dominio di Python in quella lecchia lì.Per cui, se uno impara Kotlin, diciamo che ha molti sbocchi in questo momento.Flutter, per quanto mi piaccia tantissimo il linguaggio, mi piacciono tantissimo i colori del logo, quindi quelli di Kotlin.Adesso ho paura che si inizia a diventare un po' un...un recinto che tende a chiudersi.Poi, non lo so......Kotlin è un bellissimo prato fiorito.Io Flutter mi sono sempre riproposto di provarlo, di provare a sviluppare in Dart, ma quando metti troppe cose nello stack poi diventa faticoso andare a togliere gli elementi.Sul tema delle applicazioni multiplattaforma anche qua viene fuori l'anziano che è in me.Io ho avuto esperienze davvero negative in passato con Apache Cordova e Ionic che erano delle cose terribili.Erano delle cose che ci mettevi tre giorni a compilare l'applicazione e il compilato era una roba che tipo tu schiacciavi l'icona sul telefono, poi appoggiavi il telefono, andavi a farti un giro e quando tornavi forse l'applicazione si era aperta.Io Ionic e Cordova o Capacitor, oggi li uso alle volte fino a qualche mese fa, li usavo anche per procacciare il cibo e quindi so benissimo quello quello che che stai dicendo lo so tra l'altro sempre sul mondo mobile ci tengo a citare questa cosa la metto nelle note dell'episodio che in realtà se non ho letto male pare che netflix stia portando le applicazioni mobile loro parlano di studio apps su kotlin sia l'applicazione iOS che è l'applicazione Android proprio utilizzando quell'approccio multiplatform.Ho un link, non l'ho letto benissimo l'articolo perché mi è capitato in mano pochi minuti prima di partire con la registrazione del podcast quindi ho letto solo il titolo che dice Netflix Android and iOS studio app scottlin multiplatform.Sì sì ho googlato Netflix scottlin al volo e il primo risultato è esattamente quel post lì.Io non l'ho letto benissimo, cioè ci ho giusto buttato un occhio perché non ho avuto il tempo, però se così fosse a maggior ragione è interessante.Sarebbe anche quello un endorsement normale.Anche perché oggi l'impegno in termini di tecnologia che netflix sta spendendo è importante.Stiamo parlando comunque di una società che in questi ultimi periodi è diventata uno dei pillar dell'entertainment, anzi posso dire il pillar dell'entertainment voi per colpa di questa pandemia globale che ci vede un po' però...Si, è anche però comunque molto allo stato dell'arte della tecnologia, nel senso che mi aspetto che quello che fa adesso Netflix la coda lunga del grosso degli sviluppatori lo farà dopo.E quindi il fatto che loro abbiano fatto e che decisano questa scelta è grosso.Fantastico Mattia, tu mi hai salvato dicendomi che Kotlin non reintrodurrà le applet, io credo di essere davvero un uomo un uomo migliore e comunque più sereno più sereno.Io pure dormo molto più sereno, ho più le afflets nella mia vita.Eh sì, assolutamente sì, ma tanto torneranno, torneranno io ne sono sicuro, è tutto ciclico.Detto questo ti faccio l'ultima domanda prima di chiudere perché ho visto che siamo andati lunghissimi.Se io ti dovessi chiedere qual è dal tuo punto di vista il learning path migliore per avvicinarsi a Kotlin da non già vista? Ok, allora...Kotlin ha anzitutto una documentazione molto bella, molto ben fatta.La documentazione su kotlinlang.org è davvero ben fatta sia in termini di reference del linguaggio e di quelle di classi della standard library, di sapere come si fanno le cose, ma anche in termini di guida introduttiva.Quindi quello secondo me è il primo punto un po' per farci un'idea.Un tool che io ho trovato molto utile nel mio periodo di apprendimento e all'interno di IntelliJ c'è una REPL, quindi il Redevelopment Loop, e una Shell in cui tu puoi scrivere i codi e eseguirli al volo quindi diciamo che ti aiuta molto a prendere confidenza col linguaggio scrivendo piccoli snippet di codice per vedere come si fanno le cose è un po' se vuoi l'equivalente di imparare javascript nella console del browser ho la sandbox che aveva messo Go che mi ricordo era fantastico, è stata game changer proprio si si si si e poi detto questo adesso faccio un po' di shameless self promotion in modo migliore per imparare un linguaggio e metterci le mani a scrivere del codice e c'è un progetto open source molto bello che ha molti issu aperti e che avrebbe bisogno di una mano.Quindi armiamoci e partite perché io...C'è tra l'altro il maintainer che è molto bravo, ma anche molto simpatico e molto bello.Ha tagliato un po' di issu come "good first issue" quindi è molto semplice diventare nuovi contributori.Quindi mi raccomando se vi interessa esplorare il mondo di Kotlin questo è il learning path che Mattia ci propone.Mattia io ti devo ringraziare.Tu hai dato un po' di elementi per il learning path ma tu sai che anche il podcast non può dirsi Git Bar Podcast senza il momento "Il Paese dei Balocchi".E conduco nel Paese dei Balocchi.Ah, il Paese dei Balocchi.Allora, l'altra volta l'avevo fatto in serio e l'ho portato nell'angolo dei balocchi del mio libro preferito, "Le fattiche di programmare" e quello sull'apprendimento della serie dei pragmatici.Stavolta invece faccio un po' più in faccia o meno, nel senso che non necessariamente.Abbiamo appena parlato di Learning Path e io ho un figlio piccolo che ha fatto quattro anni da poco.Tra le cose che ho scoperto gli piacciono, mi piacciono per giocarci con lui, ci sono dei giochi nel Santa Tracker che Google fa tutti gli anni, che è una serie di giochi e cose a tema natalizio.È nato come un coso integrato con Google Maps che ti fa vedere il percorso che fa Babbo Natale, la notte di Natale su Google Maps.Adesso invece è una cosa che sta attiva tutto l'anno e ha una serie di giochi a tema natalizio e un po' sono legati al coding, nel senso che ci sono dei percorsi che devi far fare a Babbo Natale specificandogli le istruzioni in maniera algoritmica.Il papà nerd che in me quando vede il figlio di quattro anni che fa i cicli ford si scelga il cuore.Bellissimo voglio assolutamente il link giusto per prepararmi per tempo alla cosa.Mattia io ti ringrazio tantissimo per aver come dico sempre condiviso con noi questa questa questa esperienza no questo questo questo sperimentare questo usare i tool nuovi e quando li si usa per lavoro si spende buona parte della giornata sui nuovi linguaggi sui nuovi tool quindi l'esperienza è veramente concreta e quindi ti ringraziamo per questo naturalmente ci sentiremo in diritto di riromperti le scatole se qualcuno vuole qualche informazione Mattia lo trovate direttamente nel gruppo telegram è uno tra l'altro dei membri più attivi quindi lo dico io al tuo posto ma sono sicuro che diresti la stessa cosa rompetegli le scatole perché è una delle persone più disponibili del mondo detto questo io vi ringrazio Mattia io ti saluto a prestissimo grazie a te e alla prossima spero che l'episodio vi sia piaciuto chiacchierare di kotlin con mattia è stato super super interessante noi ci diamo appuntamento alla prossima settimana ma naturalmente se l'episodio vi è piaciuto potete aprirlo direttamente con l'applicazione apple podcast e lasciare una recensione se vi fa poi piacere lasciate anche un messaggio nella recensione questo ci aiuterà a contattare ad arrivare a più persone possibile detto questo io ripeto vi do appuntamento alla prossima settimana da lione tutto ciao GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica] [Musica] [Musica]
