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.Bene e benvenuti in questa nuova puntata di GITBAR.Oggi non sono solo, infatti con me collegato da Genova c'è Stefano Torresi, Senior Software Engineer a SUSE Linux e con lui parleremo di P, di Go e delle community e del ruolo che hanno la formazione dei professionisti.Prima di lasciarvi alla conversazione vi ricordo rapidamente i nostri contatti potete iscrivervi a @brainrepo su twitter oppure a info@gitbar.it.Inoltre su www.gitbar.it trovate tutte le informazioni del podcast comprese le nuove puntate, le note degli episodi e le trascrizioni.Quindi la avete veramente tutto.Però penso di avervi rubato fin troppo tempo raccontandovi e parlandovi dei contatti, quindi vi lascio direttamente alla nostra conversazione.Eccoci qua! Ciao Stefano, come va? Ciao Mauro, tutto bene tutto bene nonostante le circostanze globali abbastanza interessanti.Che piacere sentirti, sono davvero tanti anni che un po' ci siamo persi di vista, abbiamo avuto modo di conoscerci in un evento, un Code Emotion giusto? No, un PHP Day, tra l'altro mi ricordo che era il primo PHP Day a cui io partecipavo.E anche il mio.C'era un altro amico Sartori.Sì c'era Luca che adesso è una delle colonne portanti del Pug di Cagliari, finalmente ce l'ha fatta.Ti ricordi che era il nostro obiettivo quello di creare Tenefarlano? Sì, me ne discutevamo.Poi io mi sono un po' allontanato voi per mille vicissitudini, però Luca insieme a un'altra serie di ragazzi che si stanno impegnando in modo abbastanza concreto sono riusciti a far partire il pug di Cagliari.Finalmente anche la Sardegna ha un presidio di cultura tecnologica.Ma tra l'altro ho visto che proprio a Cagliari mi pare che ha aperto una sede facile.it che è molto attiva nello sponsorizzare questo genere di attività.Quindi si sta creando un piccolo mini app tecnologico a Cagliari.Sì, a Cagliari c'è Leonardo di Facile che in qualche modo con Facile stanno avviando questa impresa e anche lui è il cuore pulsante, l'altro cuore pulsante del Pug, stanno facendo davvero un lavoro...complimenti, bravissimi, guarda.Anche perché nessuno gli chiede niente in cambio, cioè loro non chiedono niente in cambio, quindi tutto quello che fanno è veramente un regalo che fanno alla Sardegna e da sarlo questa cosa non può che rendermi felice.Ma parliamo un po' di te, come sei finito a fare lo sviluppatore? Questa è una bella storia in realtà.Io ho cominciato che ero veramente piccolo.Il primo approccio con il codice è stato tramite il Commodore 64.Però è stato più ovviamente per gioco avevo 12 anni, 11 anni, qualcosa del genere.Inizio anni '90, le calzette sono dell'83.In ogni caso erano gli albori dell'informatica, almeno per quanto mi riguardava, ma non avevo ancora capito che volevo fare questo da grande.C'è voluto poi l'adolescenza per capirlo e ci sono arrivato tramite i videogiochi.Nel senso che io sono sempre stato un appassionato videogiocatore, di quelli diciamo hardcore, quindi ho sempre giocato col pc.In realtà il Commodore 64 è stato il primo computer che mi è entrato in casa mia, ma poi sono passato direttamente dal Commodore al pc.Ho dovuto aspettare, tra l'altro, tantissimo per fare questo balzo.Mi ricordo che il mio primo pc era già un pc windows con windows 95 ed è stato lì che il mio primo serio approccio al coding perché il cazzeggiare con il basic con il commodore ripeto era più una cosa dove prendevo il manuale del c64 e ricopiavo il codice basic e facevo succedere cose poi lo rompevo spostando statement a caso ma non avevo ancora in realtà letto nessun manuale generico sulla programmazione.Mentre invece quando ho cominciato a utilizzare il pc, che utilizzavo soprattutto per giocare, per cazzeggiare eccetera, approcciai per la prima volta lo sviluppo web tramite una guida pubblicata, non mi ricordo su quale rivista di settore, qualcosa tipo The Games Machine probabilmente, e scrissi la mia prima pagina web tramite il notepad.E' da lì che è cominciato tutto.Perché poi da lì, proprio nel giro di pochi mesi, cominciai a utilizzare PHP perché volevo rendere le cose dinamiche, quindi iniziare a imparare come funziona l'architettura client server eccetera.E da lì è nato tutto.E poi sempre grazie ai videogiochi dovetti approfondire sempre di più, perché io giocavo anche a livello a livello quasi competitivo, anzi a livello competitivo ma amatoriale, non professionale ovviamente, quindi non ci guadagniamo niente.Però giocavo a livello competitivo a dei giochi che richiedevano il gioco di squadra e quindi si creavano i cosiddetti clan online, si utilizzava gli RC come mezzo di comunicazione e venne a formare questi clan, quindi questi gruppi di videogiocatori dove poi ci si organizzava facendo partite tra clan eccetera, tipo amichevoli, e a volte anche tornei, cominciai ad essere sempre più attivo in questo ambito, ci impiegavo un sacco di tempo, avevo più o meno 15-16 anni quando cominciai a fare questa cosa, e cominciai, il primo vero sito web serio fu per uno di questi clan, dove aveva bisogno di essere un sito completamente dinamico, perché avevamo bisogno di caricare i risultati delle partite, gli screenshot, tutto il materiale, dovevamo fare il roster, dovevamo avere i blog quindi è convizioso.Ho ancora il codice di queste cose, l'ho conservato, ho ancora il codice scritto in PHP3 da qualche parte.Lo vogliamo su GitHub.Effettivamente lo dovrei rimettere su GitHub e in qualche modo devo riprendere a farlo funzionare.Inutile dire che l'interfaccia grafica era fatta in Flash, in Adobe Flash, anzi quello che ancora non era manco Adobe Flash, era MacroMedia Flash.Tranquillo ci sono cascato anch'io nella trappola, ho speso anch'io tante ore a studiare ActionScript.Prima ActionScript 2, poi ActionScript 3.Mamma mia che mondo, mi hai risvegliato una marea di ricordi.Tra l'altro devo confessarti che io i primi pattern di programmazione li ho incontrati proprio programmando in ActionScript, perché da quel punto di vista prendeva molto dal mondo Java e i pattern li avevo appunto iniziati a vedere come si gestisce uno stato, cose che allora erano un po' nel front end.Sì, sì, era abbastanza fantascienza.Io in realtà proprio ActionScript non l'avevo mai approfondito, non l'ho mai approfondito poi in realtà.Per esempio l'ho scoperto solo dopo, quando ormai non era più utilizzato, che era una sorta di dialetto di javascript.Nel senso che era molto correlato a javascript.Non mi ricordo esattamente in che modo adesso, però aveva una simpatica relazione.Se non mi sbaglio, non vorrei dire bestemmie, però aveva una sintassi ecma script.Quindi ritornava proprio...e poi come si era evoluto ad ActionScript 3 con la programmazione a oggetti spinta, il fatto che si era svincolato un po' dalla timeline e c'era tutta la gestione degli eventi.Cioè era diventato però una bella roba.Pensa che in azienda, era il primo periodo che io ero entrato a lavorare seriamente in azienda, ti sto parlando del 2007-2006, ero ancora all'università, facevo questi side project e era uscito Flex, forse anche 2008, non vorrei dire adesso le date sono poche.Era uscito flex che era una versione un pochino diversa rispetto a flash meno gaming ah si si si si si non mi ricordo non mi ricordo e ci avevo scritto diversi crm con Flex da una parte per tutto il front end e poi facevo delle funzioni adesso fa ridere questa cosa però facevo delle funzioni in php e le chiamavo con un protocollo simile rcp e quindi potevo interfacciarmi al database quindi accedere ai dati che stavano su Postgres con poche funzioni, un mondo che se pensiamo a come si è evoluto lo sviluppo sì sì a voglia, a voglia, sconfesso di voi ho paura che in alcune aziende quel software che ho fatto sia ancora in produzione volevo chiederti una cosa un po' particolare, noi ci siamo conosciuti in occasione come dicevamo prima di un evento legato alle community e volevo chiederti, questa parte mi interessa particolarmente, quanto le community hanno influenzato la tua formazione? LM: "Beh, parecchio in realtà.Ci ho messo un po' per capirlo.Infatti una cosa che dovrei consigliare più spesso alle persone un pochino più giovani che si affacciano a questo mondo e vogliono intraprendere la carriera in questa industria è di concentrarsi sulle community sin da subito.Io ci ho messo un bel po' e la prima community con cui sono stato veramente a contatto di programmatore è stata quella di Zen Framework.È stato lì che ho cominciato a utilizzare Git e GitHub per contribuire al framework, è stato lì che sono entrato a contatto con altre persone, sono entrato a contatto con il concetto di code reviewing, che per me era una cosa completamente nuova, e ho cominciato a imparare da altri erano molto più bravi di me.Alla fine la cosa più importante era proprio quella, cercare il confronto con persone che hanno più esperienza, che sono più capaci e che hanno tanto da insegnarti, una cosa fondamentale.Fino a un punto abbastanza avanzato della mia carriera, perché già facevo il freelancer da diversi anni, fino a quel momento ero sempre stato una sorta di lupo solitario, quindi per tanti anni in realtà io non ho fatto progressi così spediti, ero un po' trincerato, sempre nella stessa posizione, utilizzavo sempre gli stessi strumenti, sempre le stesse tecniche, magari leggevo qualche cosa, leggevo qualche libro, l'università un pochino mi ha dato una spinta a livello di fondamenti, però il confronto sul codice reale, sul codice di produzione con altri professionisti è una cosa che non apprezzo.Da lì poi è stato un po' un effetto a palla di neve, nel senso che ho cominciato a interessarmi alla community di questo framework, la community di PHP in generale, la community dei programmatori in senso più ampio e poi a frequentare magari meet up e cose nel momento in cui ho avuto la disponibilità a muovermi, poi finalmente me ne sono andato a Milano questa cosa l'ho subito coltivata perché finalmente ne capivo l'importanza.Quindi sì, sicuramente creare le community o comunque avere contatti con delle community è veramente fondamentale per la crescita professionale.Anche umana alla fine.Ho conosciuto un sacco di persone con cui sono molto amico tramite queste community.Beh, se non ci fossero state le community probabilmente in questo momento non staremmo parlando noi due, tra l'altro.Esatto.Tra l'altro.No, voglio farti questa domanda.È una domanda un po' particolare, un po' personale e che mi riguarda.La voglio scoprire.Nel momento, tu hai detto, io sono sempre stato per le mie, no? Non perché me la tirassi, ma perché probabilmente non avevo, non sentivo l'esigenza di confrontarmi.Il primo periodo che sei entrato a contatto con le community, hai mai sentito quella che si chiama la sindrome dell'impostore, cioè il fatto di andare a parlare con persone che ne sapevano parecchio più di te e sentirti quasi fuori luogo? Sì, ma soprattutto il motivo per cui in realtà io non avevo ancora avuto questo contatto non era per scelta, era proprio per ingenuità e inconsapevolezza.Non avevo idea che potesse essere uno strumento così importante, quindi non l'avevo mai cercato.Nel momento in cui ho cominciato ad avere contatti con altre persone, sì, senza dubbio la sindoma dell'impostore è stata una cosa di cui ovviamente ho sofferto molto.Anche l'ambito con cui mi sono scontrato, che nello specifico era un framework di livello enterprise, nel senso che era un framework abbastanza vecchio, aveva già tanto dei biotecnici, infatti da lì a poco poi uscì la versione 2 che era completamente riprogettata e io fui molto felice di partecipare ai lavori che avevano a che fare un pochino con questa riprogettazione.Diciamo che mi scontrai con tutta una serie di carico cognitivo, una quantità di carico cognitivo non indifferente e mi rendevo conto che ero molto indietro rispetto alle persone con cui interlocuivo, quindi mi sono un po' rimboccato le maniche e mi sono dovuto dar da fare per recuperare un pochino il terreno che non avevo guadagnato nel tempo in cui invece avrei dovuto farlo.Quindi sì, senza dubbio, è una cosa che comunque succede tuttora, nonostante ormai abbiamo quasi vent'anni di esperienza, la sindrome dell'impostore è un pericolo costante, perché non si smette mai di imparare e credo che l'unico modo per liberarsene veramente è prendere atto del fatto che fa parte di questo tipo di professione, di questa scelta professionale.Bisogna a un certo punto prendere atto del fatto che non si può sapere tutto e che la propria percezione di ciò che si sa è diversa dalla percezione che si dà agli altri di ciò che si sa.Quindi in questo modo si smette di pensarci, ma comunque rimane lì un pochino.Non se ne va mai completamente.Non è una cosa su cui ormai perdo più il sonno.Un tempo magari era una cosa che mi attanagliava un po' di più.In certe situazioni, soprattutto quando cerchi magari di cambiare lavoro, devi avere a che fare con dei colloqui tecnici eccetera, allora magari il senso del fallimento può acuire questa cosa latente perché alla fine io credo che quella è la sindoma dell'impostore sia una situazione che rimanga lì inlatente e che a volte emerga improvvisamente quando ci si scontra con qualcosa che immediatamente non si riesce a risolvere, qualche problema che non si riesce a risolvere perché non si hanno tutti gli strumenti per poterlo capire magari, di solito è per questo e quindi l'unico modo per approcciare la cosa è rimboccarsi le maniche, prendere atto il fatto che ognuno ha i propri limiti, sapere qual è il proprio e poi rimborcarsi le maniche per cercare di sopperire a questi limiti in un modo o nell'altro, può essere sia comprarsi il libro, spopparselo e farsi una cultura di quella cosa in particolare, oppure anche semplicemente chiedere aiuto a qualcuno che si sa essere un esperto in quella cosa in particolare e ce lo si fa spiegare come se si fosse un po' come i life vibe, come se si avesse 5 anni.Ci sono tante soluzioni al problema, non necessariamente il "fai da te" è necessariamente la strada da percorrere, però il problema rimane e rimarrà sempre.Bisogna solo prenderne alto.guarda è una cosa che ho ritrovato in molti il fatto che quando si entra nell'otica e nella spirale della sindrome dell'impostore spesso avere un mentore una persona di riferimento verso il quale sventolare la famosa bandiera bianca aiuta perché è quella persona che può anche non insegnarti niente dal punto di vista tecnologico e tecnico ma ti dice "Ehi Stefano, ehi Mauro, fermati qua, non rompere le balle, siediti un attimo, qual è il problema?" Quindi ti riporta quei piedi per terra e riesci a rimettere a fuoco un po' quella che è la strada.Quindi una cosa che io mi sento sempre di ripetere è quella di cercare il proprio mentore.Ed è naturalmente più facile cercare il mentore quando si frequentano delle community dove hai delle persone già di natura disposte ad aprirsi a te e a seguirti in qualche modo.In fondo dedicano il loro tempo anche a te.No quindi questa questa cosa del mentoring ritorna molto importante.Un'altra cosa che secondo me è importante quando sei in quella spirale alimentato dalla sindrome dell'impostore è quella di studiare compulsivamente tutto qualunque cosa ti passi sotto mano tu la studi e passi da un libro di javascript ad ASCEL e alla fine poi non trovi il focus.Qual è la strategia che utilizzi tu per fissare un fuoco e non perderti nel mare delle mille sirene del mondo dello sviluppo e del mondo tech in generale? In realtà non ne ho ancora trovata una, nel senso che io soffro molto dell'impulsività voler imparare praticamente tutto.Io ho la pretesa di non pormi nessun limite da questo punto di vista, nel senso che vorrei poter sapere fare le cose in tutti i modi possibili e vorrei poter imparare tutti i linguaggi possibili se solo ne avessi il tempo e la voglia anche, perché a volte non ne ho neanche la voglia.Quindi non ho veramente una strategia.Sicuramente quello che per esempio io vado professando in giro è l'idea di che bisogna comunque costruirsi uno skill set che abbia sia ampiezza, quindi sia di larghe vedute, sia che sappia scendere in profondità in alcuni ambiti in particolare.quello che chiamano lo skill set a forma di T, si parte da una panoramica orizzontale di tanti topic, che ne so, può essere la programmazione in generale, i sistemi operativi, i sistemi distribuiti, può essere la programmazione ad oggetti, si può aggiungere anche la programmazione multiparadigma e quindi anche elementi di programmazione funzionale in linguaggi multiparadigma e cose del genere.E poi magari scendere nel dettaglio, per esempio nel mio caso storicamente sono sempre stato molto più coinvolto con PHP, con la community PHP e con questo linguaggio perché ho cominciato da lì e perché ho fatto lo sviluppatore web per tanto tempo e quindi ero molto specializzato in PHP e anche JavaScript.E quindi diciamo che il mio set di skill era molto formality, mi piaceva anche fare il sistemista, quindi mi è sempre piaciuto smanettare un pochino con i server, con la loro manutenzione, come farli girare, come curarne il setup, quindi avevo questa sorta di approccio.Andando avanti cosa mi piacerebbe fare? Mi piacerebbe approfondire i linguaggi puramente funzionali come per esempio il C2U Askel, però non ho mai avuto la fortezza d'animo di cominciare il famosissimo tutorial Learn Me on Askel, non mi ricordo come si chiama, qualcosa del genere.In compenso, ad esempio di recente io ormai lavoro quotidianamente con Go, e quella di Go è stata per me un pallino costante, volevo imparare Go, volevo lavorare con Go, ma non ne avevo mai mai l'opportunità, perché poi alla fine bisogna scontrarsi con il fatto che una giornata a 24 ore e non necessariamente uno finita la propria giornata lavorativa di 8 o più ore dove si è scritto codice, si ha la voglia di sedersi di nuovo davanti al computer e imparare un altro linguaggio ancora.Quindi senza dubbio è una cosa che non è per tutti, nel senso che non è necessariamente desiderabile, però è una cosa che sicuramente serve.Per esempio io sono tra quelli che dicono che bisognerebbe conoscere almeno cinque linguaggi di programmazione diversi e possibilmente diversi tra loro come paradigma, quindi magari un linguaggio dinamico, un linguaggio statico, un linguaggio compilato, un linguaggio funzionale, un linguaggio strutturato, cose del genere.Quindi mi piacerebbe, neanche io ci sono arrivato ancora, fondamentalmente perché mi manca proprio Haskell o qualcosa del genere, o Lisp per esempio, volevo imparare Clojure scritto, qualcosa di simile insomma, o Elixir, Erlang, non so di che parola dicevo, mi piacerebbe impararli tutti, quindi se fosse per me studierei uno dopo l'altro.è che anche per imparare veramente un linguaggio non basta farsi il tutorial.Tutorial me ne sono fatti mille, mila e per imparare veramente un linguaggio poi bisogna utilizzarlo per creare un progetto vero.Bisogna continuare a utilizzarlo poi perché si fa presto a dimenticarseli.Io per esempio ho utilizzato javascript per tantissimo tempo ma adesso ne ho perso un po' il contatto perché non faccio più frontend nella mia vita.Io sono stato full stack tra virgolette per tanto tempo, poi mi sono gradualmente allontanato dal front end, e adesso ho completamente perso contatto sia con la community sia con gli stack tecnologici che ci sono.Nel frattempo sono andati avanti in maniera super rapida ovviamente e quindi mi rimangono quei fondamenti abbastanza solidi di javascript e vanilla.È qualcosa sui primi framework MVC che cominciavano a vedersi, perché quando io ho cominciato non fare più front end development, era il tempo in cui c'era la santissima trinità dei framework che erano Backbone, Angular 1.4, Backbone e qualcos'altro non mi ricordo, React ancora non era uscito.JQuery che non era un framework però...No, no, io ti parlo, c'era una santissima trinità dei framework MVC, no, era EmberJS, EmberJS Backbone e Angular, era la santissima trinità dei framework MVC.Già JQuery, questi tre erano la risposta al non usare più JQuery.Da lì in poi, dopo l'uscita di Angular 2 gradualmente mi sono un po' disinteressato, perché non non ho avuto neanche le esigenze utilizzate nel mio lavoro quotidiano e quindi adesso non saprei neanche da dove cominciare.A me non mi interessa più di tanto perché alla fine, in realtà, quello che ho imparato facilmente a livello concettuale si può applicare, a parte i concetti Reactive Programming che sono stati portati per la maggiore da React, che però poi ho studiato in PHP perché invece utilizzato cose tipo RxPHP proprio perché hanno cavalcato un pochino quest'onda.Sì, ma alla fine… Sono oggetti che si trasportano tra un linguaggio e l'altro.Una volta che impari i paradigmi riesci a proiettarli nella tecnologia.No, per quanto riguarda i linguaggi, mi piace ricordare questa cosa, è una riflessione che facevo proprio l'altra sera con mia moglie.Noi avevamo un'amica che faceva la poetessa, no? E questa donna, non c'entra niente con i linguaggi però è un ragionamento che abbiamo fatto insieme ragionando anche in termini di linguaggi di programmazione.Questo perché in realtà lo ancoro un po' alla concretezza.Da qualche tempo lei è una sviluppatrice Scala quindi nel suo stack Scala lavorando nei big data è un elemento ricorrente e io ho detto mi avvicino alla programmazione funzionale però la programmazione funzionale pure mi spaventa quindi ci faccio la strada lunga per arrivarci e Scala più o meno abbraccia anche la programmazione funzionale in modo serio no? e quindi ho iniziato a vedere un po' la programmazione funzionale e più provavo tra l'altro ho fatto abbiamo fatto insieme il corso con Odeschi mi sa che si chiami il fondatore di scala, che era un corso di programmazione funzionale in scala, piano piano percepivo uno shifting mentale.Il mio modo di pensare non cambiava ma si ampliava e mi è venuto in mente il ragionamento che mi ha fatto questa amica Vittoria che diceva "guarda che fondamentalmente le parole, il dizionario che tu usi è anche il dizionario che tu usi per pensare.se tu estendi il tuo dizionario tu hai più opportunità per estendere il tuo pensiero e quindi questo ragionamento, lei veniva dalla poesia, però è facilmente applicabile alla tecnologia con l'inserimento, anche se in un livello basico di scala con un approccio funzionale il mio modo di scrivere PHP si è sconvolto Cioè, usare le closure in PHP è diventato di default, cioè quasi non pensavo più a risolvere i problemi utilizzando i classici pattern, ma dicevo "ma cavolo, perché devo scrivere 70.000 righe di boilerplate quando basta una funzione?" Adesso sto banalizzando un po' il ragionamento.LM: No, è verissimo.È proprio per questo motivo che bisognerebbe imparare tanti linguaggi, perché danno prospettive diverse nei confronti degli stessi problemi alla fine, perché i problemi che si affrontano alla fine con la programmazione spesso si assomigliano un po' tutti tra di loro, almeno per grandi linee.Mentre invece le sintassi dei linguaggi e anche i paradigmi dei linguaggi variano in maniera abbastanza profonda.Io ultimamente sto facendo lo stesso esercizio identico che appena descritto, lo sto facendo passando da Go ad altri linguaggi, per esempio quotidianamente io adesso utilizzo molto Go e poi ogni tanto anche Python, per esempio, Python ormai non lo sopporto più da che era uno dei miei linguaggi preferiti, passare da un linguaggio super stretto, tipizzato compilato molto statico come Go e poi passare a Python dove invece puoi scrivere tutto e cotere di tutto, non lo tollero più e quindi cerco le stesse soluzioni tecniche in un linguaggio dove in realtà non appartengono.Quindi poi bisogna anche ricordarsi di sfruttare i punti di forza di ogni singolo strumento che si sceglie, quindi se si usa un linguaggio dinamico bisogna utilizzarne la dinamicità, non c'è niente a fare.Questo è un esempio di uno dei motivi per cui io non ho mai approfondito molto Ruby, sebbene l'abbia utilizzato un pochino perché abbiamo avuto a che fare con delle applicazioni scritte con Ruby on Rails in passato, però è stata un'esperienza che non ricordo assolutamente con piacere, perché non mi piacciono questi linguaggi un po' troppo magici, un po' troppo ambiqui.anche CoffeeScript soffriva un pochino di questo stesso problema.LM: ha una croce sopra grande come il mondo! DLL: l'ambiguità secondo me nella programmazione è un concetto sorpassato.Secondo me è andato di moda circa una decina di anni fa, quando si cercavano soluzioni molto creative a problemi che i linguaggi vecchi non riuscivano a risolvere o meglio rendevano un po' difficili a risolvere, rendevano un po' macchinosi a risolvere, ma in realtà secondo me non era un problema dei linguaggi evidentemente, era un problema di fondamenti, di pattern, di strutture, di come si utilizzavano i linguaggi vecchi, perché se vedi invece come si risolvono quegli stessi problemi oggi con linguaggi molto più restrittivi, si trovano soluzioni molto più semplici e quindi molto più eleganti senza coinvolgere meccanismi supermagici, tipo quelli Ruby che fa monkey patching in run time o scatole cinesi di robe che cercano di farlo, di fare un'operazione che cercano di fare assunzioni a proposito di quello che il programmatore vuole.La maggior parte delle volte la spuntano, però poi appena esci fuori da alcuni parametri descritti, esplode tutto e non riesci più a fare niente, ti ritrovi bloccato.Bisogna conoscere i punti di forza? Rimangono comunque i punti di forza per i linguaggi dinamici e tipizzati in maniera molto alasca, secondo me rimarranno a lungo, ma secondo me si comincia ad apprezzare un po' di più le filosofie che vengono portate avanti da linguaggi come Go, come Rust, l'eleganza nella progettazione dei linguaggi stessi e l'eleganza che poi si trasferisce un pochino tramite convenzioni abbastanza restrittive, messe in piedi dalla community sin da subito, perché per esempio una delle cose di cui soffrono i linguaggi più classici, tipo C o Python stesso, è che siccome le community erano ancora un po' immature, non avevano messo su delle convenzioni sin da subito, le convenzioni sono arrivate un po' dopo, a posteriori, quindi già un pochino la frittata era fatta e l'ecosistema un pochino era il Wild West già di suo e è difficile recuperare.Mentre invece i linguaggi, quelli un pochino più giovani, quelli più moderni usciti negli ultimi dieci anni, hanno già un ecosistema molto più solido perché si è capito...Si portano presso l'esperienza.Esatto, da subito si fanno le cose con un'impostazione già con degli obiettivi ben precisi e predeterminati, è una cosa che secondo me aiuta.Anche se su questo voglio farti una provocazione, ma la rimando a dopo, però tieni questa cosa in sospeso perché ti devo chiedere questa cosa anche un po' provocatoriamente.Prima di passare però, abbiamo già fatto una bella introduzione sui sui linguaggi, abbiamo iniziato a parlare appunto dei linguaggi, però volevo chiudere un attimino la passeggiatina nel tuo percorso professionale.Tu sei partito lavorare dalle agency.La tua carriera è iniziata con le agency e è passata per le start up e adesso lavori per un colosso tecnologico possiamo chiamarlo così no? Raccontaci un po' In realtà non è proprio un colosso alla fine, col senno di poi, perché tra l'altro adesso che l'ho conosciuto ha ancora meno le proporzioni ancora, è una grossa corporazione.Raccontaci il percorso però dal punto di vista professionale, nel senso le sfide, probabilmente le paure perché in questo tipo di percorso certe volte ti trovi anche a dire "ma fa per me? sono sono all'altezza della sfida che mi si sta proponendo?" anche perché so che tu hai cambiato completamente lo stack tecnologico in questo percorso quindi doppia sfida.Era proprio la sfida che cercavo, era proprio quello che desideravo, quindi il cambio di stack tecnologico era la cosa minore, nel senso che ti puoi preparare per quello e me ero già preparato per questo, nel senso che avevo già capito che continuare a focalizzare l'offerta di valore in quanto dipendente, in quanto professionista su sempre lo stesso tipo di tecnologie e lo stesso tipo di problemi, perché poi alla fine queste due cose vanno un po' a bracetto, nel senso che io continuavo ad essere noto nella comunità di PHP e quindi lavoravo soprattutto con perditori di lavoro che erano interessati a quel tipo di skill set, perché ciò di cui avevamo bisogno era quello per cui PHP è molto utilizzato, cioè lo sviluppo web.Quindi a un certo punto ho capito che per staccarmi da questo circolo un pochino vizioso, che continuo a fare sviluppo web e quindi continuo a utilizzare PHP e quindi quindi sono sempre più bravo con PHP e quindi mi chiedono PHP e quindi sono desiderabile per fare lo sviluppatore web.Insomma, dopo un po' questa cosa mi è cominciata a stare stretta proprio perché avevo questa passione per l'aspetto sistemistico dell'ingegnere del software e quindi la gestione e anche lo sviluppo proprio dei sistemi, in particolar modo quelli di larga scala.Proprio di recente ho raccontato in un altro podcast di come io a un certo punto nel corso della mia carriera, dopo aver lavorato per web agenzie pubblicitarie, etc.volevo lavorare a qualcosa di più grosso e quindi mi è cominciato questo tarlo del voler lavorare per uno degli hyperscalers, quindi o Amazon o Google o Microsoft.Si ricordo che quando ci siamo conosciuti preparavi l'interview per Google.Esattamente.Ho avuto questo tarlo per molto tempo, in realtà un pochino ce l'ho ancora, perché SUSE alla fine non è esattamente un hyperscaler, anzi è molto lontano da esserlo, però la struttura comunque è sempre quella della grande corporazione, quindi al quanto meno dal punto di vista del business sono un pochino più vicino a certe logiche di gestione dell'ingegnere software e dell'industria del software in generale che mi stanno un pochino dando pace a quella ricerca spasmodica di questo tipo di sfide.Però è un tipo di ambito che, soprattutto quello dei hyper-scalers, perché una cosa è passare dalla web agency, quindi già dallo sviluppo web, a un ingegnere del software un pochino più ad ampio spettro, nel senso che ti proponi per fare qualcosa e ti chiedono e non sai esattamente cosa ti chiederanno, nel senso che io ho fatto colloqui per aziende che facevano application performance monitoring o anche messaggistica istantanea o anche come faci le brokering assicurativi e di servizi finanziari, insomma tutti gli ambiti possibili immaginabili.Non era tanto l'ambito che mi interessava, nel senso che a me la cosa che più mi stimolava era il lavorare nell'industria del software per l'industria del software, quindi volevo un po' sganciarmi dal concepire il software come un mezzo per un fine, ma il software doveva essere il fine stesso, questa era la cosa che mi stimolava tantissimo.E poi la scala dei problemi, volevo affrontare problemi dove una sola persona non potrebbe mai risolverli, volevo scontarmi con delle realtà dove il team working, ma neanche il team, perché la collaborazione tra tanti team, collaborazioni di ampie vedute si rendono non necessarie e quindi la coordinazione tra un numero molto grande di persone, raggruppate in diversi gruppi e quindi anche strutture organizzative un pochino più grandi era qualcosa che io volevo un pochino cimentarmi, volevo approfondire.Fortunatamente dopo tanti anni di colloqui andati male, per un motivo o per l'altro, c'è stata anche una buona dose di sfortuna.Alla fine, inaspettatamente, sono finito da Suse, dove ricordo di aver mandato il curriculum tra l'altro così, giusto per pescare un pochino nel mucchio.Non era per niente un'azienda che avevo puntato, però devo dire che è stato un po' la classica botta di culo, non so come descriverla.Non la botta di culo mi hanno assoluto la botta di culo, che si è trovata a collimare esattamente con quello che io cercavo, sia a livello di stack tecnologico che di sfide proprio a livello professionale e di carriera, e anche come opportunità di crescita.A costante di poi è anche un pochino più equilibrata come situazione lavorativa rispetto a quella che poteva essere invece un impiego presso un hyperscaler, perché se teni a lavorare per Amazon sei uno tra 150 mila dipendenti o giù di lì, non lo so, devono assumere altri 100 mila, quindi non so a quante sono arrivati.In piena pandemia il CTO di Amazon ha annunciato "vogliamo assumere 100 mila persone".LM: "Beh, hanno aperto a Milano da pochissimo, no?" hanno aperto la zona di AWS o la devono aprire a breve? No, è aperta.Ah, è aperta proprio.Quindi sì, probabilmente anche Milano finalmente diventerà un hub di sviluppo, anche se all'inizio di solito cercano sistemisti quando devono occuparsi dell'apertura delle zone.Però sì, il pensiero con Amazon è che diventi un numerino molto piccolo e il contributo che puoi dare lascia un pochino il tempo che trova nel senso che...L'automazione di distributore di cartigieni nei bagni è già un ruolo...Esattamente, esattamente.Stiamo scherzando però in realtà sì, alla fine là si è una goccetta.Anche in ottica di, proprio anche se la vogliamo mettere, di sviluppo personale probabilmente è molto più difficile.La competizione è probabilmente ancora più agguerrita, non che quello sia un male, per carità, anzi, per alcune persone può essere anche uno stimolo, una cosa desiderabile.Non so come riassumerti tutta la trafila che feci, sin da quando noi ci siamo conosciuti, perché di colloqui ne ho fatti veramente tanti e fondamentalmente la totalità di essi andarono male.Ne ho fatti veramente tanti, quindi mi ricordo alcuni casi in cui ci speravo veramente moltissimo e debita subito, proprio sin dalla sede del colloquio, di solito la struttura di questi colloqui era tutta che mimava un pochino quella dei colloqui alla Google, cioè le classiche Whiteboard interview da 5 ore, un fight dopo una trafila di settimane di colloqui tra test tra test a risposta multipla o anche il compitino a casa dove devi sviluppare una piccola applicazione o le domande a bruciapello al telefono tipo come si implementa una lista.Tra l'altro dove trovi tantissima teoria e comunque devi conoscere i fondamenti di teoria e di framework credo non ti abbiano chiesto niente.L'unico forse che potevano essere interessati a Framework e che non mi hanno neanche voluto passare lo screening iniziale mi pare che furono quelli di GitLab, quando ancora GitLab non aveva neanche un round B, era un round A di investimento, quindi era minuscola.Adesso non so a che round sono gli investimenti, ma è molto più grande ed è un business attivo è molto molto promettente dal punto di vista.Tra l'altro io avrei scommesso che il famoso problema che ebbero, credevo che avrebbe mandato tutto all'aria, ricordi no? Sì sì, vero vero.Invece sono stati abilissimi a gestire il tutto con una precisione, io ricordo sessioni di live debugging su YouTube dove c'era un team che lavorava in diretta.Sì, sono molto gansi, non so come dire, gagliardi, però mi ricordo che quando mandai la mia application, la mia candidatura, specificai tipo "guardate io non sono un esperto in race perché la job description richiedeva esperienza in Ruby on Race specificatamente" e diceva chiaramente se non avete esperienza in Ruby on Rails non applicate perché cerchiamo gente che sa usare Ruby on Rails.Però a me questa cosa non poteva passare perché io ero già che accarezzavo non quanto oggi ma accarezzavo già l'idea e il concetto che una volta che sai usare un framework MVC bene o male sono tutti uguali, una volta che sai usare un linguaggio dinamico bene o male.Due giorni di lavoro ti impari l'assintassi.No, magari non due giorni, però comunque in un tempo che è paragonabile a quello di un onboarding qualunque, perché alla fine per un onboarding indipendente nuovo comunque un paio di settimane ci vogliono.Insomma, in un paio di settimane, bene o male diventi produttivo a prescindere dallo stack tecnologico se sei uno che già ci sbatte su queste cose da tantissimo tempo.Quindi mi proposi lo stesso e lo specificai nella mia telepresentazione, dissi proprio in maniera molto chiara e trasparente "guardate, sono in realtà specializzato in PHP, però vedete io conosco questo framework che è la copia spiccicata di Ruby on Rails, guardate, ho fatto il quick start di Ruby on Rails e ci sono trovato perfettamente a mio agio, nel senso di abilità, perché in realtà non mi piaceva, però ovviamente me lo sono devuto per me questo, però loro proprio non ne volevano completamente sapere.No, noi cerchiamo solo persone che hanno già tantissima esperienza con questo stack.Secondo me è un pochino...forse adesso hanno cambiato perché ad esempio, col senno di poi, adesso che sono molto ferrato con Go, metà del loro stack adesso in realtà è in Go.Nel senso che ora hanno GitLab, la vecchia applicazione, proprio quella di produzione, che è un'applicazione RubinRace, ma tantissimo del resto della loro produzione software è scritto in Go perché hanno a che fare con tanti sistemi di automazione, per esempio GitLab Runner, il loro runner della CI è scritto in Go ed è un progetto di cui io ho aperto i sorgenti tranquillamente e ho anche partecipato a qualche bug fix in passato o qualcosa del genere.Cioè insomma se mi prendevano di certo non stavo salutando a un monitor con il punto interrogativo sopra la testa.Sono un po' approcci anche dal punto di vista della gestione del personale, che prescindono un pochino dalle competenze tecniche.Le persone veramente tecniche non hanno neanche tutto il suo potere decisionale quando si tratta di questo genere di cose.Ho dovuto fare spallucce tante volte per questo genere di motivi.però sai che è importante quello che stai raccontando? perché spesso nelle interviste si dice, si parla delle interviewe, di solito "ah è andata benissimo, mi ha chiesto, è andata grande, tutto fantastico" invece raccontare questo b-side dove in realtà i tentativi non sono lancio un dardo e vado subito in centro no, per niente, anzi...e ogni tentativo ti costruisce quella knowledge, quella conoscenza non solo dal punto di vista tecnologica perché ti apre comunque degli spazi da approfondire ma anche dal punto di vista di soft o core skill, chiamiamole come preferiamo, no? Di come approcciarti a un'altra persona, di come gestire la differenza di livello nella comunicazione perché un esaminatore, un recruiter è sempre un recruiter e si mette necessariamente su un gradino più alto del tuo e quindi sono comunque quelle esperienze che è giusto, pur essendo negative, sono quelle esperienze che hanno fatto Stefano, hanno formato Mauro, vabbè io non ho mai provato intervisti, interview da questo punto di vista, perché mi sono accontentato della pagnotta nella mia azienda.Non si può mai sapere, non si può mai sapere.Ma sì...Magari un domani, non è mai troppo tardi per cambiare per questo genere di...mai dire mai però ti posso dire che per esempio ho vissuto di riflesso le esperienze da mia moglie e quindi vedevo come si preparava come tornava e sentivo anche le interview che faceva insomma che insomma ti danno un inquadramento.Però passiamo allo stack tecnologico quindi tu sei passati e sostituito la tecnologia PHP con uno stack più improntato sull'utilizzo di Go, anche se io credo che PHP rimanga sempre nel tuo cuore.Quali sono le caratteristiche che ti hanno fatto innamorare di PHP e quelle che ancora stimi di PHP? In realtà non c'è nessuna caratteristica che mi ha particolarmente fatto innamorare, è stata semplicemente la prima cosa con cui mi sono cominciato a sporcare le mani realmente.Quindi questo è stato assolutamente un caso, credo.E' anche vero che PHP aveva un livello di entrata abbastanza basso, quindi come me tantissime altre persone hanno cominciato la programmazione di PHP tramite PHP.Quando cominci non sei ancora constatevole, non è mai una scelta consapevole, non è che stai scegliendo PHP perché ha terminato i fichari.Esatto, è semplicemente perché ci capiti, perché cerchi su Google web programming e ti spunta PHP come linguaggio, qualcosa del genere, insomma, magari non esattamente.In linea di massima è quello.Mentre invece dopo un po' che lo usi, dopo 15 anni magari che ci lavori e ci campi.Ovviamente VHP ha tantissimi difetti, ma il peggiore non è tecnologico e su questo ci torniamo dopo.Io credo che sia tutt'oggi un'ottima soluzione per lo sviluppo web, per un motivo tecnico a cui si arriva dopo tanto tempo, per il modello per il modello di gestione della memoria, il modello share nothing dei processi, ogni richiesta web nasce e muore in un suo contesto e non condivide niente con nient'altro.Questa secondo me è la caratteristica singolare che rende il PHP unico e desiderabile tutt'oggi, perché tutti gli altri linguaggi porteranno chiunque li utilizza a scontrarsi con il concetto di stato è stato condiviso tra un'ichess e l'altra in un'applicazione web.È un problema che è risolto, è noto, ma non è un concetto banale.Quando si comincia il non dovere a che fare con questo concetto è un po' un arma a doppio taglio, perché da un lato non ti stai neanche prendendo questo problema, dall'altro, per esempio, un programmatore che utilizza solo PHP per tanto tempo rimane completamente ignaro che esiste una cosa come gestione della memoria perché non devi farne praticamente anche se ci sono memory leak codice PHP non te ne avrei...Tanto la richiesta e il processo di richiesta risposta che è l'ossatura centrale di PHP quello è una volta che hai dato la risposta ti puoi dimenticare di tutto anche se devo dire che ne abbiamo parlato in una puntata del podcast gli sviluppatori PHP si stanno impegnando per introdurre quei problemi con tecnologie come ReactPHP React è stato uno dei compici nel farmi capire che dovevo allontanarmi del PHP, perché volevo cominciare a fare delle cose per cui PHP non è stato progettato, tra cui i long running processes, robe tipo daemoni, processi di sistema.Ci sono delle librerie molto creative che aiutano la programmazione asincrona come idea in generale, per esempio, è una cosa che mi ha affascinato tantissimo, ed è una cosa che aiuta molto i programmatori che fanno web perché è esattamente identica a livello concettuale a quella che c'è in javascript, il modello di asincronia che c'è è esattamente lo stesso, le librerie che ci sono in PHP utilizzano lo stesso pattern, cioè quello dell'event loop, il reactor, le promise come playsolder di valori futuri di cui ancora non si conosce esattamente il contenuto, cose del genere.E quindi anche un pochino i paradigmi funzionali si introducono perché bisogno di alcune strutture che sono quasi che ricordano le monadi, anzi la promise in realtà è una monade, però ovviamente uno lo sa, uno comincia a utilizzare una monade senza sapere cosa è una monade.Cioè è molto interessante, è un ambito molto stimolante, però va alla fine ti scontri con problemi di impostazione fondamentale, vale a dire che PHP non è nato per questi tipi di workload, quindi per quanto si possa fare, tra l'altro io l'ho fatto anche a livello professionale, nel senso che da facile io per esempio facevo questo, da facile io dovetti progettare un sistema che era un processo di sistema che era scritto in PHP e utilizzava React per quasi tutto l'Io, era tutto improntato sull'Io non blocking.Però ti ritrovi a scrivere codici in PHP che PHP non sembra, quindi era anche una cosa che aveva un carico cognitivo associato ad esso, che non necessariamente… cogliamo un po' di sorpresa magari persone che non erano abituate a questo tipo di applicazioni.Quindi perché non utilizzare qualcosa che sin da subito è nata come idea per risolvere questo tipo di problemi? Questi nuovi linguaggi che hanno delle primitive sulla concorrenza e sul multiprocessing molto ben strutturate e sin da subito progettate in maniera molto semplice e quindi Goel e LXIR per esempio sono i primi che mi vengono in mente, ma anche Rust.Questo tipo di problemi vengono risolti in maniera molto più semplice, molto più agile.Insomma, ripeto, è una cosa che si può fare per uno che è appassionato di PHP, si fa anche perché ti piace utilizzare il tuo strumento preferito per risolvere quel problema, però è un pochino tirarne la corda secondo me.una delle giustificazioni che danno molte società che implementano queste tecnologie è quella di dire ok introdurre una nuova tecnologia nel nostro stack tecnologico forse è un po' sovradimensionato cioè presuppone un carico verso il team che ha un certo costo e quindi utilizziamo la chiave inglese per mettere il chiodo perché bene o male alla fine il chiodo nel muro entra.credo che fu proprio il caso di Faci, nel senso che per Facile cominciare ad assumere persone che erano competenti in un altro stack era troppo complicato proprio a livello organizzativo, nel senso che se tutta la tua trafila per esempio di hiring è tutta incentrata su uno stack tecnologico e quindi tu hai dal recruiter di primo contatto fino a chi esamina i candidati che sono tutti stati accentrati su quello stack tecnologico, cominciare con un altro stack tecnologico è tutta una sorta di problemi nuovi che devi affrontare, quindi non necessariamente praticabile.Quindi è comprensibile come scelta, per carità, non la critico come scelta in sé, però considerando di poi le cose secondo me si dovrebbero fare in maniera alternativa, nel senso che per esempio, affrontare i processi di hiring su un particolare stack tecnologico è un problema, quasi un peccato capitale, nel senso che secondo me la forza lavoro deve essere eterogenea e eclettica sin dall'inizio.LM: E dinamica.Anche i professionisti che tirano dentro.DLL: Esatto.Il problema è dinamica, nel senso che con l'abilità di cambiare stack tecnologico, beh sì, ovviamente lo sono un po' e alla fine un po' tutti, nel senso che se assumi persone intelligenti probabilmente saranno in grado di cambiare stack tecnologico.Il problema poi è fare l'assessment di questa nuova roba che stai facendo, nel senso che hai bisogno poi di un consulente esterno che validi quello che stai facendo se non hai il know-how già internalizzato.Mentre invece avere più know-how possibile, internalizzato sin dall'inizio, credo che sia una mossa più appropriata, capisco che sia più difficile e probabilmente anche più costoso e probabilmente bisogna anche ritrovarci, nel senso che magari non cominci con un CTO.Da quando sei una startup di 5 persone il tuo CTO non necessariamente e un ninja che conosce mille miglia di linguaggi e quindi ti sa assumere un team leader che è super skillato in quello che ti interessa e un altro team leader che è super skillato in un'altra cosa completamente diversa.Cerchi quello un po' più pragmatico che ti porta e che ti riduce il time to market.Esattamente esatto si scende a questo tipo di compromessi per ragioni più che valide ripeto però se dovessi ragionare in un'ottica tecnologica bisogna trovare un equilibrio probabilmente, bisogna trovare una soluzione più equilibrata e sbilanciarsi tutto sul focus in un singolo stack tecnologico secondo me è una cosa che non funziona quasi mai, nel senso che se tu vedi gli esempi più celebri di successo, storie di successo non sono mai focalizzate su uno stack tecnologico in particolare, le più grandi diciamo Silicon Darling della Silicon Valley non sono quasi mai associate a un particolare sito.Guarda io posso portare la mia esperienza, ne parlo spesso nel podcast, ho scritto un piccolo software, un mio site project che adesso è in produzione e sta comunque producendo, che si occupava di media listening, quindi andava a fare la scansione tra le testate nazionali, era un progetto che ho fatto da solo.quindi la domenica sera per capirci e se guardo quello stack alla fine mi vedo in front end un un laravel poi con tutti i problemi che ha laravel però in una settimana io ho fatto tutto.Laravel e Vue io in una settimana avevo il prodotto, il prototipo e ancora è prototipo.Lo scraping ho detto sì lo faccio in php ma è un po' troppo verboso.Oh fantastico python c'è questa libreria fatto.In PHP magari ci avrei messo un mese perché avrei dovuto usare librerie che non sono agili come le librerie di scraping che ci sono per Python che ha scrape e tiri giù o per farci un po di machine learning sopra.Basico è stato fantastico quindi se già nel site project ti rendi conto che è uno stack un pochino eterogeneo poi non sono un ninja in nessuno di questi linguaggi.Cioè Vue.Vue.js l'ho imparato facendo questa applicazione.Vux, il gestore dello stato.Ci ho sbattuto il muso.Perché non l'ho fatto in React? Perché volevo vedere Vue.È un side project, me lo posso permettere.Però se tu vai a vedere anche questo piccolo stack è eterogeneo e questo aiuta di più le società.Torniamo un attimo a PHP.che questa domanda è un po' cattivella.Secondo te quanto dello sviluppo di PHP e di peso, perdonami, dell'adozione di PHP e di peso dallo sviluppo del linguaggio del suo interprete e tutto del suo ecosistema e quanto invece da framework come Laravel e Symfony? Non saprei, bisognerebbe… quello che ti posso dire è un po' un'opinione.La sensazione, sì mi interessa la sensazione.Sì, credo che… soprattutto l'Aravel, l'Aravel dietro Taylor Hotwells probabilmente doveva fare il VP di marketing per una super mega corporazione, perché dal punto di vista di marketing sicuramente ha spaccato.infatti guarda gli utili.Non li so gli utili, però penso che non se la passi affatto male.Ci sono tanti utili quanti anti-pattern.Esatto, che tra l'altro è un po' la storia, una breve storia triste, nel senso che poi alla fine il valore tecnico delle cose passa un un po' in secondo piano rispetto invece all'abilità di saperle vendere.Però sì, sicuramente l'Ara Velora come ora è un po'… negli ultimi anni è stato molto trascinatore alla comunità di PHP.Secondo me anche la spinta che hanno dato gli internals però ha grandi meriti, perché lo sviluppo di PHP da quando è uscita la 7, anche da quando è uscita veramente spettacolare, è stato iperbolico.Adesso abbiamo un po' di aspettative con la 8 e con il Just In Time.Tra l'altro, tra l'altro.Però è passato dall'essere un linguaggio di scripting un po' una cozzaglia di rapper nati dalla volontà di sostituire quello che c'era al tempo quando è nato, che era Pearl, Ponzi, Ponzi, po po po.Insomma, sebbene Erasmus in persona, io l'ho chiesto all'ultimo PHP Day, ha smentito questa cosa, nel senso che non è vero che lui voleva sostituire Perl, però comunque ha detto sì, effettivamente ai tempi se facevi una pagina web probabilmente ti finirei ad utilizzare Perl e io non volevo utilizzare Perl.Però non era la mira di PHP.Di fatto era un'alternativa a Perl ed è passato quindi da essere una semplice l'alternativa perla ad essere un linguaggio multipurpose, oggetto oriented, fortemente tipizzato con tantissime belle astrazioni, un ecosistema, soprattutto l'ecosistema dopo che è uscito composer.LM: Composer Giordi ha fatto un capolavoro.GZ: Esatto, è stato veramente un capolavoro e tuttora probabilmente è il sistema di gestione delle dipendenze che preferisco rispetto proprio a qualunque altro, non ce n'è nessun altro utilizzato finora.Ti confido che una delle cose che più mi ha spaventato è il fatto che non trovavo una logica, venendo dal mondo PHP o comunque anche dal mondo JavaScript con NPM, che fa il suo porco lavoro nonostante, diciamo, con Dino si stia provando a evolvere, ma quello ne parleremo in un altro episodio probabilmente.Anzi probabilmente quando uscirà questa puntata ne avrò anche già parlato.Però devo dire che è una delle cose che mi ha spaventato di più Digo.Eh sì, ci hanno messo un pochino per capire questo problema.Un po' di anni fa la situazione era terribile perché è migliorata moltissimo nell'ultimo anno, almeno tre anni fa, quando è uscito Vigo che è integrato nel toolkit nativo, quindi ha un gestore delle dipendenze, quando tu installi Go ha già un gestore delle dipendenze, prima non c'era questa cosa, dovevi utilizzare DEP o qualche altra cosa, c'erano diversi, risolvevano tutti lo stesso problema ma tutti in maniera non massimilamente efficiente, e quindi adesso è risolto bene o male questo problema, nel senso che utilizzi questo Vigo, questo gestore delle dipendenze che è molto ispirato in realtà a robe come cargo, come compose stesso, non necessariamente ispirato a alcuni dettagli che sono diversi, l'algoritmo di risoluzione delle dipendenze è completamente diverso, alcune peculiarità che lo rendono un un po' quirchi per alcuni versi, però alla fine fa il suo dovere e la gestione di dipendenza non è un problema da risolvere in go.Fine.Cioè nel senso non ci devi più pensare.Non c'è più il vendoring, non devi più committare la vendor dentro i repository, cosa invece bisognava fare prima.Questa già mi tranquillizza.No, credimi, è uno dei motivi per cui...C'avresti pure ragione che è uno dei motivi, è terribile questa cosa.io approccio in modo del tutto irrazionale i linguaggi, no? Ci butto un occhio, mi faccio affascinare e vedo se il fascino supera il momento zero, no? Se dopo una settimana sto ancora pensando a Go, che è per esempio una cosa che ho un fascino che adesso ho verso Rust, no? Voglio provare, voglio vedere, voglio approfondire.Però se mi dura più di una settimana, infatti adesso mi trovo nel momento in cui ho messo un attimo nel cassetto vedo se tra una settimana ho questo fascino allora mi rimane.E sono due le cose che mi hanno spaventato di Go.Il primo era a suo tempo la gestione delle dipendenze.Il secondo era i nomi delle variabili.Fermati un attimo.Aspetta perché questa crei quando da quando so che programming Go questa domanda era la domanda che volevo farti.Mi ricordo che quella cena famosa che facciamo a Verona parliamo delle delle del secondo me uno perlomeno per quanto mi riguarda delle bibbie dello sviluppo che il libro di uncle bob che praticamente prende a martellate la testa degli sviluppatori cercando di spiegare che i nomi devono essere auto esplicanti e le convenzioni devono essere il minimo possibile poi io mi son trovato a buttare un occhio al quick start di go e perdermi e qua mi è venuta una battuta in realtà l'ho rubata dalla rete ma secondo me ci sta a pennello no? Se noi abbiamo una variabile che indica un cane in PHP la chiamiamo dog, in Java la chiamiamo bellissimo animaletto baffuto con la coda perché sai la verbosità di Java, in Go la chiamiamo dì.Perché questa scelta? Esiste un motivo che ha spinto la comunità a a virare in persona questa scelta? Allora, innanzitutto ti anticipo che mi scontro quotidianamente con questo problema, nel senso che ogni linguaggio ha poi il suo modo di essere utilizzato e non puoi martellare delle convenzioni che portano da un linguaggio all'altro, di solito non funziona, i risultati finali poi sono pessimi, perché hai un codice che risulta poco leggibile e poco comprensibile per gli altri e lo sarà probabilmente anche per te, perché man mano che continui ad utilizzare sempre lo stesso strumento, poi le meccaniche di quello strumento ti domineranno.Il motivo per cui esiste questa convenzione è semplicissimo.Go è nato dalle stesse persone che hanno creato Unix e hanno creato C.Quindi Go è nato, lo chiamano, credo che qualcuno su internet definisca come il risultato di una storia d'amore tra C, C++ e Python, qualcosa del genere.In realtà è molto simile a C, si porta tante convenzioni dietro la C, e una di queste è e proprio le variabili monolettere, che io odio, inutile dirlo, venendo da un linguaggio dinamico come PHP, nei linguaggi dinamici di solito i nomi e le variabili, essendo un po' più hipster come linguaggi, i nomi e le variabili sono già un po' uniformati alla convenzione di Uncle Bob che dice che devono essere comunicativi, in Java si porta questa cosa un pochino per l'estremo.In Go la cosa carina è che siccome molti si portano dietro questa convenzione, però poi hanno a che fare con persone che lo cominciano a utilizzare da poco e che vengono inevitabilmente da altri ambienti, si deve trovare una soluzione di compromesso e di solito la soluzione di compromesso è che bisogna essere concisi, ma comprensibili.Ci sono comunque alcune eccezioni dove per esempio io continuo ad utilizzare le lettere singole e sono dei casi particolari, dei casi specifici.Dove limiti lo scope magari.No è un po' come il "this".Tu sai che quello è il "this", quindi se "this" si chiamava "t" era la stessa cosa.L'underscore di Scala che metti da partire.Esattamente, in Python c'è il "self" per esempio, stessa cosa, un po' stessa cosa.Però al tempo stesso, come Go è già di suo molto prolisso come linguaggio, perché la sintassi è molto asciutta, quindi non hai molto zucchero sintattico e quindi essendo molto prolisso le variabili lunghe non si sposano.Lo stile deve essere conciso perché altrimenti ti ritrovi delle porte aerei per risolvere dei problemi semplicisti, quindi per limitare proprio l'ammontare di codice da leggere, si cerca di essere concisi e quindi ad esempio avere delle variabili che sono tutta un'intera frase per descrivere qualcosa, ti suggeriscono che forse quel qualcosa è un concetto che è troppo complicato, forse va scomposto in qualcosa di più semplice, è curiosa e quindi al fine il risultato mediamente qual è? Che ci sono delle variabili che ti puoi permettere di chiamare le 3 singole se l'utilizzo e la dichiarazione di quella variabile sono molto vicine tra di loro e quindi il tipo ti informa, il tipo della variabile che è presente nella dichiarazione ti informa su cosa è la variabile e a cosa serve e quindi non hai bisogno di ripetere questa informazione anche nel nome della variabile e allora puoi tenerla concisa, perché tanto la stai dichiarando, la stai utilizzando e poi da lì in poi non la guarderai più, quindi la ci può anche stare.In altri casi invece dichiari una variabile un punto e poi la riutilizzi 100 righe dopo, e allora quando ci ricapiti 100 righe dopo il nome deve essere comunicativo.Però questa comunicatività non può neanche essere un'intrariga dedicata solo al nome e al tipo del lavorabile.Quindi insomma è un problema curioso, per quanto possa sembrare stupido, perché è un problema di compromesso tra sviluppatori che magari hanno un background completamente diverso.Per uno sviluppatore che viene da C, le varie lunghe sono proprio dannose, nel senso che rendono la loro lettura del codice soggettivamente peggiore.Non puoi dire "ma obiettivamente non comunica l'utilizzo" perché quello ti può dire "ma io lo so benissimo che se c'è una sola parola che comincia per C, può essere C quella variabile che si chiama cane, perché so che c'è un solo cane in tutto questo blocco di godici.Certo, assolutamente.Riguardo al CIMI mi è ritornata in mente questa cosa, stavamo sistemando i file, i miei vecchi file universitari e sono ricaduto su un vecchio esame di algoritmi in C.In realtà là c'era tutto l'alfabeto, da A alla Z.Avevo contemplato tutte le lettere.Un'altra domanda, e anche questa è un po' provocatoria però simpatica per far emergere un po' di diversità che sono come dici tu le diversità che hai dovuto affrontare quando hai fatto il passaggio di stack tecnologico.Come riesci ad andare a letto sereno sapendo che usi un linguaggio senza try e catch? Questa è una delle cose con cui mi sono scontrato quando ho cominciato.Era una delle cose che dicevo se c'è proprio una cosa che non mi piace è l'error handling, perché non c'è il tray e poi in realtà c'è però dicono tutti non utilizzarlo, perché c'è il panic recover, però dicono tutti non usarlo mai.Questa domanda l'ho preparata stanotte perché in realtà, e poi mi rispondi perché sono proprio curiosissimo di saperlo, però giusto per contestualizzarlo, perché in realtà sto sviluppando un piccolo algoritmo chi utilizza il crypting a chiave pubblica privata aveva bisogno di qualcosa di veramente performante che potesse girare e javascript non era il caso come ben puoi immaginare quindi ho detto va magari faccio un piccolo servizietto in ingo non lo so da ignorante perché non conosco però mi sembra che tutti dicono che sia particolarmente performante per i processi c'è un certo carico anche sul processore quindi forse fa il caso mio e riesco a raggiungere lo scopo guardo un po di codice sai quick start ho visto un tutorial e son capitato in un listato era solo ripeto il clip di una stringa chiave pubblica privata quindi una roba banalissima e ho visto un listato di una paginetta neanche enorme dove il 90 per cento erano commenti variabili come ti dicevo prima e non c'erano tre i e che ci ho detto io cosa ci faccio qua allora il paradigma dell'errore ne dico dopo un po' cominci a cominci ad apprezzarlo nel senso che effettivamente ha una certa semplicità che è molto apprezzabile questa questa convenzione di avere gli errori essere delle variabili semplicemente e dei risultati della computazione soprattutto cioè come concetto l'errore è un risultato di una computazione, non è un'eccezione, è un risultato, tu provi a chiamare una funzione e la funzione o ti ritorna quello che volevi che facesse, oppure ti ritorna un errore.E' geniale come intuizione in realtà, nel senso che è semplicissimo come concetto.Il concept invece è il try catch fondamentalmente, è quasi un go-to.Ci sono persone che tutt'oggi dicono "non c'è niente di male il go-to", però in realtà… Si, se lavori su Assembly probabilmente no! Esatto, c'è abituato, è un po' come un bambino abituato a essere picchiato dai bulli, cioè non è una cosa comunque giusta da fare.Però sì, il try catch diciamo che può essere accomunato a questi salti, queste interruzioni nel flusso della computazione che potrebbero non essere esattamente intuitivi.Detto questo, in realtà il problema è che a volte il try catch si usa proprio per far passare, per interrompere il flusso della computazione, farlo passare da un punto all'altro non necessariamente connesso di un'applicazione.Il problema sta nel come si usa lo strumento, come tante altre volte.È una delle best practices comune non utilizzare le eccezioni come su tuo ebicontroller.Tra l'altro Stefano, un po' adesso a parte la provocazione, io l'ho buttata dal punto di vista scherzoso, però ho sentito, non so se in realtà è una cosa accumunabile, particolarmente accomunabile al concetto di options in java.Non mi ricordo come si chiama il pattern, cioè il fatto di incapsulare dentro un oggetto il risultato è la computazione.Questo oggetto può essere nullo, quindi può essere un errore e bypassare tutti gli stadi della pipe successivi, oppure contenere un risultato.Quindi un po' c'ho trovato una sorta...adesso non mi ricordo come si chiama il pattern.L'optional in realtà è un approccio funzionale a questo problema, però l'optional è più per gestire un tipo particolare di errori che sono le Null Pointer Exception, mentre invece in Go qualunque cosa che possa causare un errore ha bisogno di un valore da ritornare.Tornando all'esempio di prima, per quanto possa essere semplice, il fatto che sia così semplice causa un side effect abbastanza massivo che è questa immediata apparenza di ripetizione continua di questi "if, else" diverso da "nil", allora devi fare qualcos'altro.Il codice Go è costellato di questi tipi di strutture, ma in maniera abbastanza naive, nel senso che se un errore è diverso lo ritorni e allora c'hai questi errori che vengono magari triggerati in un call path molto seppellito, in una gerarchia di chiamate abbastanza profonda e poi ti arriva questo errore, come si dice in italiano "bubble up", non lo so, però ti ritorna su sin dalla chiamata originaria e non hai idea di tutta la trafila di chiamate nel mezzo.Questo è il motivo per il quale anche persino questa tecnica super semplice può essere utilizzata male, nel senso che una delle raccomandazioni della comunità di Go è che con gli errori ogni volta che ti capita uno tra le mani in uno step intermedio devi farci qualcosa, perché se ti limiti a ritornarlo al chiamante non stai programmando, siccome l'errore è una condizione che devi programmare, poi spesso e volentieri quel qualcosa cos'è? Semplicemente l'errore in Go è una struttura che contiene una stringa, non è niente di che, e quindi quello che fai è aggiungere un messaggio, cioè man mano che che questo errore se lo passa a una staffetta di chiamate, ogni chiamata comunica cosa si stava facendo in quel momento.Quindi c'è stato un errore in una chiamata HTTP, c'è stato un errore in una chiamata HTTP mentre chiamavo Google, c'è stato un errore in una chiamata HTTP mentre chiamavo Google per fare una ricerca.Hai tutta questa fila di errori poi che vengono decorati uno dentro l'altro e quindi alla fine hai un messaggio di errore che ti descrive esattamente lo stacco.E questa cosa col senso di poi, all'inizio la disprezzavo profondamente, col senso di poi sì è un po' ripetitivo, è brutta da scrivere, è brutta anche un pochino da leggere, però alla fine gli IDE ti aiutano, ormai ti comprimono automaticamente queste cose per esempio, te le sintetizzano e ti fanno vedere che qui c'è un error handling, non vedi tutto l'if e tutto quello che succede con l'errore, sai solo che lì c'è un error handling.Quindi con l'aiuto dei leader, senza dimenticarsi il concetto che ci sta alla base, che vuole promuovere un approccio semplice al problema degli errori, che è semplicemente l'errore è un risultato e quindi lo devi ricevere come risultato e devi farci qualcosa con questo risultato, senza perdere di vista questo fondamento su cui è stata costruita questa convenzione, secondo me si comincia a apprezzarla poi e devo dire che non avere nessun try catch nel proprio codice è una cosa molto fresca, è rinfrescante proprio nel senso inglese del termine, nel senso che è una novità, è una cosa che fa piacere, perché è una cosa in meno su cui ragionare e quindi credo che col senno di poi sia stata una scelta azzeccata.C'è stato un tentativo di recente di introdurre una sorta di struttura simile al try-catch in Go e alla fine c'è stato un backlash gigantesco da parte della community.C'era proprio la pull request pronta per essere emergiata e c'è stato un backlash gigantesco su GitHub, hanno pure dovuto bloccare il thread, scaldare la comunicazione.È risalente a mesi fa, neanche troppo, neanche l'anno fa.Se mi mandi qualche riferimento poi le pubblichiamo nelle, almeno un po' di elementi.Ancora al tempo ero un pochino sulla baricata, non sapevo da che parte stare, nel senso che cercavo di capire perché i puristi si schieravano dal lato del "no, non vogliamo nient'altro, l'error handling sta bene così come sta", è semplice.La semplicità è uno dei tenets di base, uno dei principi di base su cui è stato costruito questo linguaggio, quindi perché dobbiamo aggiungere altra roba, altra roba alla sintassi, alla specifica.Go è bello proprio perché la sintassi ce n'è veramente poca, cioè proprio tutta la sintassi che c'è la impari in qualche ora, perché è veramente pochissima e quindi è un punto di forza e se si comincia ad aggiungere robe questo punto di forza si attriccia e alla fine esatto si diluisce e diventa l'ennesimo linguaggio che risolve i problemi come li hanno risolto tutti gli altri.LM: guarda mi fai un assist che più preciso non puoi farmelo, lo so sono cattivo, ti sto provocando però sappi che al primo evento che faranno e avremo modo di vederci ti devo delle birre perché ti sto trattando malissimo.Ti faccio questa domanda proprio basandomi su quello che hai appena detto cioè uno degli assunti e dei motti della comunità di Go è quella che se nei linguaggi ci sono 70 mila modi per fare una cosa in Go ce n'è uno ed è quello giusto e loro ci battagliano parecchio su questo tanto che le librerie di Go, queste sono tue parole, le ho seguite a un'altra live che hai fatto, adesso non ricordo con chi, forse con con Francesco Sciutti? Si, con Francesco Sciutti.Che tra l'altro sarà ospite del mio podcast tra qualche settimana.Tutti i catanesi.Ti volevo dire, questo fatto di semplificarlo, e lo vediamo anche con in realtà delle librerie di base ben fornite, cioè con Go puoi farci tutto anche solo con le librerie che ti mette a disposizione il linguaggio, con le standard libraries.Però quanto questo può in realtà essere limitante in termini di sviluppo, di prospettiva, di nuovi approcci, di nuovi pattern per quel tipo di linguaggio e quel tipo di comunità.Ma basta guardare come si è risolto gli stessi problemi un linguaggio che invece di suo non aveva quasi niente, ora direi JavaScript.Alla fine se piace la gente i problemi risolverà lo stesso, se non è il linguaggio che si risolve per te, comunque se lo strumento piace la gente usare lo strumento per risolvere i problemi in ogni caso e quindi ci saranno poi casi celebri come quello del left pad dove si implementa il left pad in userland perché il linguaggio non ti dà la funzione giusta per farlo e poi i prototype non andavano visti come diremo in sardegna.Poi fai conto che come hai detto tu la standard library di Go in realtà è molto ben fornita detto questo ci sono già per esempio dei wrapper di elementi alla standard library che sono quasi uno standard de facto e quindi il corrispettivo a standard library non si usa più, come ad esempio la libreria per fare il parsing delle flag di interfacce della riga di comando.Ce n'è una che si chiama Flags, dentro la standard library, però uno degli autori, forse non è un autore di Go, non è un contributor del suo gente, forse sì, comunque è uno che lavora per Google mi ricordo, ha creato un wrapper di questa libreria che si chiama Pflugs, che è semplicemente un buggyno più avanzata, che permette di fare sia le short end che quelle con il doppio dash, che permette di dare dei valori di un certo tipo, di fare il parsing a dei tipi direttamente.Insomma, è un piccolo wrapper e si usa quasi sempre questo, però quel wrapper non sarebbe stato così semplice da fare se non ci fosse stata già la libreria quella nativa, né la standard library.Sarebbe stato ancora più complicato con i wrapper, quindi magari avrebbe avuto dei dettagli implementativi che non piacevano e quindi magari se ne sarebbero creati due di wrapper in competizione, non ci sarebbe stato lo standard de fatto.Quindi c'è tutta questa serie di meccaniche poi che si vanno a creare quando si mette su un ecosistema, quando nasce un linguaggio nuovo.Secondo me la bontà del linguaggio non è in discussione, quindi avrà un futuro molto florente, molto molto florido, tra l'altro comunque esplode in una maniera molto repentina.Ad oggi è il mio linguaggio preferito, ad esempio, nonostante mi piaccia molto il PHP, comunque ad oggi credo che Go lo sceglierei per fare qualunque cosa che prima facevo con il PHP, anche perché ce l'ho più fresco, per carità.Però credo che sia un grande linguaggio, probabilmente quando finalmente deciderò di imparare Elixir, magari mi innamorerò un'altra volta e abbandonerò pure questo, però non si può mai sapere.L'ecosistema senza dubbio gioca la sua parte, per esempio uno dei motivi per cui io alla fine Elixir non l'ho mai approfondito è proprio perché non mi sembra che l'ecosistema sia così florido come quello di Go.Un linguaggio invece che credo La mia limitata percezione, per carità, è basata su Hacker News, Twitter, Reddit, Stackoverflow, le robe che leggo io, i vari Slack channel a cui uno magari è sottoscritto, quindi è una percezione molto aleatoria, però la percezione che ho è che il prossimo linguaggio che avrà una crescita molto veloce sarà Rust.Perché secondo me, ti dico per esempio, io non ho ancora visto niente di Rust, non ho neanche fatto l'ellowork di Rust, però ho letto una cosa, ho letto una pagina della documentazione che è quella proprio sull'ownership, sul concetto di ownership e quindi la gestione della memoria di Rust, o l'assenza della tale.Solo a leggere questa pagina ho imparato un sacco di cose, già di mio, in generale sulla programmazione.LM: lasci sulla via un garbage collector! esatto esatto capito, vieni da PHP che ha il ref counting, poi vai su Go che ha un garbage collector super mega ottimizzato e poi ti scontri, non ho mai voluto approfondire C perché non voglio utilizzare mmap mai nella mia vita o malloc, non lo voglio fare.Dopo gli esami di algoritmi, penso che il C in molti di noi è andato, il Kerning a Ricci è andato proprio su, sotto il divano.Esattamente, esattamente.E quindi è una cosa che mi stimola per imparare un nuovo paradigma, un nuovo modo di approcciare questo problema annoso della gestione della memoria e quindi insomma, del futuro erosio ci sono tanti bei linguaggi da imparare al giorno d'oggi, secondo me è un ottimo periodo per diventare un programmatore.Credo di sì.Guarda, una particolarità, giusto perché hai introdotto Rust e poi ti lascio perché si è già fatta l'ora di cena e immagino che a quest'ora dopo una giornata di lavoro… Più che altro non mi sono dimenticato di aprirmi una birra quindi sto morendo di sede.Vado ad acqua da un'ora ma non mi disseto.Ok, una in più il giorno che ci vediamo.No, ho preparato che uscirà questa settimana, quindi sarà già uscita per chi ci ascolterà una puntata su Dino, che è un po' l'outsider del mondo Java, scritto una roba freschissima perché è uscita pochi giorni fa, è uscito il 15 o il 13, adesso non ricordo, il 13 maggio.E tra l'altro di Dino c'è una particolarità.In realtà l'engine base era scritto in Go, come ben sai.Poi c'è stato questo piccolo combattimento dei due garbage collector, uno del motore V8, uno di Go, che si è optato per passare a Rust.Però, credo che all'interno proprio dei concetti di Dino sia rimasto tantissimo Go.Da cosa lo vedo? Intanto da come vengono gestiti, viene gestita la parte assincrona.E poi dalla gestione, vabbè un pochino delle dipendenze, però là Dino ha fatto una sua scommessa quella di uscire dai concetti di package manager e di fare questa scelta.che ne so c'è anche il concetto di security by design che mi piace tantissimo là e by default più che by design.Quindi non lo so in qualche modo percepisco che l'esperienza che ha fatto Ryan Dyle mi sa che si chiami così, che è stato anche il creatore di Node, su Go perché ha lavorato per per lungo tempo su Go, si è arrivato in qualche modo con Dino anche nel mondo JavaScript.Hai avuto modo di buttarci un occhio? No, in realtà ti devo dire proprio con franchezza che io fino a quando c'è stato l'annuncio della 1.0 non avevo idea di cosa fosse Dino.Forse mi era passato davanti qualche volta ma l'avevo completamente ignorato.Nel senso che quando l'ho visto ho detto "aspetta questa cosa l'ho già vista.E siccome tutti parlano di questa V1, poi alla fine mi sono dato l'annuncio e ho detto "ah, interessantissima questa cosa" e mi ricordavo di questo progetto, però non ne ho completamente familiarità.Ho letto le release notes ed è molto promettente, lo trovo molto promettente, senza dubbio.Però non ho familiarità né con i design principles se non con quelli esposti proprio in quelle release notes.Non pensare che ci sia molto di più, eh.Non pensare che ci sia molto di più.Non sapevo che originariamente era stato implementato in Goldstone.E poi è stato riscritto in Rust.E tra l'altro una cosa che mi è piaciuta tantissimo, la condivido con te perché tanto stiamo chiaccherando ma tra un po' ti lascio, promesso, è che è stato pensato in un modo molto intelligente perché è stato pensato ragionando in pacchetti.cioè non è un mega pacchettone mega eseguibile come nodo dove o prendi tutto o niente, prendere o lasciare, no, ma è strutturato in crate, che sarebbero da quello che ho capito i pacchetti delle dipendenze, i pacchettini che ti vai a costruire e puoi prendere solo alcune parti, che ne so, ti serve il typescript o un modulo, ok ce l'hai e lo butti nel tuo dispositivo embed, Nuova vita JavaScript.Sì, secondo me sarà promettente e a tutte le carte in regola per diventare il prossimo Node, il prossimo Darling dell'ecosistema JavaScript.Vediamo, vediamo.Sicuramente alle carte in tavola, nel senso che mi sembra un approccio...anche il fatto stesso che ci siano le stesse persone coinvolte, la dice lunga, nel senso che è il classico esempio di sviluppo iterativo, di persone che creano un progetto, ci nasce poi per carità tutta una comunità gigantesca e quindi il progetto diventa una cosa a sé, va avanti molto di più rispetto a magari l'idea che ne aveva avuto il creatore e la stessa cosa è successa ad esempio con PHP, nel senso che per esempio vedi quanto è coinvolto Rasmus Lerdoff al giornalogico negli internals in realtà non moltissimo, ci può dire anche più poco.Oltre a giustificare i nomi delle funzioni di Standard Library, mi sa che allo stesso conferenzo ci siamo conosciuti che aveva detto "sì i nomi sono omogenissimi, sono verticali con l'assintassi in C".Non so se ricordi quella frase, era bellissimo.che per carità ci può stare, però ovviamente i progetti nel momento in cui assumono questa massa critica poi prendono vita e fanno il loro corso.Però è ammirevole il fatto che il creatore stesso dei progetti torni sui passi e dice, si interroghi su "ma si poteva fare diversamente, si poteva fare meglio magari?" Di solito la risposta è ovviamente sì, nel senso che nell'ingegneria di software tutto è sempre molto iterativo, di solito 10 anni, quando passa qualche anno, a volte anche molto di meno, però per quanto riguarda i linguaggi magari i time frame sono un pochino più dilatati, ma quando si ritorna sui propri passi ci si rende sempre conto che gran parte delle cose, la maggiore parte delle decisioni non le si prenderebbe di nuovo esattamente nello stesso modo, perché nel frattempo sono emersi i limiti di quelle decisioni che si erano prese regionalmente.Mi piace molto questa cosa che ci siano le stesse persone che hanno creato uno degli ecosistemi più di successo nella storia dell'informatica e adesso ne stiamo creando un altro.Spaccherà la community? Probabile, possibile, chi se ne frega anche.insomma, non ci vedo molti svantaggi.Se io per esempio fossi uno sviluppatore che utilizza TypeScript ogni giorno probabilmente starei già a rompere palle a tutti per dire "usiamo dire, dai, usiamo dire".Anche se Ryan Dahl dice "Ehi, occhio, non usate l'improduzione in progetti enormi, fermi un attimo" perché lo dice lui.Sì, dipende cosa si intende poi ai progetti la mia produzione.Questa cosa è molto soggettiva.Io ti dico che sicuramente lo proverò.Però al di là del fatto che spacchi o non spacchi, e qua voglio veramente avviarmi verso la chiusura, anche perché siamo un'ora e quaranta che chiacchieriamo, potrei rimanere altrettanto tempo, quindi non ti preoccupare, mi fa estremamente piacere chiacchierare con te.Al di là del fatto che Dino spacchi o guadagni fette di mercato tra virgolette o meno quello che in realtà fa fa un salto in avanti e quelli che a me piace chiamare i salti quantici, i salti di prospettiva, apre una serie di possibilità e tool come Node o come qualunque altro linguaggio ecosistema non può rimanere l'inerme.In qualche modo da questo shift verrà condizionato, tutto verrà condizionato, così come altri ecosistemi hanno condizionato quello.Si, probabilmente si ritaglieranno ognuno la propria fetta di sviluppatori, nel senso che alla fine TypeScript nell'ambiente Node è un po' un afterthought, diciamo.Mentre invece per Dino TypeScript è subito il focus.Quindi forse c'è la possibilità di avere questa dicotomia.La gente che vuole continuare a programmare in JavaScript dinamico senza tipi lo continua a fare con Node e chi invece si vuole concentrare sul TypeScript, credo che siano quelli un pochino più lungivinanti, perché torno a dire che secondo me la tipizzazione dei linguaggi è una cosa che è destinata a soppiantare completamente.In modo molto light come lo fa TypeScript.Esatto, esatto.Quindi sì, secondo me c'è spazio per entrambi, ecco, questo senza dubbio.C'è spazio per entrambi.Detto questo, non sono abbastanza a stretto contatto per avere un'opinione che sia autorevole in nessun modo, quindi è solo una sensazione.Detto questo, mi è bastato leggere delle release notes di un progetto per catalizzare moltissimo i miei interessi.E' una cosa che succede spesso con lo sviluppatore, ne vediamo tante release notes di tanti progetti che potenzialmente sono interessanti, ma poi non li diamo così tanto preso.Mentre invece un progetto di cui avevo scarsamente sentito parlare, leggo le release notes e mi viene subito da pensare che questa è una cosa che avrà un grosso impatto, proprio a sensazione.assolutamente comunque a conferma di quello che ti dico che farà un po' da traino e da spinta, da lepre no? come che si dice il fatto di scattare la lepre per far correre i cani io sono sicuro e sono pronto a mettere davvero una una una pinta di birra sul tavolo la prossima volta che ci vediamo che da qui a stretto giro naturalmente coi tempi di release Node avrà le promise nelle standard library, cosa che non aveva alcuna intenzione di implementare.Sono pronto a scommetterci.Questa è la mia battuta e con questo ci avviamo in conclusione.Avrei altre centomila milioni di domande da farti Stefano.Anche me piacerebbe rimanere da te.Io quando parlo di queste cose prendo la calata come si dice.Avremo modo di risentirci spero e continuare la chiacchiera e perché no magari la prossima volta coinvolgendo anche più persone e provare a fare una chiacchierata come fanno tanti podcaster americani che coinvolgono più attori nella discussione anche per per renderla più dinamica non che questa non sia stata dinamicissima mi son divertito un mondo.Sì, mi ha fatto molto piacere.Lasciamo i tuoi contati perché vedo che su Twitter sei molto attivo, quindi metterò tutti i tuoi riferimenti.Sì, vanno spazi su Twitter.Ci sono periodi in cui twitto, periodi in cui invece lo ignoro completamente.Ma più che altro perché non sono un tipo molto social.Anche se nelle community, poi magari una puntata parliamo solo di community, hai fatto quel salto e sei diventato davvero super super super attivo.Comunque sì, il mio Twitter è @s_torresi e basta, il GitHub è @stefanotorresi, ma c'è molto altro.Torresi.it è il mio sito ma è un vieto travisa.Metterò tutto nelle note dell'episodio.Stefano io ti ringrazio di cuore a nome mio e di tutti gli ascoltatori di Gitbar, sono queste le puntate che vogliamo.Sono quelle puntate che ci salvano dalle mie decine di minuti di monologo dove sbaglio tutti i congiuntivi e quindi ci aiutano a entrare più nel vivo con anche una competenza diversa da quella che posso avere io su argomenti verticali.Quindi grazie.Grazie a te.Alla prossima Stefano.Alla prossima.[sottotitoli a cura di Luca Gardella] È stato veramente piacevole rifare una chiaccherata con Stefano.Fosse stato per me la puntata sarebbe durata un po' qualcosa tipo 10 ore, però in realtà arrivate ad un certo punto bisogna anche tagliare.Detto questo vi ricordo rapidamente i contatti, potete iscrivermi info@gitbar.it o su twitter @brainrepo vi ricordo che qualora voleste potete aggiungere il podcast alla vostra lista di podcast preferiti mediante la vostra app che può essere Castamatic, Pocketcast, Google Podcast, Spotify e chi più ne ha più ne metta se proprio vi è piaciuta potete anche lasciare una recensione potete farlo direttamente dall'iTunes Store o dall'applicazione podcast di Apple per qualunque consiglio, informazione e quant'altro potete iscrivervi ai contatti che vi ho detto prima e nulla, da Leone è tutto, alla prossima settimana, ciao! GIT BAR, il circolo dei full stack 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 degli strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.[Musica]
