Bene e benvenuti su Geekbar, questa puntata devo dire che un po' così ci siamo, mi sono organizzato per farla nonostante sia un viaggio e non abbia tutta l'attrezzatura che insomma è l'attrezzatura, il setup di default del nostro podcast.In questa puntata di luglio ho voluto mettere la seconda parte della chiacchierata che abbiamo fatto con Danilo iniziata già nell'episodio precedente dove parliamo delle caratteristiche di Goi, di Rust detto questo io credo di non avere niente altro da aggiungere oltre che insomma le lagne di Lambda in sottofondo io vi auguro un buon ascolto allora e ci sentiamo la prossima settimana 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.E quindi io faccio una missione, sono tipo nubo per eccellenza, nel senso che non ho mai scritto una riga di codice né in uno e né nell'altro linguaggio.Parliamo infatti di Go e di Rust.Non essendo la persona adatta per parlarne ho con me Carmine che in qualche modo mi fa da bastone della vecchiaia e in qualche modo mi dà una mano per non fare domande veramente idiotte.Anzi ha un pulsante e può suonarlo ogni volta che dico una cazzata.La prima domanda che voglio farti riguarda Go ed è una cosa che mi chiedo spesso in realtà Danilo.Secondo te cosa cambia nell'approccio tra un linguaggio interpretato e uno compilato? Me lo chiedo spesso.Bella domanda.Diciamo che per me personalmente non mi sono mai soffermato questa domanda particolare perché penso di aver passato un sacco, fortunatamente penso di aver passato un sacco di tempo con le linguaggi compilate.Però quando vado sui linguaggi interpretati quello che mi manca è il compilatore che mi dice "guarda, stai facendo questa cosa, è sbagliata, cambiala".Di solito quando più o meno l'errore viene fuori, se scrivi qualcosa di sbagliato l'errore viene fuori.La differenza è quando mi viene fuori sulla macchina in locale o quando mi viene fuori in production o su staging.Quindi questa effettivamente è la differenza maggiore.L'altra differenza che personalmente, diciamo che è la differenza fondamentale, è la velocità di sviluppo tra i due linguaggi o apparente velocità di sviluppo tra i due linguaggi.Uno dei selling point maggiori dei linguaggi interpretati è che scrivi, non c'è bisogno di aspettare un minuto per il compilatore alcuni linguaggi, tipo Rust, per esempio.O le mezz'ore se compili con SBT in scala.Esatto.Ma invece è un feedback più veloce.Io...questa è diciamo che la differenza fondamentale che vedo e che sento, però ho qualche "mixed feeling", come si dice...non credo che sia effettivamente da...un'ottima ragione perché poi dipende tutto da quanto sei...quanto ti senti a tuo agio con un determinato linguaggio o meno.Personalmente, per esempio, riesco a scrivere delle cose molto velocemente in Go o molto velocemente in qualche altro linguaggio compilato perché penso di essere a questo punto abbastanza familiare, di avere abbastanza familiarità con il linguaggio e se dovessi andare ad utilizzare un linguaggio interpretato potrei effettivamente essere meno produttivo, meno productive rispetto a, per esempio, Google.Semplicemente perché è quello che più o meno faccio da tutti i giorni, però costantemente da cinque anni, sei anni.Diciamo che è per questo che principalmente spendo la maggior parte del mio tempo sui linguaggi compilati.però dipende che a volte non è bisogno di avere diciamo il compilatore che ti dà sempre una mano su se il tuo programma effettivamente funziona oppure no.Per esempio a me piace, sono un grande fan di scrivere, sono un grande fan dei script in Python, io cerco di utilizzare Shell il meno possibile, anche per quando si tratta di qualcosa di stupido per il mio laptop o per quello aziendale.In quel caso effettivamente il livello di criticità non è lo stesso di lavorare su un progetto a lavoro, per esempio, in azienda.Quindi anche se scrivessi del codice che non funziona, che non funziona in determinati punti, però riesco a sviluppare uno script in cinque minuti o 10 preferisco piuttosto andare ad utilizzare Python che magari scriverlo in Go.Quindi secondo me dipende anche da quello che stai facendo.Dal caso d'uso.La mia domanda, e la domanda che volevo farti è, Go, che cos'è che ha reso Go così famoso qualche anno fa e che lo ha fatto saltare nell'apice delle classifiche di interesse il rispetto ad altri linguaggi? Cosa lo distingueva dagli altri? Credo all'epoca.Io ho iniziato con Go, quindi per me non c'era nessun altro metodo di paragone fino a quando ho iniziato praticamente.Quindi per me più o era la normalità, però anche anche vedendolo adesso rispetto ad altri linguaggi che sono più o meno lo standard nel settore, la differenza principale, le differenze principali sono la semplicità del linguaggio, il linguaggio Go è semplice by design, non l'hanno fatto effettivamente L'hanno fatta effettivamente semplice perché volevano avere un linguaggio semplice per...Google voleva questo linguaggio semplice per il loro codice interno e per metterci intents che magari non hanno mai visto il linguaggio, però di portarli ad essere produttivi nel giro di settimane, non di mesi o di anni.Quindi la semplicità del linguaggio, senza dubbio un ottimo selling point linguaggi tipo Java, Scala o C#.E la differenza nel paradigma che Go ha...Go può essere utilizzato come un linguaggio object oriented, però effettivamente non è object oriented.Questo, secondo me, fa la differenza quando vai a scrivere codice.C'è un sacco di persone che usano Go come se fosse Java, come se fosse C#.Però se poi effettivamente qualcuno utilizza Go nel modo in cui è più o meno pensato di essere utilizzato, il codice che puoi produrre fa le stesse cose ma è molto più semplice di quello che avresti con un linguaggio diverso.Ed è molto più veloce anche.A livello di paradigma cosa cambia in realtà? Principalmente non hai classi, non ci sono le classi, è tutto abbastanza...non ci sono classi, non ci sono cose come inheritance, cioè qualcosa di simile all'inheritance ma non proprio.Quindi in generale tutto l'overhead che si ha con altri linguaggi per via del paradigma oggetti, In Go non c'è, semplicemente.Quindi ti permette di scrivere un codice senza dover pensare a cose complesse, tipo complessi catene di inheritance, di ereditarità.Tra le tante cose che in realtà mancano in Go c'è anche il try and catch, quindi la cattura delle eccezioni.Corregimi se sbaglio, ne ho parlato in uno dei primi episodi di Gitbar con Stefano e la cosa a suo tempo mi suonava particolarmente strana come facciamo tutti un po' cresciamo nel tempo ho avuto modo di provare altri paradigmi per gestire gli errori che mi sono sembrati alle volte molto più semplici concettualmente da assimilare per cui questa mancanza di try and catch per l'error handling mi sembra un po' meno aliena.Ad oggi qual è la best practice per la gestione dell'errore in Go e se ci sono anche delle altre fazioni che propongono degli altri approcci perché so che è stata una cosa un po' di battuta, no? Sì, allora, parlando del "best practices" di oggi, in generale se hai del codice che torna errore, ritorna l'errore.Quindi una delle cose che Go ha è supporto per ritornare numero diverso di parametri che ritorno all'uscita di una funzione, quindi non è un solo parametro.Quindi quando stai scrivendo del codice che può fallire in qualche modo, sempre ritornare l'errore.Poi hai praticamente due vie quando hai questo errore, che torna da una funzione che magari che vanno all'interno del codice o lo gestisci o lo ritorni a un monte.Se devi gestirlo, semplicemente devi più o meno vedere che tipo di errore è e ci sono diversi modi per vedere che tipo di errore è, c'è il package errors che ti permette di fare qualche assertion sul tipo di errore, quindi error is di un particolare valore o error has per vedere se è un errore di un particolare tipo, in base a quello ovviamente tu fai o l'uno o l'altro, dipende da come la tua logica di error handling.Se l'errore va ritornato, non va gestito nel livello in cui l'errore è stato catturato, la best practice sarebbe di tornarlo a monte ma wrappandolo, facendo wrapping praticamente di questo errore, con un errore un pochino più descrittivo o con un messaggio un pochino più descrittivo.C'è la standard library mi sembra da Go 13 o da Go 15 ha aggiunto la funzione error f un parametro per drappare gli errori quindi è molto simile a fare una roba tipo printf quindi con formatting, invece di utilizzare il percento S, utilizzerò il percento W, e quando la W è presente in questa funzione, la standard library ti wrappa già l'errore e ti li passa in input con un messaggio che specifica cosa è successo.così che quando l'errore viene gestito, a livello in cui viene gestito, praticamente hai più o meno una catena che mostra quello che è successo.Quindi praticamente rispetto al try and catch, al posto di passarlo in un canale invisibile, questo errore, rilanciarlo in un canale invisibile, ce l'hai sempre a portata di mano in tutti i livelli? Possiamo dire così? Sì, diciamo che questa è la base di Goal, penso che è un motivo per il quale a molte persone piace Go, è che devi gestire le cose in maniera esplicita.Non c'è nulla che avviene in maniera implicita, o pochissime, pochissime cose che avvengono in maniera implicita.Quindi anche quando si tratta degli errori.Alla fine della sera questo è più o meno quello che succede anche con i try-catch, no? Fai il try ad un certo punto del tuo programma e ti gestisci vari tipi di errori che sono successi quando hai chiamato una funzione.La differenza è che devi farlo esplicitamente quando lo fai in Go.Quindi ci sono meno...i casi nei quali tu stai chiamando qualcosa che può fallire e non sai come fallisce, in Go praticamente non ci sono.Se ci sono magari qualche funzione che ritorna panic, che panica e ti botta giù tutto il programma, di solito sono marcate o documentate in maniera appropriata, quindi è abbastanza esplice.Adesso che ho iniziato a fare un po' più di Java Kotlin stuff a lavoro, ti ho trovato ad interfacciarmi con roba tipo Kafka Streams e tutto quel tipo di ecosistema e ogni volta che chiamo qualcosa ho la paura."Ma forse torno un'eccezione.Ma questa cosa non mi dice se torno un'eccezione oppure no.Che devo fare? La metto in un traghaccio? Come lo gestisco l'errore?" Con Go questo problema non c'è.Cioè, se ti torna un errore, la funzione può fallire ti ritorna l'errore, cioè proprio nella signatura del metodo e quindi di conseguenza ti dà anche più, come dire, confidenza a scrivere il codice.Chiaro, chiaro.Detto questo vediamo spesso a Go associato al mondo della programmazione di sistema e la mia domanda è e esistono e Go lo vedo usato in tantissimi microservizi, ma esistono degli esempi famosi di monoliti in Go? Perché altrimenti non sarebbe di moda Go eh? Penso che Kubernetes lo potresti definire come monolita.Non so se hai mai visto la di Kubernetes, io non sono un esperto della codebase, però probabilmente una delle codebasing più grandi che esistono sul panorama open source.Nel settore enterprise non lo so, penso che sia un linguaggio abbastanza nuovo.Concede più o meno con il periodo nel quale c'è stato questo shift verso Microsoft Visual Architectures, quindi se qualcuno sta pensando di scrivere qualcosa in Go, per esempio una startup che ha bisogno di scrivere un monolita per il loro progetto.In quei casi la velocità di sviluppo è abbastanza critica, quindi usare una cosa tipo Go effettivamente non è che ha tutto questo senso, perché uno uno dei pro e uno dei contro, allo stesso momento, tipo un Schrödinger cat, uno dei pro e uno dei contro di Go è che, essendo così esplicito, molte delle cose che in altri linguaggi viene fatto magicamente, in Go non viene fatto magicamente, devi farlo tu.Quindi quando si tratta di scrivere un MVP per un prodotto, per una startup, quello che è, di solito questo è il punto dove crescono, dove nascono i monoliti.Ma utilizzare i monoli non ha così tanto senso, quindi sono un po' scettico riguardo a trovare questo tipo di casi nel settore enterprise.Però ogni volta che sento dei racconti da altre persone arrivo un gosto di tutto, quindi forze, forze! Lo so! Nel senso che non ci li metti al peggio, no? Esatto.di magia e io so che Carmine ha una domanda sulla magia.Allora, diciamo, riconduciamoci proprio a quest'ultima cosa, no? Diciamo di avere comunque altri linguaggi e altri tool o framework in altri linguaggi che fanno tante cose magiche tra virgolette e dietro le ascense.Abbiamo lavorato entrambi in Rails, quindi sai bene come vedi per una persona magari che viene comunque da un mondo e da un linguaggio in cui la metaprogrammazione è presente diciamo come costante, ad esempio per chi viene magari dal mondo Ruby o anche dal mondo JavaScript.Come la metaprogrammazione in Go e come la giudichi come practice da seguire per prendere alcuni, diciamo, bypass quando si fanno le cose, oppure qualche cosa da relegare, diciamo, ai casi d'uso più reconditi e veramente necessario.La seconda, la seconda.In generale per fare metà programmazione in Go o per fare qualunque magia strana in Go c'è bisogno di reflection e quando qualcuno inizia in Go, ci sono alcuni posti dove andare a vedere, dove andare a imparare.Uno di questi posti è Facted è una delle cose che effettiv.co, se non ricordo male, è stato un po' di tempo fa, una delle cose che effettiv.co dice è "non usare reflection se non sai quello che stai facendo".Ci sono alcuni casi in cui le limitazioni del linguaggio che vengono dalle scelte di design per la semplicità, Alcune scelte di linguaggio in generale limitano quello che può essere fatto con il linguaggio.Di nuovo, è stato fatto per design, però lasciare la metà programmazione è solo per quei casi, solo per i casi in cui c'è bisogno di risolvere un problema con questo linguaggio, per qualunque motivo, e gli strumenti che ha a disposizione, il linguaggio che dà a disposizione, non sono abbastanza per risolverlo in maniera pulita, in maniera bella.Magari adesso che arrivano i generics, penso che tra un paio di anni, un annetto, un paio di anni, le cose cambieranno un po', quindi non ci sarà bisogno neanche di questa magia della reflection.Però sì, di solito in Go l'idea è cercare di evitare reflection, cercare di evitare magia nera, perché di nuovo va contro la filosofia del linguaggio.Questo è vero per Go ed è vero per altre cose come domain design, per esempio, che è una delle cose a cui mi sto attraversando un sacco ultimamente.Più si espliciti, meno devi pensare a cosa può andare storto, meno devi stare in ansia, perché se tutto è esplicito, è scritto là, non sai cosa può succedere, cosa non può succedere.Quindi sì, niente magia, ho cercato di non usarla.Secondo te questa cosa qui può essere una limitante per tante persone che magari vengono da quel mondo lì e che vogliono approcciarsi a Go perché ne hanno bisogno per una questione di performance, per una questione di compatibilità con alcune cose, insomma perché effettivamente hanno bisogno di Go, insomma, questa cosa qui la dico anche perché nel senso ci sono passata anch'io, insomma avere anche lo switch mentale, l'overhead mentale di passare da da un linguaggio, da uno strumento che ti permettesse di fare tutto e il contrario di tutto a qualcosa invece che diciamo che ti sforza a pensare esattamente a quello che stai facendo può essere effettivamente qualche cosa che può scoraggiare tanta gente.Io ho visto effettivamente alcune persone che hanno detto no, questa cosa non fa per me.invece c'è una path per entrare in quella che è la go way e come scrivere go provenendo da questi ambienti un po' più liberi oppure è semplicemente qualcosa che devi sposare così com'è.Ci sono un sacco di punti di riferimento dove puoi effettivamente imparare qual è la GUI.Devo dire però che a volte è difficile, e questo non tanto per me perché, ripeto, io sono entrato...ho iniziato con Go, quindi più o meno ho iniziato la programmazione Enterprise, che è stranissimo, ho iniziato la programmazione Enterprise proprio con Go, quindi non mi ritrovo molto in questa descrizione, però da molte altre persone con cui ho avuto a che fare, ho avuto un sacco di difficoltà con Go, perché c'è una certa mancanza di quali sono le best practice, come lo risolvi questo problema con il "go away" in maniera idiomatica e questo è un po' un punto a sfavore di Go, però ripeto c'è un sacco di di materiale online dove effettivamente qualcuno può imparare qual è la go way, anche se magari a volte è un po' nascosto, però in genere effective go è seguire un paio di delle codebase più famose, per esempio Ashicorp ha un sacco di roba interessante Si può fare.So che Go scorraggia un po' di persone perché effettivamente è diverso rispetto a molte delle cose che la maggior parte delle persone utilizzano, come JavaScript o Magian, Ruby.Secondo me personalmente è importante cercare di fare uno sforzo, ad essere aperti a una tecnologia e a risolvere il problema in maniera diversa.Per me, quando cerco di entrare in un nuovo linguaggio, per esempio anche Rust, quando sono passato da GoRust, ho sempre cercato di trovare all'interno della community.Questa è la prima cosa che faccio quando mi approccio a un nuovo linguaggio, cerco di entrare dentro la community e di estrapolare le informazioni importanti, per esempio "ah, come risolvo questo problema in questo linguaggio?" o magari non il problema che sto cercando di risolvere però qualcosa di simile.Questo è quello che cerco di fare sempre e cerco sempre di mantenere un open mind come risolvere il problema con degli strumenti diversi.Quindi penso che mettiamola così, il modo in cui la vedo è se il problema è che non riesci a trovare del tempo per approfondire il linguaggio e fare le cose come dovresti farle, in maniera idomatica, nel linguaggio, probabilmente non dovresti utilizzare quel linguaggio, mettiamolo così, perché a volte capisco che, specialmente a livello laborativo, abbiamo delle certe requirements, dei certi deadlines e quindi se il problema è essere veloci o comunque sia essere produttivi in un determinato linguaggio probabilmente non dovresti utilizzarlo.Questa cosa qui mi trovi d'accordo, ma quindi secondo te Go può essere un'alternativa, facendo un passo indietro anche a livello accademico, nonostante tutti i vari problemi che ci possono essere, scusate un attimo che stanno sgozzando con qualche cosa fuori dal mio barchetto.Dì che gli buchi il pallone.Allora, stavamo dicendo, secondo te Go può essere un'alternativa, diciamo, un'alternativa come primo linguaggio anche dal punto di vista didattico a C o a C++ o comunque a quei linguaggi che tipicamente sono quelli, diciamo, con cui si comincia, insomma, ecco.Secondo me sì, secondo me sì.Il fatto che Go sia effettivamente by design un linguaggio semplice è a dire il vero uno dei linguaggi migliori con il quale iniziare, perché è abbastanza a basso livello da capire come funzionano le cose a basso livello, ma non troppo.Ricordo ancora ancora quanto tempo abbia passato a capire come funziona HIP Allocation in C e come funziona Stack Allocation, tutta quella roba lì, da persone che non hanno mai programmato prima.Quindi sì, senza dubbio, secondo me Go è un ottimo linguaggio per iniziare.Ovviamente quando uno inizia a programmare non pensa a come fare le cose in maniera erotica, uno inizia il programma e basta.Secondo me per Go ci sta un sacco, utilizzarlo come primo linguaggio è un'ottima opzione.Vorrei fare, magari per specificare quello che intendo per iomatico, penso che questo termine ha un significato particolare per noi che lavoriamo nel settore IT e magari principalmente nel back-end, per esempio.Però c'è da ricordare che Go non è un linguaggio per back-end, non è tipo PHP che è nato per scrivere web servers, è nato come linguaggio generico di programmazione, come un linguaggio di sistema.Quindi molte delle cose che noi riteniamo idiomatiche magari non sono idiomatiche per altri settori o per altri casi d'uso.Go, che magari non ha senso parlare di codice idiomatico quando si tratta di persone che si stanno approcciando alla programmazione.No, anche io insomma sono d'accordo con te, che Go effettivamente può essere quel compromesso, diciamo, per avere una strazione giusta, diciamo, per cominciare.anche perché poi, almeno per me è stato difficile passare dal CI, da avere la gestione della memoria in un certo modo, a scrivere codice in un certo modo, a passare diciamo a qualche cosa con un pizzico di astrazione in più.Invece con il Senno di Poi sono convinto che mi troverei molto a mio agio a fare il contrario, quindi magari a partire con qualche cosa con una strazione in più come può essere Go e almeno per questo fatto io, spinto dalla curiosità direi "ma aspetta ma come funziona veramente il memory management?" per poi andare diciamo nel dettaglio di quella cosa lì.Sì, sono totalmente d'accordo, secondo me, ma questo in generale, penso che andare top down sia meglio che partire bottom up.Molte volte magari non hai neanche effettivamente bisogno di sapere cosa succede nel dettaglio, però secondo me è sempre buono partire da un certo punto dove ti senti più o meno produttivo e poi iniziare a capire determinati concetti, poi se hai voglia di approfondire, andare più nel dettaglio, penso a Loopy.Quindi, secondo te, avrebbe senso, diciamo, per un programmatore neofrea, per un wannabe software engineer, che sta partendo da zero, ha senso con il mercato, diciamo, che c'è oggi e a questo punto ti chiedo di fare uno uno sforzo per riuscire anche ad interpretare quello che può essere il mercato italiano rispetto magari a quello dove ti trovi ora.Diciamo per un nostro connazionale super junior, ha senso imparare Go nel 2021 come prima cosa e come strumento per arrivare diciamo ad una produttività lavorativa sana e in un tempo breve, oppure consiglieresti di partire con un'altra cosa? Questa domanda è un po' tricky.A un punto di vista un po'… mi trovo un po' in conflitto, perché per una persona super junior, in particolare per una persona che cerca un prospetto lavorativo con nazionale, parliamo dei con nazionali, giusto? Per un con nazionale che cerca un prospetto lavorativo, vuole iniziare a diventare produttivo in maniera abbastanza veloce, principalmente per lo stipendio, immagino, non credo che il problema sia prendere il linguaggio, cioè pensare al linguaggio che mi insegna il come programmare, è imparare il linguaggio che mi fa guadagnare da mangiare.Il problema è che quello che succede è che in Italia non credo ci sia un sacco di aziende che effettivamente utilizzino Go, quindi io guarderei più da quel punto di vista piuttosto che alla semplicità del linguaggio.Quando si tratta di pura istruzione o comunque sia di una cosa più da tempo personale, un hobby, allora il discorso è diverso.In quel caso direi sì, in Go c'è senso, ma per una persona che è alla ricerca di un inquadramento professionale, la verità è che in Italia il lavoro o le opportunità in Go sono veramente veramente poche, o erano veramente poche l'ultima volta che ho cercato lavoro in Italia.Adesso non so com'è la situazione però immagino, dallo standard italiano, che probabilmente non è divenso.Confermo questa però devo dire che all'astro e specialmente a Berlino Go è uno dei linguaggi più cercati.Allo stesso modo devo dire è il linguaggio con il quale facciamo più difficoltà a trovare persone.Adesso che ho iniziato a fare hiring da sei mesi o una roba del genere, in allo fresco utilizzo un sacco Go, è uno dei linguaggi principali che utilizzo per i microservices e devo dire che abbiamo fatto un sacco, un sacco, un sacco di difficoltà a trovare persone preparate in Go, senior developers.Molte persone a livello mid, a livello più o meno mid, diciamo ok, avevano, però diciamo che il co-developer, non so come spiegarlo, diciamo che ha una spinta in più, perché c'è un sacco di aziende qui e non ci sono un sacco di co-developers, quindi quando si tratta di negoziare una posizione in un'azienda fa effettivamente la differenza.No, certo.Quindi diciamo, secondo te qual è il profilo del Senior Developer Go, diciamo, come conoscenza e padronanza del linguaggio? Ottima domanda.Secondo me, quello che vedo in genere da un Senior Engineer, quando vedo del codice, specialmente nell'Iring, quello sul quale mi soffermo è la complessità della soluzione, quindi in particolare quanto è complesso il codice, quanta strazione c'è nel codice, quante interfacce, quanti componenti no classi ma struct, quante funzioni, quanti test, quanto è complesso il codice in generale.Go ti permette di scrivere un codice che è abbastanza semplice e non ha bisogno di...Come dire...di...Sovrastrutture strane.Sì, mettiamola così, sì.Boilerplate.C'è un po' di boilerplate che devi fare in Go, però quello che mi aspetto da un senior è fare i giusti trade-off.Questo è vero per Go ed è vero per altre linguaggi.Però in Go in particolare, dato che è molto, ripeto, molto esplicito, è più semplice, è più apparente, è apparente di città in italiano credo si.Lo vedi con più facilità, no? Bisogna essere verbosi il giusto, insomma.Esatto.E' quella cosa no? Anche secondo me, Go è quel linguaggio che può fare...allora, Go è semplice, però può essere anche tanto verboso, secondo me, come diciamo come righe di codici scritte per fare una determinata cosa.La trappola è quella, la trappola è quella, che il codice che vedo per esempio per le persone che stanno iniziando è molto complicato, è molto, molto defensive, no, c'è un sacco di defensive programming.Quello che vedo per esempio dai junior, quello che facevo anch'io effettivamente qualche anni fa, è quello che invece vedo nei senior, il codice da senior, è totalmente abbattere una classe di complessità che non ha senso.Controllare se i valori di quando fai "tract.new" o quello che è, quando di un costruttore, controllare se i valori sono null oppure no.Te lo puoi anche tenere, effettivamente puoi fare tutta quella parte di error handling e complicare il codice in quel modo, non ha effettivamente senso secondo me.Anzi, molte volte credo che effettivamente, semplicemente utilizzare una classe, utilizzare non il linguaggio, il linguaggio non go, ma il linguaggio generale, utilizzare una classe con i metodi pubblici.In Go è perfettamente valido e anzi è una delle cose che vedo un sacco nel codice di diversi signi.Quindi ripeto è sempre trovare il giusto compromesso.Beh c'è da dire che Go comunque era utilizzato ed è utilizzato in Codebase, eccellente abbiamo citato Kubernetes ma potrei dire anche Discord anzi Discord è un caso particolare no la la pietra della della diaspora scherzo nel senso che era una codebase scritta che poi è emigrata a Rust.Rust, quattro anni di seguito il miglior linguaggio nella survey di Stack Overflow.Carol, cosa possiamo, cosa vogliamo sapere in più di questo linguaggio che si presenta a noi come un outsider, no? È un linguaggio diverso, è un linguaggio un po' Senti, per quanto si tratta di Discord, per esempio, il passaggio da Go a Rust, da quello che ricordo dall'articolo, aveva senso per il tipo di servizio che era scritto in Go, che era abbastanza più intenso.Rust, da quel punto di vista, è probabilmente una delle cose a quale eccelle, però c'è da tenere in considerazione quanto diverso sia rispetto ad altri linguaggi e alcune delle cose che lo rendono veramente più complesso rispetto ad altri linguaggi, per esempio il borrow checker, ownership, tutti questi concetti abbastanza nuovi e fanno effettivamente la differenza, parlavamo del sentirsi produttivi con un linguaggio, Rust è tipo l'ultima spiaggia a livello di produttività secondo me, è veramente iniziare, entrare all'interno del linguaggio e capire come funziona ha bisogno di un po' di tempo, ha bisogno di un po' di trial and error e ho visto che molte persone entrano in Rust con, più o meno come entro in con il concetto con il con il la forma mentis di un altro linguaggio cercano di farlo funzionare allo stesso modo.Il punto è che non è come Go dove il compiler più o meno ti dice niente, ti fa scrivere quello che vuole.Rust è unforgiving, cioè se una cosa non non è fatta come dovrebbe essere fatta non compilerà mai, che è un po' frustrante.Penso che frustrante sia la parola giusta.In particolare io, specialmente in azienda, adesso sto cercando di promuovere un po' di più Rust, perché penso che sia un linguaggio abbastanza interessante, uno di quei linguaggi in cui puoi fare un po' di magia.Penso che sia Go, ma con la marcia in più, la marcia in più che mi piacerebbe a me fare una roba un pochino più magica, più interessante, che vedo per Rust.Il problema nel cercare di venderlo agli altri ingegneri, a altre persone.Se io lo metto in confronto ad altri linguaggi, cosa guadagno? Sì, tutti dicono che Rust è veloce, che Rust è figo, quello che vuoi, però cos'è che guadagno alla fine se io utilizzo Rust? Quando si tratta di settori tipo il nostro dove principalmente, o settori tipo il mio, dove principalmente scrivo microservizi o web servers, la differenza tra Go e Rust a livello di performance non è così diversa.Quando parliamo di cose abbastanza semplici tipo un API o un servizio che non abbia nulla di particolarmente performance critical, mettiamolo così.Quindi l'unico selling point è che puoi scrivere il codice un pochino più safe per via di come il linguaggio funziona, però c'è da metterlo su una bilancia con il livello di produttività, il livello di complessità del linguaggio e la curva di apprendimento.Quindi non lo so, è un po' difficile.Secondo te, diciamo, volendo paragonare Rust e Go, diciamo Go ti offre comunque una standard library ampia, questo ovviamente croce delizia tra le persone che reinventano la ruota e le persone che lo leggono sul blog mistico, ma Rust come si pone, diciamo, rispetto a questa cosa qui.Switchando tra Go e Rust, riesci a ritrovare la stessa ricchezza o diciamo le stesse possibilità nella standard library o no? Una cosa che apprezzi o no, insomma? No, Rust se lo mettiamo in confronto alla standard library di Go, questo è vero per Rust, ma è vero per molti altri linguaggi, se lo metti in confronto alla standard library di Go, perde un sacco e tra l'altro è fatto da design.In design di Go ha in mente essere semplice e essere inclusive, da darti abbastanza, da sentirti produttivo e sentirti produttivo velocemente, mentre Rust ti dà a disposizione un Kalashnikov, dove puoi praticamente uccidere qualunque cosa, diciamo affrontare qualunque problema che tu possa avere.Però l'idea di Rust è di darti a disposizione solo quello di cui tu hai bisogno, per quanto si tratta della standard library.Tutto il resto devi portartelo tu.Quindi mettiamo una cosa così, Go è Batteries Included, Rust è batterie esclude.La mia domanda invece è che differenze noti tra il type system di Go e quello di Rust? Go quasi non ce l'ho, per ora.Era quella la domanda.Si Rust è decisamente più complesso rispetto a Go.Infatti so che un sacco di persone che sono interessate a Rust vengono principalmente da linguaggi funzionali, perché effettivamente puoi scrivere un sacco di linguaggi funzionali in Go e in Rust, non tantissimo, non come un linguaggio funzionale ovviamente, però abbastanza con il bonus di tirare fuori un programma che è molto molto molto performante specialmente se lo occupari per esempio Askel o Kamel, uno di questi linguaggi così.Go invece è molto più semplice, il type system è quasi inesistente.Almeno fino ai primi periodi Rust non aveva un supporto per la programmazione asincrona se non ricordo male.È cambiato qualcosa e soprattutto si può pensare di utilizzarlo per i servizi diretti dove in realtà possiamo di loro in questa piccola essenziale.Sì sì sì come dicevo prima penso che sia successo nel 2019 alla fine del 2019 La quest della programmazione asincrona per la maggior parte è stata risolta ed è finita in Stable, quindi ad oggi su Stable è possibile utilizzare PADIS asincrono, Batteries excluded però, cioè c'è il supporto per la programmazione asincrona ma non c'è un runtime, il runtime è esterno e va utilizzato...ci sono diversi runtime che tu potresti utilizzare, il più famoso probabilmente è Tokyo.Quindi è assolutamente possibile scrivere un web server in maniera sincrona in Rust.Non so se lo farei comunque, l'ho già fatto, personalmente l'ho già ho fatto gli scritti una decina, però la differenza tra Rust e un linguaggio più standard tipo Go ovviamente o JavaScript per esempio è che principalmente mancano alcune librerie o alcune In particolare, librerie, mettiamola così, per rendere l'esperienza un po' migliore.Secondo me c'è ancora del lavoro da fare su Rust per rendere l'esperienza di sviluppo un po' migliore.E questo, fino a quando non succede, secondo me non ci saranno un sacco di persone che ci proveranno.In questa cosa che hai detto mi ci ritrovo tanto, diciamo uno dei più grandi ostacoli che ho con Rust è proprio l'ergonomia nello svolgere alcune task che con altre linguaggi sono molto più ergonomiche, ok? e diciamo quanto tempo ti ci è voluto perché il compiatore smettesse di bastonarti davvero? Qual è il punto in cui acquisisci quella padronanza tale da uscire fuori da quelli che sono? Quali sono le bastonate più comuni? Bella domanda! Ci spensavo qualche tempo fa.Per me lo switch è stato abbastanza improvviso.Penso che il problema, dal mio punto di vista, io ovviamente parlo dal mio punto di vista, penso che altre persone abbiano avuto un percorso un diverso, però dal mio punto di vista sono entrato in Rust sapendo quali fossero i problemi di Rust, che erano per esempio la gestione delle lifetimes o borrowing ownership.Sono entrato in Rust tenendo queste cose in mente e con la convinzione che dovessi gestirle in maniera efficiente dai WAN, per chi non sapesse e per chi ascolta e non sapesse cosa stia facendo nel lifetimes, borrowing.Questi sono alcuni dei meccanismi di Rust per validare che i riferimenti di alcuni oggetti siano effettivamente validi e che non ci sono problemi di memoria, praticamente null pointer exceptions o cose simili.Quindi io sono entrato nello sviluppo di Rust con questa cosa in mente pensando che dovessi gestirla esplicitamente.La realtà è che molte volte non hai bisogno di gestire.Anzi, molte volte è più semplice cercare di scrivere il programma, anche se dal punto di vista di memoria è super inefficiente, magari copi, stringa su stringa su stringa ad ogni passo.È meglio approcciarsi allo sviluppo, specialmente nei primi momenti, in questo modo, piuttosto che pensare all'ottimizzazione dal day one.Direi che nel mio caso fosse il problema di Premature Questo secondo me è stato il mio problema quando ho iniziato con Rust e so che molte persone allo stesso modo entrano in Rust sapendo già quali sono questi tipi di problemi e pensando che debbano risolvere tutti questi lifetime problems per le cose più semplici, poi effettivamente non è vero.Le lifetimes diventano un problema semplicemente quando scrivi codice, per esempio containers o cose del genere però in generale non c'è bisogno di gestirle in maniera esplicita.L'altro...il momento in cui ho avuto il click con Rust è realizzare il modo in cui scrivere codici in Rust.Nel senso, adesso lo spiego, è più o meno collegato a quello che dicevo prima, no? C'è il concetto di "borrow checker" in Rust, che è diverso da qualunque altro linguaggio, che è la cosa che ti bastona a livello di compilazione, e c'è il concetto di ownership, cioè come passi la memoria all'interno del tuo programma.Passi per il vadore, passi per il riferimento, move, praticamente muovere l'ownership da una regione di codice ad un'altra regione di codice.Il fatto di avere mutabilità e immutabilità, specialmente quando venivo, quando cercavo di scrivere il codice simile a come lo scrivessi in un Go all'inizio, più o meno lo facciamo tutti, cerchiamo tutti di scrivere il codice più o meno come lo sappiamo fare, ho fatto lo stesso anche io ovviamente, però tenendo in mente la mutabilità e l'immutabilità, e molte volte ovviamente il compiler esplodeva perché magari stavo utilizzando, scrivendo qualcosa che era pezzato per essere utilizzato su diversi thread, per esempio una struct in Go, una class in Java che viene utilizzato su diversi thread e magari utilizza una connessione verso il database e magari fa una create, aggiunge un user al database.Entrando in Rust con tutti questi concetti nuovi, la cosa naturale da dire sarebbe "ok, io scrivo questa classe che mi fa aggiungere questo utente, però questa classe, questa interfaccia, è mutabile, perché io sto cambiando lo stato della funzionalità che sto rappresentando.Però poi effettivamente non è vero.Effettivamente se non stai effettivamente cambiando la memoria all'interno di Rust, non c'è bisogno di pensare a tutte queste cose tipo mutabilità e non mutabilità.Anzi, molte volte è più semplice pensare a questo concetto esattamente come facciamo in altri linguaggi.l'esempio più semplice che mi viene in mente, se stai scrivendo un repository, un repository interface, e hai bisogno di scrivere il metodo dove aggiungi qualcosa al repository, piuttosto di utilizzare mutability, quindi un riferimento mutabile a self, che sarebbe praticamente tipo this in qualunque altro linguaggio o oggetti, piuttosto di utilizzare quello è meglio assumere che l'implementazione di questa interfaccia, trait, si chiamano trait in Rust, l'implementazione di questa interfaccia gestisce già l'immutabilità o la mutabilità al suo interno e passare tutto per riferimento.Esattamente come succede in qualunque altro linguaggio tipo Java, tipo Go, passa tutto per riferimento e poi quando si tratta di scrivere un'implementazione puoi avere a che fare con la mutabilità dei dati all'interno di implementazione.Il problema principale viene per esempio quando scrivi qualcosa in memory, in memory repository.In quel caso Rust mette già a disposizione dei modi con i quali puoi mutare i dati internamente, cioè la Smart Pointer, se questi si chiamano, ReadWriteLock, ReadWriteMutex, e praticamente utilizzando questo tipo di dati, questo è quello che si intende per Rust, Rust ti spinge a scrivere del codice thread safe.Utilizzando questi dati, questo tipo di pointers, questo è l'unico modo con il quale tu puoi scrivere del codice che effettivamente muta dei dati al suo interno, non c'è nessun altro modo per scriverlo.Una volta, questo probabilmente ha confuso un po' di persone, però una volta che più o meno capisci questo tipo di concetti, come funziona il Rust, e ci sono un paio di blog posts e di blog posts e di immagini anche dove più o meno spiegano queste cose in particolare, una volta capito questo secondo me il resto del linguaggio è fatto, cioè è abbastanza semplice.Sì, no, beh, intanto hai fatto da spot verso le parti che sono importanti da approfondire a un primo impatto, proprio per evitare di fare a cazzotti pesante col compilatore.Siamo andati lunghissimi e siamo arrivati al momento, paese dei balocchi, è il momento in cui i nostri ospiti e alle volte anche noi portiamo una roba che ha tratto la nostra attenzione un tool, un libro, una conferenza, insomma qualcosa che riputiamo sia importante lo condividiamo con la nostra community."E conduco nel paese dei balocchi" "Ah il paese dei balocchi" "Sì, ne ho tre e non so quali scegliere effettivamente" "Tutte e tre" Tutte e tre.Ok.Parto con la non tecnica.Non so se voi avete mai sentito parlare di mob programming.Avete mai sentito parlare di mob programming? No, sì.Se non sbaglio dovrebbe essere il pair programming ma con più persone.Esatto.Programmazione di Krik.Programmazione di Krik.Ci sta.Ottima traduzione.Sì, ultimamente siamo entrambe in una situazione entrando un sacco dentro questo Moat Programming in azienda e devo dire, riconducendoci al discorso che faceva prima Carmine, sulla serenità, sull'ottimo, su avere un ambiente sereno nel team, in ufficio.Il nuovo programma è un ottimo strumento per abbattere, punto primo, la asincronicità della review, che diventa un problema in team abbastanza, più o meno grandi, perché tutti i membri del team sono lì a programmare sulla stessa cosa, quindi praticamente il tempo di review va virtualmente a zero.Non solo questo, ma anche...Beh, lo dico, programmare insieme ti porta a stabilire un rapporto più profondo con il team, ed è personalmente uno degli strumenti che mi chiedo perché non l'ho scoperto prima.Fantastico, cioè nel team con il quale sto lavorando adesso, stiamo lavorando su questo nuovo progetto, che è un progetto enorme, ha fatto veramente la differenza e ci ha portato più vicini a livello tecnico, quindi ci ha portato a livello tecnico, più o meno allo stesso livello di comprensione, per lo meno per quanto riguarda questo particolare progetto.Tutti quelli nel team che partecipano More Programming, sanno cosa stiamo lavorando e come funziona, ma anche a livello umano ci ha portato molto vicino, perché di solito queste sessioni More Programming sono abbastanza lunghette, intorno a due ore, e cerchiamo di farle più o meno giornalmente, poi dipende, e poi effettivamente a un certo punto c'è bisogno di parlare di noi, non necessariamente sempre del Codgy, quindi è anche un ottimo strumento per avvicinarsi.Hai detto però che ne avevi altri due.Ne avevo altri due, sì.Pensavi me ne dimenticassi, ma io sono attentissimo.Ne prendo uno solo, ne prendo uno solo a livello tecnico.Ok.A livello non troppo tecnico, più o meno.Nella mia carriera professionale in Italia non ho mai sentito parlare di domain driven design.non so quante persone effettivamente sanno di domain driven design, però è assolutamente una delle cose che un software engineer, un ottimo software engineer o qualcuno che aspira a diventare un ottimo software engineer deve, deve, deve sapere.Dà una prospettiva completamente diversa allo sviluppo e alla qualità del codice.Adesso che ho avuto l'opportunità di finalmente utilizzato su un microservizio, come si deve, sta facendo veramente la differenza.Domanda, tu sei della scuola della pillola rossa o della pillola blu, del libro rosso o del libro blu? Ho provato a leggere il libro blu e effettivamente non è stato chiarissimo per me all'inizio, quindi libro rosso.Libro rosso è specialmente per qualcuno che non vuole leggersi l'intero libro rosso c'è il libro verde.Esatto.E aggiungo anche che c'è un altro libro che è il glossario.se sembrano davvero scritti da toi, il chien.Io ho detto il distilled perché sono pigro e poi ho comprato il rosso.E' vero, il rosso è un mattone.E' un mattone.Cioè il distilled ti dice le cose essenziali, secondo me, importanti e ti fa venire la curiosità poi di andare sul ROS.Il contrario secondo me è complesso perché parti comunque con un impatto che è molto più strong, invece se non è partire dal distillate per farne sul ROS è molto più tranquillo e secondo me il distillate è anche molto più scorrevole da leggere.Sì, senza dubbio.Anzi, il problema del ROS è che, ovviamente si, ma implementing domain C'è un sacco di dettagli sull'implementazione, però DDD personalmente è uno strumento principalmente che mi soffermerei molto, un sacco di persone si soffermano molto sul tactical pattern, su come implementare le cose nel codice, però la cosa fondamentale, lo shift fondamentale modo di pensare.Lo strategic pattern, sì, assolutamente.Ubiquitous language, context mapping, assolutamente la cosa principale.Sono d'accordo.Anche perché poi alla fine nel codice, nel mondo reale si fanno sempre compromessi e se non si sa quando farli è un grossissimo, grossissimo problema, sono d'accordo.Esatto.E poi ci sono modi diversi di implementarlo.Non bisogna sempre seguire lo stesso modo per implementare molti dei concetti anche nei tactical patterns.Vero.Termini, tu cosa ci hai portato? Allora io ho portato una cosa molto più terra terra, però in realtà è un libro, si chiama "Learning Go, an idiomatic approach to the real world Go programming.È un libro piccolo, dell'AORilly, credo, e in realtà io l'ho letto dopo averlo consigliato, un amico mi ha detto "ma c'hai qualcosa con cui posso avere una linea guida su come scrivere Go idiomatico?" Ho visto insieme che lo consigliano in tanti, l'ho consigliato, l'ho letto e secondo me è quel giusto compromesso per capire realisticamente come si fanno alcune cose e come non portarsi determinati pattern dietro anche in Go dove hanno effettivamente poco senso.Interessante.Naturalmente attendiamo il link.Io avevo preparato un balò com, lo cambio corsa in realtà è così tendo a perdermi le notifiche di github e tendo a rompermi le scatole entrare su github e a cercarmi le notifiche non so se qualcuno di voi ha avuto lo stesso problema ho beccato un'applicazione per mac os un'applicazione fatta in electron che semplicemente mi mette le notifiche di Github direttamente nella barra del mio sistema operativo in modo che ce li ho sempre visibili e questa roba è tanta roba.Si chiama Gitfi ed è una robetta che secondo me è parecchio comoda quindi ve la suggerisco.Nice, nice.Stavo pensando di scriverla poi a una ricerca l'ho trovata e quindi non la scriverò, sappiatelo.Ottimo, ottimo.Mamma mia, siamo andati lunghissimi, però sono felicissimo in primis di aver conosciuto Danilo, amico di Carmine, è stato lui a portarcelo qua nel Gitbar a bere una birra con noi, a parlarci un po' di Go e di Rust, mondi molto lontani da me, ma che vi assicuro attirano la mia attenzione e prima o poi qualcosa o in Go o in Rust la scriverò, fosse anche solo un Hello World.Detto questo a noi rimane che intanto ringraziare Danilo per essere venuto, quindi grazie di cuore.Grazie ragazzi, grazie per l'invito.Grazie anche a nome della nostra allegra combriccola nella nostra community.Noi come diciamo a tutti ma è questo lo spirito di Geetbar, ripetiamo che Geetbar è anche un po' casa tua da oggi quindi quando scopri qualcosa di interessante da condividere qualcosa che ti gaza particolarmente vienici a trovare c'è una birra fresca per te insomma qua nel nostro bar degli sviluppatori.Grande ci sono già a dire il vero quindi io guardo sempre il channel da lontano, a volte entro a volte partecipo cerco di farlo più di frequente.Sino ma dico anche in episodio.In episodio se hai voglia di parlarci di qualche altra cosa contattaci pure.Facciamo il part 2 su DDD, DDD Event Sourcing, Event Storming.Bello, ci sta.Penso di aver detto tutto a noi contati, io me ne dimentico sempre.Info www.kiosciolagitbar.it o @brainrepo su Twitter.Il gruppo Telegram perché ovviamente il gruppo Telegram è il cuore della nostra community dove tutti sono i più benvenuti e potete trovare me, potete trovare Mauro, potete trovare Danilo, potete trovare anche tantissime altre per poter discutere di tutto ciò che volete.Siamo aperti a qualunque discussione.Lamentatevi sul Rost quando scrivete qualcosa, cerco di aiutarvi.Detto questo io Danilo ti ringrazio nuovamente, ci accingiamo a chiudere da Budoni, Firenze, Berlino, giusto? Ho detto le tre geolocazioni.È tutto, noi ci aggiorniamo alla prossima settimana.Naturalmente se l'episodio vi è piaciuto mi raccomando utilizzate dei device, poi aprite Apple Podcast e mettete tante stelline per Gitbar, anche magari due righe, insomma non siate così parchi di parole.Detto questo io vi ricordo che l'appuntamento sarà giovedì prossimo sempre qua sugli stessi canali e niente, alla prossima.Ciao! ciao ciao GIT BAR 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 Full Stack Dev.[Musica] [Musica]
