Va benissimo ha fatto due piccoli terremoti nei momenti negli ultimi 10 secondi qua quindi se fa qualcosa me ne vado, ve lo dico se mi vedete che me ne vado ne ha fatto un altro più forte per questi due sono stati leggeri però siccome la un po' di anni fa ho fatto una bella...ok, mi ricordo niente siamo noi che nonostante il deploy fallito l'Asia in rossa il business incazzato ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave bene e benvenuti su Gitbar nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori Abbiamo con noi Carmine e let me interject for a moment.Ah no, Alessio che ha tipo Alessio è l'uomo dei dei nickname su questo software praticamente è lo spotter di tutti i bug di questo software devo dire che lo paghiamo un rene e io oggi sto registrando con gli spectre aperto Alessio è riuscito a scrivere un nickname lungo tipo quattro cartelle.Sì, ci ho collato un copypasta dentro di Richard Solman, quello famoso.Quindi c'è...vabbè, lasciamo stare.Detto questo, ragazzi, come state? Bene, bene.Ale? Fa caldo.Allora, stavo in muto fino a 30 secondi fa.Tutto a posto fa troppo caldo in questa Italia centrale nonostante tutte le peripezie de Carmine in Francia anche le tue comunque vi invidio le temperature a cui siete stati sottoposti e continuate nel tuo caso a essere sottoposti sono appena tornato da Rust Lab tra l'altro che non c'entra quasi niente con il tema della puntata.Com'era Rust Lab? St'anno c'erano delle cose fighe, fighe, fighe.Sapete che volevo proprio andarci, cioè alla fine devo stare qualche cazzo di giorno a casa, non posso sempre essere fuori, mia moglie mi dà per disperso, altrimenti non faccio.Però l'anno prossimo è possibile che...Chiama chi l'ha visto.Ma comunque, in questa chiamata facciamo pubblicità, ma c'è qualcuno che va al FOSDEM oltre me, Alessio, Mauro sì? Eh beh, mi hai prenotato l'albergo quasi! Ok, quindi la vera cosa è Andrea Vieni al FOSDEM? No, non ci vengo! In realtà...No, non ci sono mai andato, veramente.La volta buona per iniziare.La volta buona prima o poi.Nessi prima o poi per forza.Alessio ha già spoilerato il nostro super ospite di oggi, però prima di a questo punto di accendere i microfoni per bene.Ehi, prima di iniziare vi devo ricordare che questa puntata è stata registrata in collaborazione con Fisco Zen, che è esattamente tutto quello che serve quando si ha o si vuole aprire partita IVA.detto questo vi ricordo rapidamente i nostri contatti info@gitbar.it e @brainrepo sono i modi classici e poi? E poi c'è il gruppo Telegram ci potete trovare schiendo Gitbar sul vostro client di Telegram preferito siamo più di 1300 persone insomma vi aspettiamo.Oltre a quello insomma abbiamo anche il nostro neonato canale YouTube che è un canale YouTube che ha pochissimi, pochi ascoltatori per cui insomma se ci state ascoltando e vi fa piacere anche vederci, vedere qualche contributo speciale, la cosa che potete fare è andare su YouTube, cercare Gitbar, iscrivervi e cliccare sul campanaccio.ok è arrivato il...aspetta aspetta aspetta ti devo fermare dovete donarci i soldi questa è la cosa che io dico sempre.Io non è possibile che non ho un green screen per non fare dell'immondizia della mia cucina visto che non ho nemmeno il sistema operativo giusto per fare lo sfondo insomma sfocato mi raccomando donate perché dobbiamo comprare qualcosa.Ah no allora di rapidamente cos'è successo Carmine prima di iniziare la puntata, adesso lo dici! Io sono stato mezz'ora a configurare sta roba con la telecamera Blurred, riavvio kernel panic.Così, quindi ho passato gli ultimi 40 insomma minuti, infatti sono con un altro computer, non sono con quello lì con cui ho fatto il test.l'anno di Linux sul desktop! E' l'anno dei Linux sul desktop ma non è l'anno dei Carmine! Non è l'anno dei Carmine sul desktop proprio! Voi dovete donare così io posso comprare una licenza di Windows così almeno non ci sono questi problemi! Detto questo io direi che iniziamo e e partiamo con la presentazione del nostro ospite.L'ospite di oggi è un Principal Engineer a Vips e anche e soprattutto un Core Team Member Elixir.Abbiamo con noi Andrea Leopardi.Ciao Andrea! Ciao a tutti! Grazie di avermi invitato.Una cosa che devo chiarire subito è che è il primo podcast nella vita che faccio in italiano e sto in difficoltà estrema perché non parlo mai di queste cose in italiano e quindi ho l'ansia della ceca e si sente l'accento.Cioè è un disastro, quindi scusatemi se dico cose...speriamo che non dico parolacce almeno quello da che...speriamo che dici parolacce! Si possono dire! Si devono dire! Siamo in fascia protetta! Tra l'altro storicamente ci fu un momento, questo è il momento history, ci fu un momento dove durante una puntata Carmine stava ancora a Firenze e si affacciò dalla finestra senza mutare il microfono disse alcune cose inenarrabili...in arabo, sì! Io non me ne accorsi...accorsi? forse sì...sì, accorgi...no, accorsi, buona, esatto, Stefano...non me ne accorsi, arrivarono in puntata e dicevamo un paio di messaggi dicendo "ah però che bel dizionario! Eh ragazzi, anche l'abilità di uno speaker si vede dal cambiamento del registro a seconda del contesto.Assolutamente sì.Allora io direi, siccome Carmine ci teneva particolar modo ad averti qua, vorrei far fare a lui la prima domanda.Carmine? Allora, faccio proprio la domanda tipo quelli proprio basi, come stessimo su questo dimanetto Barbara D'Urso.Ciao Andrea, che cos'è Elixir? Ciao Barbara.Elixir è un linguaggio di programmazione che ha una decina d'anni adesso, poco di più, funzionale e principalmente orientato sulla concurrency, parallelismo insomma, compila in bytecode per la virtual machine di Erlang, quindi gira sulla virtual machine di Erlang, è come se fosse magari Clojure è un po' più conosciuto, è come se fosse Clojure, quello che Clojure è per la JVM, quindi un linguaggio diverso che però compila lo stesso bytecode di Erlang.Erlang è un linguaggio di programmazione per Context, linguaggio di programmazione che ha una trentina d'anni, anche qualcosa di più, che è stato fatto da Ericsson in Svezia, diciamo in Svezia, ma una trentina, 35 anni fa, per telecomunicazione, ci facevano gli switch dei telefoni, cioè le reti telefoniche insomma dei telefoni fissi, una trentina d'anni fa con Erlang, quindi ha una serie di cose che poi sono tornate a essere utili nel mondo moderno.Elixir insomma è come un dialetto nuovo di questo linguaggio che gira sulla stessa virtual machine.Ok, e come nasce Elixir? Nel senso tu considera che se io sia Alessio sviluppiamo un Elixir per lavoro.Ah top, lo sapevo.e praticamente io ho conosciuto Elixir un po' di anni fa perché mi linkarono un documentario su YouTube, tipo una roba del genere, che sono quei quarto dura venti ore, ma se ci dovessi dire tu in italiano, in lingua corrente, come è nato Elixir e perché utilizzare Elixir? E l'Elixir, io mi sono avvicinato perché era molto simile, almeno nella mia testa, che è una cosa abbastanza vaida, a Ruby.Io facevo Ruby, facevo Rails e quindi, diciamo, me l'ha stato consigliato di passare a Elixir e Phoenix, insomma.Quindi ci sono avvicinato così.Sì, sì, allora è nato un ragazzo che si chiama Gioseva Lim, che era un membro del team di Rails, quindi anche lui viene da Ruby Praticamente all'inizio del 2009-2010 lui stava nel team di Rails e in quel periodo ci si cominciavano a stare parecchi sistemi, parecchi app in Rails molto grandi, tipo Twitter magari, quindi si cominciava a sentire un po' la fatica di Ruby nel fare cose con molta con concorrenza a scalare insomma come framework e come linguaggio insomma e quindi Giuse si è messo a esplorare un po' insomma che c'è il panorama delle cose delle altre cose che si potevano utilizzare e è venuto a conoscenza di Erlang e la frase famosa che l'ho detto parafrasata perché in inglese l'ha detta però è stata tipo che gli piaceva tutto quello che c'era in Erlang, però odiava tutto quello che non c'era.E per contesto, tanti conosceranno Erlang, però per chi non lo conosce Erlang è un linguaggio vecchio, come età proprio, cioè nel mondo del linguaggio di programmazione solo 35 anni è tantissimo.10 anni fa, 12 anni fa, quando è nato l'Exil si percepiva tantissimo, cioè il tooling era molto...era proprio cioè...quelle cose insomma da...non da hacker, ma insomma multi-make file, cioè delle cose che non erano diciamo al passo con Rails ecco per esempio dove c'era molto più la developer experience era mille volte meglio magari e quindi tutte queste cose mancavano, mancavano magari i modi facili di fare testing, di documentazione tutto questo aspetto e quindi Giose ha messo insieme le due cose, ha detto ok tutte le cose buone di Ruby che sono spesso magari la developer experience, il tooling di Ruby, di Rails, il metaprogramming per esempio, quindi tutte queste cose in Ruby e Rails piacevano a tanti messe insieme alla a Beam, che sarebbe la virtual machine di Erlang, quindi tutta la parte della concorrenza, della parte funzionale, insomma tutti questi aspetti qua.Quindi ha fatto questo linguaggio che sarebbe, diciamo, un linguaggio developer-friendly, quella era l'idea, fatto per questa virtual machine.Quindi era un linguaggio che è uscito già alla versione 1.0, aveva un tool built-in per fare un framework per fare il testing, c'aveva il framework per generare documentazione, il build tool, insomma tutta la developer experience era molto curata già da appena uscito e in più a cose tipo il metaprogramming che Erlang non aveva, cioè le macro, un linguaggio omoiconico per i nerd, tipo Lisp insomma, però meno parentesi.quindi questo è come è venuto a nascere all'inizio sicuramente era mirato a un mondo del web era mirato a coprire quello che faceva Rails infatti subito è stato fatto un framework tipo Rails che è Phoenix l'equivalente di un web framework per Elixir fatto un equivalente di un tipo RM, tipo Active Record in Rails per parlare con i database, insomma quindi è stato fatto diciamo come approccio per il web.Poi si è evoluto, adesso insomma ci si fanno tante cose.La seconda domanda che è il motivo per cui si utilizza, cinque quattro cinque anni fa era, avrei detto principalmente web, cioè dove siccome specialmente siccome Erlang è stato fatto per queste reti telefoniche, per questi sistemi dove ci sono tanti computer collegati fra loro, dove magari una telefonata non può cadere perché io devo aggiornare il software, tutte quelle cose di questo tipo, si stanno riproponendo nel web, dove c'è il WebSocket connesso, c'è le applicazioni molto real-time e quindi e hai tanti computer che ti servono le richieste HTTP ai client questa cosa si è ricollegata molto bene a quello per cui era stato fatto Erlang in più la concorrenza e fault tolerance sono cose che stanno nella virtual machine di Erlang da 30 anni sono cose che adesso sono utilissime Un esempio brevissimo è che i processi in Xeer e in Erlang sulla virtual machine sono lightweight threads praticamente sono gestiti dalla virtual machine, non sono gestiti dal sistema operativo e quindi se ne possono avere centinaia di migliaia e via dicendo e sono isolati garbage collection è per process e in più quando un processo cresce non si porta dietro gli altri processi a meno che tu non vuoi e quindi questo per esempio è perfetto per le richieste web perché ti arriva una richiesta web al tuo server elixir elixir fa lo spawn di un processo che gestisce la richiesta e poi il processo muore e questo lo puoi fare con centinaia di migliaia di richieste contemporaneamente quindi si sono riproposte tutte queste cose che vanno benissimo per il web quindi per me è un sistema web che non abbia requisiti pazzeschi di performance perché comunque l'exil non è un linguaggio veloce non è quello che uno considererebbe un linguaggio veloce è più veloce di Ruby, è più veloce di Python però non è più veloce di tanti altri linguaggi della JVM o di Rust, di Go, di tutti i linguaggi che girano adesso quindi a meno che non si hanno requisiti di performance molto aggressivi Elixir per me è una scelta molto molto sensata per cose web poi negli ultimi 5-6 anni si sta espandendo tanto anche in altri ambiti perché la mia teoria è perché piace tanto il linguaggio mi piace pensare che perché a tanti piace tanto questo linguaggio però sono stati fatti framework per fare embedded devices quindi ci sta chi fa, si chiama NERVS, ci sta chi lo usa per fare, per metterlo nei sensori, varie cose, nelle telecamere, eccetera.E in più adesso, negli ultimi forse anno, anno e mezzo, sta esplodendo anche sul machine learning, perché è stato fatto un framework tipo NumPy, per Python, cioè è stato ricreato un po' il panorama dei framework dedicati a machine learning e neural network, tutta questa roba qua è stata ricreata in Elixir con un progetto che si chiama NX, cioè sarebbe numerica all'Elixir, quindi si sta facendo tanto anche in quell'ambito, è stato fatto un equivalente ai notebook Jupyter, quindi che si chiama Livebook, che sarebbe l'alternativa ai notebook di Jupyter, quindi si sta, tante persone lo stanno cominciando a usare anche per fare cose di machine learning, di data science, di tutta questa roba qua.quindi adesso sinceramente è più difficile quando lo uso di Xilbo, sempre, è bellissimo, è il linguaggio più bello che c'è, è troppo facile sempre quando lo usi per qualsiasi cosa, però per tante cose, ormai ha veramente tanti, cioè si può utilizzare per tante cose rispetto a prima, poi ci sono degli ambiti magari che ne sono, cose di driver, di sistemi operativi, cosa che ovviamente non ha magari senso usare un linguaggio del genere, la risposta più lunga della storia del divano di Barbara D'Urso è sempre parlando di divano, scherzo io ho una domanda invece io ho conosciuto Elixir, ho sentito parlare di Elixir in un Code Motion tipo 2013-2014 una roba super vecchia, al Politecnico di Milano, un eone fa dove ci furono due talk interessanti.Il primo era su Elixir, fondamentalmente era un talk che parlava di Elixir ma parlava del pattern matching più che di Elixir, quindi la potenza del pattern matching.Me lo ricordo ancora chiaro, 35 minuti di pattern matching.Chapeau a chi è riuscito a fare un talk.Adesso non ricordo chi fosse ma bravissimo perché è intrattenere così tanto parlando di quel topic quindi bravo.Il secondo talk era appunto su Phoenix e su Elixir.Allora, prima domanda che ti faccio, tieni presente che io non ho mai scritto mezza riga in Elixir, mezza riga in Phoenix e quello che so è per scienza infusa passata da Carmine e da Alessio che sono invece dei super fan e non parlano d'altro nel nostro gruppo privato.e tipo la mia percezione è che in fondo Erlang non era pensato per essere un linguaggio general purpose ma era un linguaggio molto verticale e invece l'Xeer prendeva tutti i vantaggi di Erlang però con un mindset, shiftando non solo quindi non solo creando del tooling, ma proprio shiftando il mindset.Ci ho visto sbagliato in questo? No, no assolutamente no.Cioè Erlang è per me affascinante come linguaggio di programmazione perché è uno dei pochi forse linguaggi di programmazione, almeno che io conosco, che sono stati fatti non per fare un linguaggio di programmazione ma è come se a noi ci dice, uno ti dice devi fare cioè devi scrivere un programma che mi fa questa cosa io comincio aspetta mi serve prima un linguaggio di programmazione per fare quello che mi stai chiedendo e quindi è stato fatto per un motivo non è stato fatto cioè è come se fosse il by-product di un, cioè capite è uscito fuori dal fatto che dovevano fare questi sistemi per per reti telefoniche quindi è molto verticale almeno all'inizio invece l'Xeer sì come l'hai detto tu, è subito...cioè il mindset è sempre stato di fare un linguaggio general purpose, non è mai stato di fare un linguaggio dedicato al web o dedicato a qualsiasi cosa, anzi tante cose nell'XIR come il sistema di metaprogramming sono state fatte proprio in modo da rendere il linguaggio molto estensibile, di poter fare cose tipo Phoenix ma anche cose tipo machine learning, di poter fare cose con un linguaggio relativamente semplice che tu puoi customizzare tanto, insomma, fare queste cose.E una cosa però è che Erlang nel frattempo si è evoluto tantissimo, cioè negli ultimi 5-10 anni Erlang è diventato molto, molto general purpose, cioè è stato rivoluzionato tanto, anche con l'aiuto di Lixir e di tutte le persone che Lixir ha portato nella community, che adesso usano la virtual machine di Erlang.Però anche Erlang si è molto allineato a un linguaggio general purpose dove tanto è stato implementato, tanto di quello che era all'inizio c'era nell'XSERE è stato poi riemplementato in Erlang e adesso l'XSERE usa semplicemente quello che Erlang ha riemplementato, insomma, quindi adesso si è evoluto tanto in questa direzione, però sì, ci hai preso, insomma, all'inizio era sicuramente più, molto più specifico, ecco.Oddio, mamma mia ragazzi, ora è di un miliardo di cose.Allora, la prima cosa è che Erlang, cioè questa cosa è un esempio assolutamente accidentale di un paradigma che si chiama "language oriented programming", quello che ha detto Andrea prima, te danno un problema e tu la prima cosa che fai è scrivere in linguaggio Erlang, è nato così, è vero? è veramente figa sta cosa che hai detto, dovrebbe succedere più spesso, certe volte sì, cioè infatti è quasi tra virgolette è strano e brutto e bello allo stesso tempo che Erlang poi alla fine si è stato espanso da Elixir, è un po' una cosa strana, però la cosa interessante è che ha beccato esattamente quella nicchia di cose che poi alla fine è diventata il web, a parte i telefoni, quindi è una cosa molto figa.Io sono qui in veste di fangirl, oltre che di sviluppatore l'XIR e ti volevo portare i ringraziamenti del nostro collega Fabrizio Sestito per il tuo libro Testing l'XIR, perché per gli ascoltatori a casa, allora Andrea ha scritto un libro, si chiama Testing l'XIR e diciamo che si è creata al lavoro da noi questa situazione diciamo di di Cable Management dove da una parte del cavo c'era Fabrizio che ci tirava il libro del testing Elixir e dall'altra parte c'eravamo io e Carmine che portiamo ancora delle ferite fisiche sul nostro corpo causate da questo libro che è veramente uno dei migliori libri de testing de sempre cioè a parte Elixir veramente quindi leggetevi il testing Elixir perché è proprio figo e poi te volevo fare una domanda che è allora deviamo un attimo tu sei diventato core team del team di sviluppo dell'XIR dalla tua stanza da letto dell'Aquila Come hai fatto? Nel senso non è esattamente "The Usual Developer Journey", quindi come hai fatto? Prima di rispondere, intanto il libro l'ho scritto insieme a un altro odore, lo devo dire, che se no mi denuncia Geoffrey, però tanto non parli italiano per fortuna, però vabbè Geoffrey Mattaes.A me le puntate sono sottotitolate quindi.non è un po' di scrittura.No! Ah perfetto! No a parte gli scherzi la se l'abbiamo scritto insieme anzi l'idea è stata sua quindi c'ha tutto quasi tutto il credito lui io ci ho messo solo eh un po' di scrittura poi ehm come eh sì no non è sì abbastanza neutral però eh io eh l'ho fatto da partendo un po' da Piediero ero molto quando superiori confuso a pallone, quindi ho provato a fare il test di medicina per entrare all'università, ho fatto sei mesi di biotecnologie, mi sono appassionato a un corso di fisica, a biotecnologie, quindi ho fatto fisica, mi sono trasferito a fisica, ho fatto un anno e mezzo di fisica, andavo pure bene, però poi ho fatto un corso di programmazione a fisica e mi sono innamorato della programmazione e quindi mi sono dato a informatico, però diciamo sempre tutta la...ho fatto la triennale di informatico alla fine, ma tutto il tempo che ho passato nell'università l'ho passato la maggior parte a farmi i cazzi miei, cioè a fare cose, altre cose, cioè dove io andavo, mi imparavo git, mi imparavo una cosa, una cosa, poi rubi, cioè ero molto curioso ai tempi e quindi mi sono imparato un bel po' di cose.Mi so avvicinato linguaggi funzionali nel senso che ho esplorato un po' magari Haskell, Closure, però non mi ha mai cliccato qualcosa quindi è sempre stato un po' restio.Ho trovato Elixir, mi è piaciuto tanto però l'ho trovato quando era, ora non mi ricordo, però era prima di 1.0 cioè sarà stato tipo 0.16 ma non mi ricordo.Insomma un paio di versioni appena prima che fosse 1.0 ed era...Quando dovevi ancora fa application.start delle dipendenze? Eh sì, una cosa del genere, manco me lo ricordo perché ai tempi poi non ci ho fatto niente, me lo sono guardato un po', era la documentazione magari delle volte non matchava quello che c'era nel codice, era un linguaggio abbastanza giovane e io avendo zero anni di esperienza già dicevo "non posso stare presso ai linguaggi che non sono documentati bene" e quindi ho lasciato perdere.Poi dopo ho continuato, un po' di wordpress con un amico qua insomma ho fatto un po' di cose, ho finito l'università poi mi sono riavvicinato un po' a Elixir che era diventato 1.0 nel frattempo e mi piaceva mi piaceva un sacco quindi mi sono cominciato siccome non lavoravo con Elixir decisamente lavoravo pure poco ma in generale sicuramente non con Elixir quando cioè quello che ho cominciato a fare con Elixir è stato fare contribution su github alla documentazione perché magari andavo a leggere la documentazione e vedevo che c'era una cosa che non corrispondeva a quello che c'era nel codice e dicevo "aspetta un attimo, questo lo possiamo" e quindi ho cominciato a fare contribution sulla documentazione, una, due, tre e alla fine Giuseppe, sempre il creatore del linguaggio, mi ha contattato e mi ha detto "vuoi lavorare su GetText?" GetText è internazionalizzazione, una libreria per Elixir che esiste per GNU, GNU GetText è una cosa che si usa in C, insomma in altri linguaggi, e Giuseppe voleva fare una libreria di Elixir per fare sta cosa, che era un progetto abbastanza grande, diciamo, e quindi mi ha guidato nel fare questo progetto e ci ho dedicato un sacco di tempo, ci avevo a quei tempi, e quindi ho fatto sta cosa e e poi una contribution qua, una contribution là, un bel po' di contribution a Elixir e sono andato a lavorare in Svezia per un annetto e mezzo dove ho lavorato in un'azienda in cui c'era Alexey Magushev che è un ex membro del team di Elixir quindi lavoravamo insieme molto a contatto e quindi ho fatto molte contribution su Elixir e poi alla fine Giosè mi ha invitato a far parte del team nel 2016 Quindi così è andato, questo è stato il journey.È stata una fortuna pure perché l'ho beccato l'Xeer nel momento migliore per farci contribution, perché c'era tanto tanto da fare, capito? Sia specialmente nell'ecosistema ma anche nell'Xeer.Adesso per esempio l'Xeer è molto molto più maturo, quindi non è che trovi i famosi low hanging fruits, no, non è che ci stiano cose.un proverbio orientale che è l'equivalente della fortuna aiuta gli audaci dei latini però mi piace perché è meglio secondo me descrivete più la situazione soprattutto questa che è la fortuna aiuta solo le menti già pronte - mi piace sì sì mi fa sentire mi fa sentire fregno però sì insomma pure il culo insomma cioè il momento giusto è stato pure il momento giusto insomma però sì No veramente complimenti e quindi da questo si va alla mia seconda domanda che è come è strutturata la tua giornata? Pochissimo elixir, pochissimo no aspetta full time elixir al lavoro però pochissimo open source allora intanto una cosa da dire che il team di elixir è piccolissimo cioè cioè siamo 5 persone nel team, quindi è un team molto piccolo.Il team di Elixir, cioè il lavoro che va fatto in Elixir è poco adesso, cioè è poco.Un po' del lavoro per esempio è quando esce una nuova versione di Erlang e possiamo utilizzare cose che hanno aggiunto ad Erlang, tutte cose di questo tipo, però Elixir in sé non è che abbia tanto lavoro rimasto, ci stanno qualche bug report, insomma però non è, non c'è tanto tanto tanto lavoro da fare, quindi nel frattempo io negli anni ho accumulato tantissime librerie che io o sono maintainer o sono co-maintainer e quelle che ho fatto io o quelle che ho fatto io o quelle che ho fatto io con altre persone oppure quelle che nel pieno della frustrazione del perché non fossero supportate, alla fine mi sono accollato io.Adesso sono maintainer come maintainer di una ventina di librerie di Elixir, quindi a me l'open source il 99% del tempo che ci dedico è dedicato a quello, non a Elixir, cioè all'ecosistema sarebbe, intendo, quindi a mantenere librerie.Tanto triaging su github di ishu, di pull request, cioè tutte le cose che succedono nel mondo dell'elixir, ovviamente quando stai appresso a 20-25 librerie, sono tanti perché pure se per ognuna sono pochi, si accumulano, quindi la giornata tipo è che mi faccio un'oretta la mattina magari di questo tipo di lavoro dove faccio triaging e cose così e poi lavoro al mio lavoro normale che è in Elixir, però non è open source.Per fortuna tante volte negli anni è capitato di poter lavorare più intensamente su open source perché magari ho fatto da consulente per aziende che avevano, che usavano qualche libreria che volevano feature più importanti, insomma più lavoro.Io mi sono potuto dedicare in quei momenti magari a fare cose pagate per fare open source full time o anche è successo sia a un paio di aziende fa che all'azienda dove lavoro adesso usiamo delle librerie che io ho fatto, che ho fatto e ci sono servite di fare delle feature quindi mi sono potuto dedicare magari 100% per qualche giorno al lavoro open source però questo è il tipo di giornata Mamma mia che bello! Ti giuro! Io per il momento non ho altre domande, a parte te devo dire una cosa, ma chi lo mantiene Makeup? Non lo so! Makeup per gli amici ascoltatori è una librerì, è una cosa che praticamente fa il syntax highlighting dei sintasti arbitrari, nel senso c'è il plugin, c'è tutto fatto a plugin, c'è il plugin dei C, dei Erlang, dei Elixir, vabbè quello dell'Elixir, c'è la documentazione dell'XIR, il syntax highlighter sotto è Makeup.Io volevo sapere chi era il maintainer di Makeup, perché io tempo fa ho scritto un syntax highlighter che è quello di Rust, che secondo me con Rust l'era già zicca un sacco, però ho provato a chiedere di aggiungere a Readme il supporto questa cosa dei make-up, però dei make-up rust e tipo ho beccato un thumbs up, dei cose va li e basta e quindi stavo a cercare di capire come muovermi perché vabbè questo è il momento personale, la mia storia, il mio Ted Talk all'interno di questa montata.Guarda, non lo so chi lo mantiene e ti dico di più, non lo voglio sapere perché se poi io mi interesso, vado su Makeup e comincio a vedere gli issue, le cose, me lo accollo perché io ho capito che così funziona, s'ho fatto così.Quindi tante cose, proprio faccio tipo i cavalli, mi metto le cose ai paraocchi e non ci guardo perché...Bravo! Cioè finché non mi serve, prego che non mi servirà di dove fai il syntax sliding in Rust perché poco poco poi mi va a servire e così funziona.Cioè, capito, è successo tante volte.Io volevo stare un po' dietro, anche a make up, perché ho detto "è figo che ha fatto tutto con nimble parts" però comunque c'erano un po' di issues, volevo cominciare a fare un po' di cose, però mi sembrava un po' ghosted quindi ho detto "ma chissà, dopo ci arrivo a vedere" dopo ci riprovo, io non mollo mai questa cosa e ragazzi avete delle altre domande? ok se vogliamo dedicare il nostro tempo a studiare elixir dobbiamo liberarci della zavorra aprire e gestire una partita IVA è uno di questi pesi di cui facciamo volentieri a meno per liberarcene, evitando di generare danni, è quasi sempre necessario affidarsi a un professionista professionista, che vuol dire cercare informazioni online oppure recarsi di persona presso uno studio.Ciò significa dover andare ogni volta in centro città, trovare parcheggio, attendere il proprio turno, eccetera, eccetera, eccetera, eccetera.Esiste un modo smart per farlo che è affidarsi a Fiscozen, che collabora anche con Gitbar per realizzare appunto questo episodio.Chi è Fiscozen? FiscoZen è un servizio per aprire e gestire partita IVA online che però ci mette a disposizione un commercialista dedicato che ci segue dall'inizio del nostro contratto e che possiamo contattare via email, chat e persino telefono.Tutto questo appoggiandosi a una piattaforma evoluta che tra le varie cose ci permette di emettere e inviare fatture elettroniche e quindi anche di avere una previsione in tempo reale sulle tasse che andremo a pagare.Per quanto riguarda la dichiarazione dei redditi ci pensa sempre Fiscozenco, il suo commercialista dedicato e quindi senza costi aggiuntivi ci manda il modello F24.Se quello che ho detto vi interessa potete cliccare nel link che trovate in descrizione o nelle note dell'episodio per ricevere una prima consulenza gratuita e senza impegno con un esperto fiscale in modo da toglierci tutti i dubbi e le domande relative appunto alla partita IVA e poi eventualmente anche 50 euro di sconto sulla sottoscrizione per il primo anno qualora poi decidiate di procedere.Grazie Fiskozen.Io ne ho una da Gnubo.Vai, vai.Quando sempre in quel famoso Code Motion di cui vi ho parlato all'inizio si parlò di Elixir, lo si presentò come un linguaggio esoterico, no? C'era proprio questa voglia di presentarlo come quasi la setta, se non la famiglia di Charles Manson, qualcosa di simile.Una cosa che ti devi mettere la tunica per sviluppare, devi essere uno stregone del quarto, si programma solo all'interno di dei dungeon.Tu quanti gallineri hai ammazzato nel core team, scusa! Adesso noi ci stiamo ridendo su questa cosa però in realtà molta dell'immagine che ne venne fuori fu questa.Venne fuori l'idea di un linguaggio fighissimo in un ecosistema molto interessante e poi voglio parlare con con te magari della relazione tra Elixir e Phoenix e paragonarla alla relazione tra Ruby e Rails.Però in realtà l'idea era quasi che ok sì ma non è fatto per me non sarò mai all'altezza di poterlo fare che è un po' quello che in parte sta succedendo con Rust oggi.Però in Rust sto vedendo un'adozione diversa, cioè sto vedendo che la gente bene o male si mette, si sta mettendo su Elixir proprio ho visto questa questa resistenza, no? E quindi mi chiedo se era un problema di comunicazione o proprio anche un problema di curva d'apprendimento? Ok bella la domanda, no? Da come me l'hai detto, insomma, il primo istinto è di dire che era un problema che era dieci anni fa Cioè che questo è successo dieci anni fa, all'inizio di LXIR e in un mondo della programmazione diverso Se tu vedi il successo che ha avuto Go, per esempio, secondo me è dato dal fatto che quanti sono usciti dall'università, dai college sapendo il Java e il C, è ovvio che vedi il Go è uguale, no? Quindi lo capisci troppo più facilmente Anche perché Go si lo impari in 15 minuti esatto, lo impari un quarto d'ora e stai sereno, esatto.Invece l'XIR è un par...già parte da un paradigma che è la programmazione funzionale che dieci anni fa era molto meno, come si dice, molto meno...permeava molto meno nel mondo, secondo me, della programmazione.Dieci anni dopo siamo messi molto meglio, cioè se guardi un sacco di quello che sta succedendo front-end, già solo javascript di sé ha aggiunto tante cose tipo di programmazione più funzionale, dei vari map, reduce, tutte le cose da programmazione diciamo da programmazione basica funzionale e quindi tante persone sono molto più familiari con queste cose.Poi Go per esempio ha fatto i channel di Go sono molto simili all'actor model di Erlang come funziona, quindi la concurrency è diventata un po' più, secondo me, meno di nicchia, cioè fare queste cose di questo tipo e alla fine secondo me è cambiato il panorama, cioè adesso non è...dieci anni fa sinceramente era più difficile capire, cioè capire, no? Magari però imparare un linguaggio tipo l'exil era più difficile perché c'era meno cultura generale su questo tipo di...cioè su tante di queste cose, sulla lingua gifunzionale eccetera, invece adesso secondo me...e in più era un linguaggio nuovo è che non è mai...cioè un linguaggio nuovo è sempre difficile perché non ci stanno risorse, non ci stanno...cioè c'è poco materiale per imparare, adesso invece sono dieci anni di Elixir, dieci anni di domande su Stack Overflow, cioè insomma si è creata...ovviamente si crea molto più materiale per poter imparare e in più è cambiato secondo me il panorama, cioè le persone...magari io non lo so in Italia, io quando ho fatto l'università io non è che ho ho fatto un corso dove c'era un accenno di lingua di programmazione funzionale, però so che adesso per esempio nei college americani si fa di più, in tanti college studiano Erlang per esempio per studiare la concorrenza eccetera, quindi comunque c'è più esposizione, o almeno la mia sensazione è che ci sia più esposizione a questi concetti e quindi naturalmente un linguaggio come l'exil diventa meno esoterico.Rust per me è un enigma perché è parte è pazzesco, è bello come linguaggio, è figo, è molto interessante, il problema è che è molto low level ed è pure difficile, è un linguaggio, secondo me, è difficile, è pure di nicchia come utilizzo, se io devo scrivere un server o una web app in Rust è sprecato, è una cosa che mi devo andare a fare cose molto di basso livello, con un linguaggio molto di basso livello per fare cose però che che so di natura di alto livello cioè dove non voglio stare magari a pensare ai byte dove stanno allocati no però allo stack esatto cioè per perciò è enigmatico per me è molto bello cioè se dovessi iscrivere un sistema operativo ma hands down in Rust cioè ovviamente quello che fanno tanti Carmine ma lo sai che dobbiamo fa' mo' a sentì parlare dobbiamo fa' Rustler vitellone e io e Carmine ci siamo capiti.Poi ne parleremo anche con Andrea e anche con gli amici ascoltatori.Vitellone è Vitellone che è il nome di uno dei server che c'è nell'Oblad.Ah ok, Vitellone.No, Rustler Van Vitelli.è vero no c'hai secondo me c'hai ragione io so del ritorno da Rust lab, Rust in questo momento è uno dei miei linguaggi preferiti però comunque c'è nel senso per fare delle cose va benissimo tipo dei fazzi a live tool, ma pure il web server che ti prende una cosa e ti dice allo word va va bene però c'è per fa c'è l'ergonomia di mettersela e fa un'applicazione web strutturata con una cosa c'è sicuramente non è che ci voglia che fa con le mozze emantics terrestre vuoi un web server come phoenix penso sì cioè io penso se metti a confronto cioè se uno è che è difficile perché noi ma io non so voi però magari quando hai 10 anni 12 anni di esperienza c'è una visione talmente distorta del mondo della programmazione e distorta dalla tua esperienza che è difficile essere oggettivi però se a me ha intuito se mi metti davanti un programma scritto in Rust, un programma scritto in Elixir mi sembra più leggibile quello scritto in Elixir ma non perché ho lavorato dieci anni in Elixir, proprio perché è più alto livello come linguaggio quindi mi sembra c'è meno esoterico quello quindi non lo so secondo me adesso è migliorata tanto la situazione è vero all'inizio era era era considerato esoterico ma come però cioè io penso anche closure per dirla era considerato esoterico che adesso invece un linguaggio cioè penso molto mainstream quindi secondo me è cambiato un po' cioè grazie anche al linguaggio tipo tipo closure tipo che ne so no aske vabbè helm no cioè tanti linguaggi funzionali che hanno che hanno avuto tanto successo so piaciuti tanto quindi penso che la programma sia funzionale sia meno esoterica no Poi l'Elixir c'è questa cosa molto unica che è la concorrenza che non ci sta in altri linguaggi, cioè dove la concorrenza è così insediata nel linguaggio, nell'ecosistema, nella virtual machine, non ci sta.C'è Scala che ha H dove c'è sostanzialmente l'actor model, ci sta Go che ha degli aspetti tipo i channel che sono molto vicini, però in Elixir e in Erlang c'è permea veramente ovunque, quindi quello è ancora forse un po' esoterico, però è legato anche al fatto che Elixir non è un linguaggio, non è di nicchia, io direi ormai, però non è manco come il mainstream, come tanti altri.Non so se ho risposto, ho fatto un po' di...Ti faccio una domanda io.Che cosa ci hai fatto nella tua carriera con l'Xeer, NDA a parte, insomma, quello che si può sapere, e che cosa ne pensi della tipizzazione del mondo, diciamo, in generale? Non voglio dire Glim, voglio lasciarti dire a te, però che pensi, secondo te è una cosa utile? Allora che ci ho fatto io? Diciamo gli highlights delle cose interessanti che sono capitate a me di fare con il XIR.Ho lavorato un paio d'anni in Svezia per un'azienda che si chiama Forza Football, che fa un'app per i risultati di calcio.Io penso magari qualcuno l'avrà anche usata forse.Però insomma sono risultati di calcio e io ho lavorato per due anni sulle notifiche push con elixir, era tutto un sistema fatto in elixir per mandare le notifiche push che era una cosa molto importante perché c'avevamo fai conto 6-7 milioni di utenti, 5-6 milioni mi ricordo di utenti che se fa un goal che seguono magari hanno le notifiche push attivate, fanno Real Madrid-Barcellona Cristiano Ronaldo fa il goal e tu devi mandare la notifica push tre secondi dopo che fai il goal, se no non ha senso, se la mandi un minuto dopo quello che è.Quindi c'era molto, cioè questo era il sistema ed è stato fico.Abbiamo fatto insomma tutta una cosa che non c'era praticamente l'inizissimo di Genstage che è una libreria per fare...infatti mi stavo a chiedere ma l'avete fatto con Genstage? Non c'era Broadway, non c'era...cioè ai tempi io ho scritto un client HTTP2 per mandare richieste a Apple per mandare notifiche push perché non c'era Mint, non c'era niente, cioè non era un disastro.Ah non era Mint? Non era Mint, poi ho scritto Mint, la parte HTML Mint l'ho scritta io proprio perché c'avevo esperienza nell'averlo fatto per quello.Porca dogna.Però quindi quello è stato molto figo, cioè Cassandra e Lixir, cioè figo figo perché c'era un problema di scalare vero che era quello di doverle mandare velocemente le notifiche e questa era la cosa.Poi mi è capitato di usarlo, abbiamo fatto un sistema, due aziende fa abbiamo lavorato in un community, si chiamava ed era apparentemente le celebrità, persone famose, potevano parlare tramite sms con i fan e noi facevamo l'sms delle persone famose, cioè dove gli davamo il numero.Ah, community.com.Ma va, bellissimo.Ma bellissimo! Quello era tutto in Elixir e ho avuto la fortuna di entrare a far parte dell'azienda molto presto cioè quando c'erano pochissimi sviluppatori abbiamo fatto tutto un sistema event sourced in Elixir quindi molto figo, molto RabbitMQ e là in Elixir c'avevamo una settantina di microservices in Elixir fatto tanto l'XIR là.Molto Broadway, moltissimo Broadway.Abbiamo fatto tantissimo Broadway.Ho una domanda.Aspetta, aspetta, aspetta.Cos'è Broadway? Bro, scusate, Broadway è...c'è tutta una serie di...Genstage è...quello nominato prima, Genstage è una libreria per l'XIR che ti consente di scrivere un po' più ad alto livello delle pipeline di questi stage che sarebbero del codice, dei processi che eseguono del codice, che si passano dei messaggi e tu veramente hai queste data processing pipelines, cioè delle pipeline dove ti arrivano degli eventi all'inizio e poi vanno tramite questi stage fino alla fine, all'ultimo stage.Questo è Gen Stage.Broadway è un abstraction un po' più user friendly di questa cosa, quindi tu hai dei plug-in che ti dicono per esempio "Broadway quindi tu dici ok, gli dai le informazioni di dove ti vuoi connettere a RabidMQ e poi scrivi solo il codice per processare i messaggi che ti vengono da RabidMQ invece di dire ok, connettiti a RabidMQ, prendi il messaggio, fai l'hack cioè è molto alto livello, molto dichiarativo per fare queste cose e ci stanno insomma tanti plug-in per varie fonti da dove vengono gli eventi cioè ci sta AWS, SQS, ci sta B2B Q, Kafka eccetera eccetera insomma questo è Broadway.Parlo ovviamente come se tutti sapessero di che parlo.No no ed ecco quel XS è un po' difficile certe volte, però con Mauro no, però con me caschi bene pure con Carmine, ma io te volevo chiedere, ma i microservizi che avevate erano un'umbrella app gigante oppure erano 70 repo separati nel bene e nel male? ognuno col suo mix xs ognuno col suo mix sì infatti lì è stato interessante perché 70 repo separati in qualunque linguaggio dei file diventano problematici anche perché non ci avevamo manco 70 persone quindi manca di a ognuno gli dons in macroservice Mi avete triggerato una domanda ragazzi, qui è il momento che sto vivendo e la faccio a tutte e tre.Proprio in questa situazione voi cosa andreste? Andreste di monolite feature flag o di pezzettino per pezzettino, microservizio per microservizio, spappolati? Andrè, rispondete.Io ho una breve risposta, nella mia precedente esperienza avevamo più di 100 microservizi per un SAS e non eravamo nemmeno la metà e ci si è trovati comunque bene, secondo me è come le fai le cose, il monolite feature flag arriva il collega tuo quello smart, Anzi, quello di uno smart che fa la macro, schiaffa la roba dentro, non si capisce più niente.Ora, mi eclisso, prego.No, io non ce l'ho, risposta diplomatica, dipende, non lo so.Però io, quando ho saputo che fa con 70 repo, è difficile gestire per me 70 repo, perché ti devi concentrare tanto, secondo me, e devi investire tanto nel tooling che ti permette di gestirle, cioè noi avevamo, sinceramente non mi ricordo come si chiama, lo potrei andare a ritrovare per le show notes se ce l'avete, però avevamo un tool che ci permetteva di fare operazioni su tanti repository, cioè scrivi uno script che poi gli dici le repository e lui va e fa, che ne so, una PR e la merge a tutte le repository con dei cambiamenti e avevamo anche incapsulato tanto in alcune librerie interne, per esempio noi avevamo, per processare gli eventi di questo eventsware system e per pubblicarli a rapidenq avevamo una libreria che ci faceva tutto praticamente, quindi quando tu scrivevi il servizio era molto...cioè se succedeva qualcosa dove devi aggiornare la libreria o devi fare dei cambiamenti lo facevi nella libreria principalmente queste cose, quindi secondo me bisogna investire tanto nel tooling nelle cose perché se no se hai 70 repo diversi dove hai 70 microservizi e sono indipendenti funziona se hai 700 persone cioè dove ognuno capito ogni servizio ha dedicato un po' di persone che ci possono lavorare anche se poi i microservizi secondo me non funzionano in quel senso cioè se sono troppo micro non ci lavorano 10 persone, cioè se sono micro non ci lavorano 10 persone infatti io non ho mai...l'ho detto microservizi perché sono paraculo erano "right side services" non sono mai stato amico servizi perché se no c'è forse ancora peggio.Adesso per contesto nell'azienda in cui lavoro adesso Vips abbiamo un'umbrella app, un'umbrella app per chi non usa l'exir, è soltanto...qual è l'equivalente? Io lavoro solo in exir però che ne so c'è un progetto dove ci stanno delle applicazioni nella stessa le cose che possono condividere del codice volendo.Il buon monoripo di Yarn, tipo.Sì, è un monoripo un po' più smart, cioè dove è supportato dal linguaggio, dal tooling del linguaggio, lo supporta proprio Mix che è il build tool di Lixier, quindi è un po' più ergonomico però di una monoripo qualunque diciamo, dove ci metti solo il codice tutto insieme però il concetto è quello di monoripo.Una roba tempoverna o...Si, si, si.Si, tipo nativa dell'X.Ma anche delle funzioni di scaffolding come NeXo? No, lo scaffolding è tremendo, però quello è un problema che non abbiamo risolto ancora.Però sì, cioè non lo so se l'abbiamo risolto nel mondo della programmazione in generale, comunque abbiamo 7-8 applicazioni lì dentro quindi per ora funziona bene e siamo pochi quindi non so come funzionerebbe una monoripo con 10.000 PR ogni giorno poi fate mix release e vi escono 10 binari separati abbiamo sì sì cioè le facciamo release separate cioè diciamo sì li impacchettiamo le applicazioni separatamente con delle alcune sono solo dipendenze altre sono applicazioni che facciamo girare invece che figo ok per ora funziona bene però ripeto siamo c'è un team veramente piccolo e so poche applicazioni cioè non è una cosa megalitica insomma quindi ma e che cosa fanno ad apple con l'Elixir, sono estremamente curioso.Certo, ho lavorato un anno Apple con Elixir e io lavoravo nel team Environmental Supply Chain Innovation, che sarebbe...Non ti diciamo cosa facciamo! Sì, sono quel nome...era insomma dove facevamo cose relative all'ambiente, alla supply chain di Apple e cose per l'obiettivo che hanno nel 2030 di fare tutto carbon neutral, tutti i prodotti.Ho sempre in atto che posso dire qualche cosa legata tipo non lo so a FaceTime o ai messaggi magari no no era roba diciamo sto pesando la causa la querella di erano diciamo cose abbastanza tranquille fatte con elixir cioè non abbiamo spinto elixir ai limiti di quello che può fare elixir come che ne so se uno legge io consiglio a chi non conosce l'elixir esempio di andarsi veramente a leggere cosa ci fa Discord o cosa ci fa Whatsapp.Discord con Elixir, Whatsapp con Erlang, però quello che ci fanno loro è roba veramente pazzesca.Quello che facciamo noi.Io non ho mai fatto roba di quel genere, neanche in altri posti.Comunque sì, era roba abbastanza così.La cosa di Apple è che è talmente grande che cioè io stavo in un'isoletta piccolissima dentro ad Apple dove ho avuto pochi contatti con le stelle di Apple ma proprio per come è strutturata Apple, cioè non è che io vado su Slack o abbiamo il donut, quello su Slack che ti fa un co-worker una settimana da conosce e vado là e parlo con Tim Cook e gli dico "Buonasera" quando esce l'iPhone, cioè non è, era molto, sì è talmente grande è come se fossero magari più aziende unite, no? E quindi io non so se ci fanno anche altro, tutto qua quello volevo dire, però ci stanno ci stanno aziende, cioè Apple purtroppo è una di quelle aziende dove se lo usano loro fa una pubblicità mostruosa e l'XR qui gli manca questo, cioè gli manca una pubblicità mostruosa dove lo usano i Netflix e i Twitter e i...Beh, in realtà sta cosa non è vera, cioè nel senso che c'hai ragione, lo usano tutti però non lo dicono, è come Berlusconi quando ha vinto le elezioni nel '94, non l'aveva votato nessuno.Grazie per il bellissimo effetto anche di France, mi sento veramente il Joy Tribbiani di questo podcast.C'è WhatsApp che usa Erlang, Facebook che siccome sono tutti terrorizzati da metterci le mani, dentro Meta si entri e ti dicono "per i nuovi progetti noi non usiamo Erlang by policy.Poi c'è Discord che usa Elixir, poi c'è Figma, Figma è stato fatto nell'Elixir.Pinterest ha avuto un periodo d'oro, poi l'hanno faced out perché non c'era gente, però Pinterest è stato un super early adopter, nel 2015-2016 usavano per roba di caching, se mi ricordo bene, per roba importante.Ma ce ne stanno tante di aziende che lo usano, però di "very big player" non ce ne stanno tanti.I Google della situazione, i Twitter della situazione non ce l'hanno.Netflix so che ce l'aveva per un po', ce l'ha avuto, però insomma ci mancano...e soprattutto vedi, non è che se tu cerchi Apple e Lixier lo sai che usano Apple mentre Discord e Whatsapp sono molto vocal sul fatto di utilizzarlo perciò io ho consigliato loro tra l'altro perché hanno scritto tanto su come lo usano ed è pazzesco, quello che ci fa Whatsapp con Lixier d'altronde siamo in Italia quindi tutti usiamo Whatsapp 6 ore al giorno quello che ci fanno Whatsapp è pazzesco i volumi di dati che c'ha Whatsapp sono incredibili e le videochiamate, tutto, cioè fanno di tutto e quello è Elixir, è Erlang e tra l'altro sono pochissime persone, cioè il team di...- 20 persone erano quando l'hanno acquisito - Esatto, erano 20 persone che l'hanno scritto in Erlang e io ho amici che lavorano a Whatsapp, tra l'altro uno è stato un core team member di Elixir che lavora adesso a Whatsapp e ci ho parlato qualche...- Figo - E ho ho fatto un keynote a San Francisco all'inizio di quest'anno insieme sul palco insieme a un ragazzo che lavora a Whatsapp, Maxime Fedorov, insieme al ragazzo che lavora a Whatsapp e stavo prima di fare questo keynote ne parlavamo e lui mi ha detto guarda cioè noi abbiamo siccome ovviamente Meta ha acquisito si è comprato Whatsapp e quindi abbiamo un influsso di persone da Meta cioè che ci danno risorse, cioè ovviamente abbiamo persone.Tante volte il il nostro problema è cosa fargli fare, perché Whatsapp funziona con quelle 40 persone che lavorano su Whatsapp e lui va.E quindi non sappiamo, infatti per esempio questo mio amico che è stato nel core team dell'XIR che lavora per Whatsapp, lavora principalmente su type system per Erlang, tooling per Erlang, language server per Erlang per il editor, cioè lavora su cose relative molto più alla la virtual machine che le reazioni emoji su whatsapp, quelle le fanno in pochi.Per me è una success story pazzesca, quella di whatsapp e discord sono...cioè io già legge quelle direi ok, di base twitter in elixir, bluesky in elixir, cioè tutto in elixir perché dici "porca miseria se ci sono riuscì a fare whatsapp per me funziona sempre" cioè funziona sempre e funziona bene e più di così sì sì infatti piccola parentesi infatti io ho sempre trovato inesplicabile il fatto che mastodonno sia scritto in ruby con tutti i svantaggi infrastrutturali che questo si porta per non mettere 2g server io e quella è la cosa fantastica infatti c'è sta pleroma che tutti quanti se lo installano e dicono l'unico problema che c'è è che dopo un po il database diventa lento perché devi devi fa un po dei barbatrucchi, però il resto funziona da paura e il binario è uno perché dentro tutta l'infrastruttura che tu hai dei processing degli eventi non ti serve sidekick non ti serve niente c'è la ngoti piena figata Sto piangendo dentro, so cosa hai detto da Roberto.Esatto.Io ho anticipato una domanda però che provavo a comparare il rapporto che esiste tra Ruby e Rails e tra Elixir e Phoenix che è il suo framework web, se non mi sbaglio.Perché in realtà chiunque in qualche modo ha usato Ruby è venuto da me a parlarmi di Phoenix e di Elixir.E quindi mi chiedo questa che relazione c'è tra il rapporto tra linguaggio e framework e che relazione e rapporto c'è tra il linguaggio e linguaggio, quindi tra Ruby e l'Xeer e tra Rails e Phoenix.Quindi immagina questo graficchino dove ci sono le relazioni dirette e le relazioni incrociate.Allora intanto tra l'Xeer e Phoenix io direi è meno presente la codipendenza.Cioè, forse io, almeno io non è che c'ho un'esperienza pazzesca nella community Ruby, c'ho fatto un po' di Ruby all'inizio della carriera, o seguo un po' ovviamente quello che si può seguire, però non è che ci sto super dentro.Però Ruby e Rails mi sembrano molto più legati, cioè, dove veramente tanti di quelli che usano Ruby usano Rails, no? invece su Elixir specialmente adesso si vede di meno, magari tanti usano Elixir, specialmente con l'uscita di tutti questi framework come NERV per gli embedded devices, tutta questa roba di machine learning, anche Broadway che ho nominato prima, cioè vedi magari tante persone che usano Elixir per processare eventi senza un'interfaccia web su questa cosa, quindi che lo usano senza un web framework, quindi secondo me, o almeno la mia percezione è che siano meno legati l'Xeer e Phoenix rispetto a Ruby e Rails.Poi è vero che tanti usano Phoenix ed è anche vero che tanti usano, almeno nella mia esperienza, che tanti usano Phoenix e poi non vanno veramente a imparare l'Xeer, cioè diciamo non è che li dissociano tanto ma li tengono molto vicini, cioè che Phoenix sarebbe l'Xeer, insomma, quindi c'è anche quello.Immagino succeda anche per Rails, perché penso che anche Rails abbia questo aspetto, però non lo so.Un altro aspetto è che Rails ha un minimo di concorrenza nel mondo Ruby, cioè ci sta Anami, che l'ha fatto...come si chiama Luca? comunque ci stanno Anami per esempio, c'era Sinatra, ci stanno tutti questi framework che fanno concorrenza a Rails perché Rails è mastodontico, cioè se io devo scriverlo in API con 3 endpoint non uso Rails magari Elixir non ha questo, tra virgolette, problema perché si usa Phoenix praticamente sempre cioè c'è un livello più giù che si chiama Plug che è tipo Rack per Ruby, se avete utilizzato Ruby cioè sarebbe come se fosse un'interfaccia per definire cose che processano le richieste web a grandissime linee, cioè come se fosse una base, un toolset per fare cose tipo Phoenix e poi c'è Phoenix, però Phoenix viene utilizzato veramente quasi sempre se devi fare qualcosa sul web, anche solo in API, anche solo in API con pochi end point, cioè comunque si usa tanto tanto Phoenix, quindi nel web Phoenix ha quasi una presenza incontrastata nell'Xero, mentre in Ruby forse ci sono anche altre alternative, come Anami, altre alternative.Quanto riguarda invece tra Phoenix e Rails, sicuramente Phoenix all'inizio è stato ispirato tantissimo da Rails, anche nel paradigma di MWC dove c'era il model view controller, cioè è stato molto molto ispirato a Rails.poi ha preso una strada sua, specialmente con i channel che sarebbero un'abstraction sulle websocket che Rails non aveva all'inizio.Quindi poi Phoenix si è molto distaccato con questi channel, tanto da poi adesso siamo in una situazione in cui almeno secondo me c'è molto più Rails che guarda quello che fa Phoenix che viceversa perché Phoenix ormai si è trovato una sua strada molto indipendente dove abbiamo fatto, cioè abbiamo fatto, parlo della community, non ho fatto niente, però abbiamo, c'è stato i channel, adesso c'è LiveView, LiveView io non so se si conosce però sarebbe un modo di scrivere, cioè di fare rendering dell'HTML sul server in real e mandare solo gli update al browser.Credo che Rails abbia fatto una cosa simile, ma io sinceramente non è che ci sto così dentro.Però credo che Rails abbia appena fatto l'equivalente, diciamo, e hanno fatto l'equivalente anche per i channel un paio d'anni dopo che ci sono stati i channel in Phoenix, che erano Active Cable, mi sembra.Quindi comunque adesso mi sembra che Phoenix sia...cioè Phoenix non è che ci guarda più tanto a Rails, cioè hanno una loro strada con con live view con tutta sta roba che Rails invece, cioè penso si sia almeno per un per un paio di feature più grandi si sia ispirato a Phoenix parecchio però secondo me le due community si sono separate tanto cioè mentre all'inizio chi lavorava in Elixir praticamente quasi sempre veniva da Ruby, c'era molto più dipendenza della community di Elixir, della community di Ruby adesso non mi sembra così cioè ci sono io vedo tante persone che già lavorano in elixir, punto, ma che lavorano in elixir da ormai talmente tanto tempo che non seguono più ruby quindi si è diventata molto più maturata, molto più indipendente la community di elixir, non so se è una risposta sì, sì, sì, sì, lo è, lo è, assolutamente io posso confermare comunque io ho fatto veramente due cacchiate Poi il resto, quando mi sono avvicinato a Elixir, mi sono avvicinato perché era proprio figo Elixir.Era ancora il tempo tra l'altro di quando dovevi fare comunque application, punto start delle dipendenze a mano.Non c'erano parecchie cose che sono arrivate dopo, tipo formatter.Era appena nato, credo, c'era un anno.Tooling fuori di testa, linguaggio bellissimo.Per esempio adesso, cioè all'inizio, una decina di anni fa, anche un po' di meno, era molto più comune la situazione in cui uno aveva sviluppatori che facevano Ruby full time e si appassionavano all'XIR, quindi facevano diciamo tutti e due, no? Quello era il senso.Oppure di aziende che stavano riscrivendo pezzi del loro sistema in XIR e il sistema era in Ruby.anche io ho partecipato a queste cose dove magari avevi il monolite in ruby e cacciavi un servizietto in elixir quindi era molto...cioè uno lavorava spesso in entrambi, quello intendo io ho parlato con tantissime persone che day to day facevano un giorno 60 ruby, 40 elixir e adesso la mia sensazione è che non ci sia più sta cosa la maggior parte delle persone con cui parlo fanno l'XIR 100% se fanno l'XIR quindi perciò mi dà la sensazione che le due community ormai siano molto indipendenti cioè è ovvio ci sarà dell'influenza ovvio nella sintassi c'è dell'influenza ci sarà per sempre l'influenza dei rubri però per ora mi sembrano più indipendenti di come erano prima, insomma erano più legate Io ho una domanda legata al tuo libro, cioè proprio al libro tuo e del tuo programma.Come stisci la notizia di quando vado nel libro e fanno una domanda? No, no, no, ma sì, io sono letteralmente andato a vedere...Dobbiamo promuovere.No, so...letteralmente andato a vedere il libro perché c'è un capitolo apposta ma io non me lo ricordo e quindi te lo chiedo sperando di non risultare invadente ok ma è una domanda che mi è venuta sti giorni a Rust Lab tra l'altro per tutt'altro motivo ma quando è secondo te che è meglio cioè no che è meglio che è necessario passare da un testing del tipo normale tra virgolette a un approccio property based? se la risposta è sempre oppure se ci sono tra i dossi? però però diamo un po di contesto quindi testing normale e testing property based - Sì, il property based testing è un modo di fare testing che è abbastanza di nicchia, cioè per testing normale intendiamo quello che pensate che intendiamo dicendo testing normale, cioè il testing normale, invece il property based testing è una tecnica per fare testing che si basa sulla randomizzazione degli input dove tu praticamente prendi un pezzo di codice che vuoi testare gli tiri, cioè degli input generati a random secondo dei criteri tipo deve essere un intero però poi un intero random, deve essere una stringa però poi una stringa random, le lanci a questo pezzo di codice e poi verifichi delle proprietà di questo pezzo di codice, ecco perché si chiama property based testing, quindi tu per esempio la funzione valore assoluto no, la funzione ha un valore assoluto e prendo un intero e ritorno il valore assoluto di quell'intero, tu prendi il dominio di input di quella funzione che sono tutti gli interi negativi, zero e positivi e dici qual è la proprietà, una proprietà di questa funzione? Beh la proprietà di questa funzione è che il risultato è sempre positivo e poi non vai a vedere il risultato specifico perché spesso poi, questa è una funzione semplicissima, però per funzioni, per pezzi di coce più complessi diventa più complesso capire, cioè diventa più complesso testare l'esattezza dei risultati e quindi si testano delle proprietà del risultato questo sarebbe il property based testing a grandissime linee.Per la domanda di quando utilizzarlo è molto soggettivo e dipende molto dal caso io l'ho utilizzato tanto per esempio per cose di protocolli di network dove decoding e encoding cioè per esempio se io se dovessi scrivere una libreria per fare encoding e decoding di JSON o di qualsiasi altro formato lì sarebbe utilissimo perché poi prima di tutto io non l'ho mai utilizzato e non consiglio di utilizzarlo da solo, cioè sempre insieme al testing normale perché il testing normale ti garantisce che tu su degli input esatti che tu sai il tuo codice fa delle cose esatte che tu sai, che ti aspetti che faccia.Quindi quello io lo lascio sempre lì.In più il property based testing su queste cose ti permette di testare, cioè di trovare dei corner case che rivelano dei bug nel tuo codice, testando un sacco di input, quello è il senso.Quindi io lo consiglio in genere su cose di questo tipo su encoding e decoding oppure su...che ne so io ce l'ho in utilizzo in una libreria che fa course, c'ha gli header course quindi gli genero le richieste a caso, gli dico che vai tramite la mia libreria e se ci sta ci deve avere sempre un valore che ha più o meno sta forma, quello è il senso che io lo utilizzo.Poi c'è tutto un mondo per lo stateful testing che non è anche lo stateful property based testing dove tu praticamente descrivi un sistema e gli fai fare cose a caso e ogni volta che fai una cosa vedi che se una proprietà del sistema rimane veritiera ma è molto più complesso.Dipende anche da cosa uno vuole ottenere col testing.In tanti casi aggiungere property based testing è un investimento abbastanza importante perché i sviluppatori magari non sono molto familiari con il "property based testing", quindi è una cosa da imparare.Specialmente stateful property based testing è molto difficile, cioè magari ci passo tanto tempo a scrivere dei test, ed è pure difficile scriverli bene, poi magari c'ho i bug nei test, ovviamente, quindi è più complesso.Dipende dall'utilizzo, cioè se io devo fare una cosa che è molto delicata, che è pezzo di codice è molto importante voglio stressarlo tanto io per esempio stateful property faccio l'ultimo esempio l'unica volta che ho utilizzato stateful property based testing è per testare un client di redis che ho scritto in elixir e per cioè per testare il client stesso perché quello dici ok è un client che lo utilizzano cioè che c'ha che ne so 3 milioni di download su ex quindi evidentemente lo utilizzerà tanta gente per fare cioè lo stressano tanto in in tanti modi voglio essere sicuro.Al lavoro non l'ho mai scritto perché al lavoro non mi è mai successo.Cioè uno come al solito "move fast and break things" quello è il senso, cioè io devo fare cose, cioè non posso perdere una settimana a scrivere un pezzo di codice, una settimana a testarlo perché non funziona così il mondo delle start up dove ho lavorato sempre io, quindi questo è il senso.Io mi sono fatto un'idea molto più ignorante e meno dettagliata di come la state descrivendo e me la sono fatta proprio quando stavo leggendo il libro in realtà.Se dovessi scrivere ad esempio la libreria che fa validazione e dovrei fare la funzione che va da una stringa, un intero, userei il property based testing.Perché mi interessa stressarlo con tante cose.Altrimenti no.Cioè nel senso questa...io mi ricordo ero a spiagge a Giuli e ho detto "ah sì, farei un web, insomma, una roba molto più ignorante.Ti richiedo di Glimm.Sì, sì, sì, tipico.Perché io spero che arrivi una cosa del genere prima o poi, ma non come Glimm, perché è totalmente altro linguaggio, insomma, non...Sì, sì, sì.Glimm, per chi non lo conosce, è un altro linguaggio che è come l'XR, cioè con T-Line bytecode della virtual machine di Erlang, con sintasti mi sembra tipo camel, no? Io non è che l'ho mai usato veramente, però tipo camel.Sì, tipo una roba...in realtà mi ricorda più Kotlin, anche proprio come compatta.Ok, Kotlin non l'ho mai letto neanche, penso.Però sì, comunque è un altro linguaggio tipo l'exil, statically typed, di diverso, cioè la cosa più importante.I tipi, la mia opinione, a me piacciono, però io sono, in inglese "anal" si dice, no? Sono anale su queste cose, cioè io sono un rompicoglioni, ma su tutto, cioè se tu entri dentro casa mia lo vedi che io scriverei il codice coi tipi perché ho fatto così, cioè sono proprio fissato sull'ordine, cioè per come sono fatto io lo userei tantissimo, mi piacerebbe averlo.L'opinione professionale è che si possono fare le cose con e senza, cioè ci sono vantaggi e svantaggi in tutto.Quello dei tipi per tante cose è vantaggioso, per altre è svantaggioso, per esempio per scrivere del codice in modo veloce e lavorare con input che non si conoscono bene, tutte queste cose io penso che i tipi spesso siano più un ostacolo che un aiuto, cioè dove uno deve, nelle fasi esplorative, per esempio me magari vado a lavorare con una nuova API che non conosco, in quella fase esplorativa in cui io gli faccio richieste, faccio il debugging delle risposte, vedo di che si tratta, eccetera, e tutto quanto, in quel caso sia come se fosse meno, cioè è più un ostacolo perché non mi fa mo...cioè è come se io dovessi sapere già cosa voglio, devo già dichiarare i tipi e tutto quanto, solo per, cioè che ne so, per esplorare nella fase esplorativa quindi in quel caso non lo so poi è ovvio in un sistema grande a veri tipi spesso è molto utile perché dice ok io tocco una cosina qui e mi si rompono altre sei cose me lo dice il compiler e questo ovviamente cioè per me mi sembra positivo in generale quindi ci sono pro e contro Il mio sogno è quello che sta succedendo in elixir se va in porto cioè che stanno lavorando ci sono tra l'altro Giuseppe Castagna, si chiama, un italiano che fa il professore in un'università in Francia e c'è un suo PhD student e loro due stanno praticamente facendo ricerca accademica sui set theoretic types, che è un tipo di di static typing basato sulla teoria degli insiemi eccetera con l'idea, con elixir come il fulcro della loro ricerca quindi insieme a Giuseckel che è il creatore del linguaggio, quindi stanno lavorando attivamente, hanno pubblicato un paio di paper e stiamo cercando di inserirlo, di inserire questo asset in Excel che sarebbe abbastanza graduale, cioè dove l'idea sarebbe non è che da un momento all'altro io, cioè, tipi sì, tipi no e quindi se metto tipi sì devo scrivere i tipi a tutte le funzioni dove l'idea sarebbe avere as much as possible di type inference, cioè dove il compiler lo capisce da solo e in più di poter dire un po' come fa TypeScript, l'idea sarebbe di tipo quello che fa TypeScript dove non è che io devo fare typing di tutto.Avere una cosa del genere per me sarebbe il top perché per come sono fatto io probabilmente magari metterei tipi dovunque e anche in codebase più grandi penso che avrebbe un'utilità più importante avere tipi, però mi piacerebbe poter rimanere a scrivere del codice che non ce l'hai, molto dynamic, dove io dico aspetta io voglio solo fare una richiesta, voglio vedere il JSON che mi torna, fare il decoding del JSON e scrivermelo sul terminale perché lo voglio vedere, voglio essere, lo voglio poter fare ancora, quindi per come stanno, cioè per come si stanno evolvendo le cose, quello sarebbe il mio mondo ideale, però irone che ho lavorato particolarmente con linguaggi stati retyped, solo un po con Rust.Personalmente ti ringrazio di aver detto che anche tu sei un uomo mortale come tutti e usi IOinspect e console.log.DBG ormai, DBG in Elixir.Ah questa mi annuovo.l'ergonomia di buy bug per ruby è inarrivabile adesso l'hai detto andrea e lui lo scrive io sono non mortale, non ho mai usato un debug nella mia vita quindi per i per i giovani ascoltatori console log andate tranquilli anche perché se avete dei codici...io vengo dal mondo javascript e se il codice è per sbaglio un po' troppo async e con compromise e cose particolari alla fine usare il debugger è un bagno di sangue invece il buon vecchio Puz console log, quello che è, top! ma hai mai usato l'observer davvero? cioè nel senso io lo uso per roba di debug, però non ho mai conosciuto nessuno che mi abbia detto "sai ho utilizzato l'observer" e l'ho utilizzato anche per andare in moto.Io una volta sì.Addirittura.No, ma perché ho detto "poi io ho scoperto che potevo fare le stesse cose con Ioninspect, adesso con DBG" e ti dico "oh, cannavo".Però mi sono andato a vedere lo stato di Engine Server.Sì, no, perché sempre per dare il contesto, Observer sarebbe un tool GUI che ti fa fare molto in inspection del sistema running della virtual machine eccetera.No, però non penso di averlo mai usato in production perché di solito la parte di monitoring, cioè si spera che uno ci abbia cose più stabili tipo Prometheus, insomma dove c'hai il grafana dove sono cose vere, non la GUI anni 80 di Observer.Oh, guarda, rispetto Giulio.Observer ha la stessa UI, mi hai presente? Il barter in aim, no? Tipo con mille mila form.Sì, sono Wix widgets, è terribile.è terribile però fa il suo lavoro però per fare debugging in production ha sempre fatto tramite la console cioè tramite la ihex tipo lo stato di un genserver l'ho sempre scavato così ovviamente Observer è un po' più ergonomico però però è meno facile da avere a disposizione spesso però la cosa figa effettivamente questa è una cosa che non si dice mai di Elixir e Erlang ma ahimè delixir perché io so, è un fanboy, è il fatto che tu ti puoi attaccare a un cluster bm esistente con una shell dal tuo computer e runare le funzioni dalla...- Puoi guardare lo stato, puoi spezionare lo stato dei processi, cioè puoi fare tanto debugging su un sistema live collegandoti a quel sistema, siccome avere più nodi collegati l'uno fra loro sono è una prerogativa diciamo di lì c'è della BIM della virtual machine è stata fatta è stata pensata così per avere cioè tu hai visto machine collegate fra loro questa è una cosa che non si dice mai io non lo dico mai perché è raro che si faccia però una cosa pazzesca della BIM è che la BIM ha la distribution built in cioè tu puoi collegare dei nodi Erlang e Elixir diciamo Elixir tra di loro senza nessun tool, cioè non devi avere...si parlano nativamente tramite messaggi Erlang e Elixir, non devi usare HTTP, non devi usare un rabbid enqueue in mezzo, niente, cioè si parlano fra di loro.Questa è una cosa che io...ecco è quella che dicevo prima della distorsione dei dieci anni di utilizzare Elixir che per me è scontato, però per chi non usa Elixir e viene da altre piattaforme dove io per far parlare due nodi che...che ne so, due nodi che fanno girare java io per farli parlare devo magari mandarmi cioè farmi delle richieste http tra l'uno e l'altro grpc quello che è invece in elixir volendo quello si può fare nativamente cioè in airline realtà nella virtual machine quindi quella per cioè quella è una cosa molto figa si fa poco però è una figata ragazzi fighissimo.C'è una domanda che non c'entra niente, però secondo me interessa a tutti qui dentro.Come si scrive un libro tecnico e come si promuove un libro tecnico? Speriamo che sia una cosa mainstream ma non troppo, nel senso magari se io dovessi scrivere l'ennesimo libro su Yuki React io abbezzo, ok? Me lo posso pure copiare, ce l'ho su Scriatch, non lo scrivi meglio.- Tanto non li sanno usare nessuno.- Eh non li sanno usare nessuno, Yuki React anzi fai questa bella prefazione e dici ti ricordi quando c'erano le classi? anzi ora dico una cosa e poi censuriamo era più bello React quando c'era la classe bei tempi di...a terza B la classe no, così sono estremamente curioso, cioè come si scrive un libro tecnico e come lo si promuo...cioè come si fa? Come si scrive? Tipo Markdown principalmente.Allora intanto come uno viene...dipende dal publisher.Io ho avuto un buon rapporto con Pragmatic Programmers, che è la mia casa editrice con cui ho pubblicato il libro, perché è la casa editrice che ha più libri sull'Xeer quindi è dove per noi è stato più ovvio parlare con loro perché hanno una collezione di una libreria di libri sull'Xeer abbastanza importante insomma quindi un libro testing l'Xeer.Mari su O'Reilly ci stonava invece lì ci stava bene diciamo come collezione che offrono.Come si scrive un libro tecno? un bagno di sangue, chiedete, non so chi l'ha detto prima, ma è un bagno di sangue vero, cioè è durissima, perché cioè non ho mai scritto un libro non tecnico, quindi per me un libro tecnico che vado a scrivere, io ho scritto un libro, non so se tecnico è diverso dal romanzo, però la parte, cioè per me la parte di nozioni è stata la parte più facile, perché sono, cioè uno lo scrive su cose che sa, diciamo, di base, no? Quindi uno lo scrive su nozioni, su esperienze che ho accumulato anni e anni, quindi la parte di contenuti non manca, almeno per me è stata così.La parte che è il bagno di sangue è organizzarli e scrivere un libro che tu lo leggi e non vuoi morire, che non è così semplice, penso.Quindi quella parte è difficile, organizzare i contenuti, presentarli in un modo che sia interessante in più che le parti del libro si colleghino, cioè che io dico una cosa che però non vado troppo in profondità su quella cosa perché poi ne devo dire un'altra dopo, cioè quello è stato...cioè scrivere in un modo che fluisce, che può insegnare cose alle persone, fa casino, cioè per me quello è stato difficilissimo.Poi la parte di scriverlo è molto macchinoso, cioè ci vuole tanto tempo, è macchinoso, ci stanno tante fasi di review, di technical review, e poi insomma dove ti dicono, no, qua...oppure insomma, non...è technical editor che ti fa l'editing, poi cioè ci stanno tante fasi di review del libro, ci vuole tantissimo tempo.Ne sto scrivendo un altro adesso...- Ma poi viene...ah sì? - Sì.Adesso ne sto scrivendo un altro da solo su network programming, si chiama Network Programming in Elixir e sarebbe su networking, cioè su tutte le cose di TCP, UDP, DNS, tutti i protocollini vari in Elixir.Pure questo, uno stima, dice "ok in sei mesi l'ho scritto" e sono passati, non so, dieci mesi e ne ho scritto mezzo, ma è sempre così.La mia curiosità adesso è la mia attenzione, come si fa Network Programming su Elixir? cioè nel senso usi Rustler e poi fai delle cose? No, GenTCP, GenUDP, Erlang ha librerie per tutto, si si puoi fare tutto.Ma è bellissimo, grazie, ma stanotte non dormo.Hai citato sette volte rastler, ma che è rastler? Allora, grazie per la domanda, Andrea che cos'è rastler? Rastler è una libreria in Elixir che ti permette di scrivere NIF, natively implemented functions, cioè ti permette di fare FFI, si chiama, una foreign function interface, quindi di scrivere del codice Rust e di usarlo da l'Elixir.Rustler ti dà questi pochi binding che ti servono per poter fare questa cosa, che poi è una cosa che Erlang supporta, cioè la Beam, la Virtual Machine supporta nativamente, che è quella di scrivere queste nif in C, o insomma C++ in quello che è, è quello che ti fa Rustler e ti fa il packaging molto semplice di poterlo scrivere in Rust e poi te lo compilano che ti fa le cose giuste per fartelo usare dalla BIM, essenzialmente.Il tooling ha fatto molto bene, integro un paio di cose perché quello il tooling è fatto benissimo da Rustler e lo dico anche perché Fabrizio che è la persona che ti mandava i suoi saluti ha fatto anche delle contribution a Rustler nell'ambito del progetto su cui lavoriamo perché c'erano un paio di cose che andavano fixate e il tooling è della madonna, cioè veramente bello bello bello e soprattutto il caso storico diciamo dei Rustler è che Discord aveva le sue nif in go che gli buttavano giù la BIM perché il problema delle nif è che se crashano buttano giù tutt'abim e macello, invece in Rust chiaramente tu puoi evitare tutto grazie al type system, alla correctness eccetera eccetera eccetera senza che mo stiamo qua a fare l'apologia di Rust, chiaramente queste cose succedono molto meno tendenti al non succedono e quindi discord ha passato la loro infrastruttura de nif tra virgolette da golang a rust con dei gain della madonna e noi abbiamo scritto anche delle madonne precedenti al ipodromi della madonna mi immagino no gli sviluppatori go che un bel giorno si sentono dire bene sapete cosa vi dico? Oggi riscrivete tutto su Rust.È la stessa cosa che si sono visti dire i programmatori Java.Adesso riscriviamo tutto in Go.Ma anche i programmatori desuse.Noi avevamo un monolite in Go che faceva delle cose, l'abbiamo buttato al secchio e l'abbiamo riscritto tutto nell'exil per fare la tua felicità.Sì, che tra l'altro al momento abbiamo due servizi in Elixir, di cui uno che utilizza Rustler.Ah, grazie.Cioè, sì, secondo me per la community di Elixir è abbastanza...no, rivoluzionario, però è abbastanza fondamentale una cosa tipo Rustler che ti permetta di fare queste cose, ma non tanto per...cioè è ovvio che magari un Discord scrive "cosa in Rust" per efficienza.io penso che sia per il Mario Rosti di turno, penso sia più utile ancora il fatto che il Rust ha un ecosistema molto grande, già rispetto all'Xero, perché ovviamente ci si sono fiondate centinaia di migliaia di persone sul Rust, e quindi ci stanno tante cose che...io faccio un esempio del cavolo, che è un algoritmo di compressione che si chiama LZ4, che è un algoritmo che Cassandra usa per fare compressione volendo e io siccome ho scritto insieme a un altro ragazzo il driver di Elixir per Cassandra per supportare questo algoritmo adesso posso...cioè ho fatto una libreria separata che usa Rustler perché ovviamente l'ho trovato fatto in Rustler cioè qualcuno l'ha implementato, è veloce perché è Rust e non mi sono dovuto impegnare a scrivermi io l'algoritmo di compressione nell'Xeer per me ha ancora più valore quello del fatto dell'efficienza, ovviamente Rust è più veloce per tante cose di Xeer però avere, che ne so se io mi devo fare, per esempio in Erlang e nell'Xeer c'è il supporto per gli schemi Thrift, di Apache Thrift, fa schifo quindi però qualcuno se si mette e fa il binding con Rustler probabilmente è una cosa che non è così difficile cioè queste sono le cose che per me Rustler ha...e in più sono veloce, ovviamente c'è una cosa che è veloce, cioè più veloce di Rixir sicuramente quindi sicuramente su quello separato l'unica difficoltà è che storicamente è un po' difficile cioè la BIM è molto intelligente in come fa le cose, per esempio non crasha e per esempio fa lo scheduling dei processi in un modo molto molto intelligente, molto eco tra i processi c'è molta logica su come fa lo scheduling dei processi di quello che fanno i processi eccetera e nel momento in cui tu ci metti una nif, cioè ci metti una di queste funzioni iscritte in Rust la BIM non lo può fare più, nel momento in cui la tua funzione stai seguendo, quella stai seguendo la BIM non la può toccare, cioè crea un po' di danno in quel senso quindi bisogna scriverle in un modo attento che siano...infatti dicono di farla sotto un millisecondo, cioè di non farla eseguire mai per più di un millisecondo, quindi ci sono, cioè devi ingegnarti magari a fargli fare yielding così che ridà il controllo alla virtual machine eccetera eccetera.Non è così semplice come magari sembra, però per me è utilissimo.Cioè avere una cosa così nell'ecosistema è fondamentale per fare tante cose.che è fighissimo.Infatti alla fine noi abbiamo utilizzato Rustler per integrare una libreria che c'era in Rust.Esatto.E' stato esattamente questo il caso.Esattamente esatto.Bene guardavo l'orologio siamo a un'ora e trenta io direi che se non ci fosse l'hard limit della puntata potremmo rimanere anche tutta la sera visto che siamo appena iniziando però ahimè un'ora e trenta diciamo penso che sia il momento giusto per passare al momento il paese di Balocchi ma prima vi devo ricordare, questa parte la fa meglio Alessio devo dire però faccio una una piccola introduzione, vi devo ricordare che siamo sotto periodo Black Friday e se volete supportarci perché GitVar ha dei costi che in realtà la prossima settimana mi siedo e li calcolo perché ho paura a farlo non più tardi di stamattina ho ricevuto una scheda d'acquisizione video nuova quindi mi farebbe piacere calcolare i costi di GitVar, però no, GitVar ha dei costi e se potete supportarci gratis praticamente intanto lo so che state andando a comprare la cosa più inutile da Amazon durante questo Black Friday, che sia un tagliaunghie elettrico o uno scaldavivande, comunque qualcosa la state andando a comprare su Amazon.Nelle note degli episodi c'è un link che è un link sponsorizzato, affiliato, voi partendo da quel link potete arrivare su amazon e adesso non so quanto duri la sessione ma credo per un paio d'ore avete la possibilità di in qualche modo darci una piccolissima percentuale degli acquisti che fate vi costa zero ma permette a github di continuare ad andare avanti quindi se non l'avete fatto facetelo.Ragazzi, c'ha Mauro c'ha una figlia, veramente, la deve mantenere, io pure c'ho famiglia, guardate che questa è un'attività che noi facciamo pro bono.Io c'ho un sacco di rate, è breve."Verti max, erate da barca con il volante radica di noccio" "Sono sacco dorato, mamma mia, ve prego" E poi dobbiamo mantenere il figlio di Alessio che mi ha mezzo ipnotizzato per una parte della puntata, che è il nanetto lucicoso volante, che è una figata allucinante, con il paracadute anche! arte modellissima! ma ero muto io l'avrò pagato 10 euro questo affare da un villaggio di Natale che sta verso Roma Sud a Infernetto l'ho visto, lui mi ha guardato dallo scaffale, io l'ho guardato ci siamo guardati un po' così e poi alla fine l'ho comprato sta qua da Natale scorso scorso non l'ho mai detto.Si lo so, infatti volevo aggiungere questo.Se lo merita, è bellissimo.Se lo merita, vi stace.Detto questo io direi che possiamo passare al Paese dei Balocchi."Riconduco nel Paese dei Balocchi" "Ah, il Paese dei Balocchi" Il Paese dei Balocchi è quel momento nel quale condividiamo qualcosa che sia un libro, un film, un video, una conferenza, un talk, un articolo, un qualunque cosa abbia catturato la nostra attenzione e in qualche modo pensiamo valga la pena di essere condiviso con la nostra community.Quindi la mia prima domanda è Andrea hai qualcosa da condividere con noi? durissima questa domanda però sì mi lancio con una cosa da nerd cioè Spark se non avete mai utilizzato Apache Spark andate a vedere cos'è Apache Spark è un coso che ti fa fare processing di big data ed è fichissimo l'ho utilizzato un paio di lavori fa lo sto riutilizzando adesso è bellissimo c'è un libro si chiama "Spark the definitive guide" di O'Reilly che ce l'ho là dietro ed è molto bello molto interessante.è una cosa da nerd come cose da una serie di Guli.L'ultima che mi sono vista è The Bear.Bellissima, vabbè però no no le cose da nerd ci interessano, non preoccuparti.Di Spark ne abbiamo parlato abbondantemente in una in uno dei primi episodi di Gitbar.Lo ripeto ogni volta, mia moglie è una big data engineer e a casa mangia pane e spark.Mi fa due cuoio.Pane e spark, bellissimo.E tra l'altro abbiamo citato H.Un eone fa Spark si basava sull'actor model di H.Non più.adesso c'è qualcuno che si è scritto il suo framework, altri sono passati a Elixir un giorno avremo Spark in Elixir ma infatti dello Stamovendia, scusa tu sai questa cosa? se hai fatto fai Spark, se puoi fai pure Spark Allora, giusto così io sono anni di ancora capire che cosa sia esattamente Adoop.Ogni persona mi dà una risposta diversa.Adoop è un sacco di cose.È un sacco di cose, è come Baltho, è uno o l'altro, ma non sa cos'è.Comunque, ma in realtà allora io faccio il faragudo, nonostante io l'abbia portato anche in un'altra puntata, io porto di Andrea come, insomma, balocco.È stata la seconda o terza volta che lo porto.Quindi Testing Elixir l'ha scritto...Lecchino! Grazie, io non lo posso dire, sennò che...Ha scritto Andrea, no, credo sia un ottimo libro, un master, se fate Elixir, ma in realtà credo sia abbastanza scorrevole anche se non lo fate, perché alla fine sono quelli i concetti.Secondo me è un ottimo libro sul testing, a prescindere.Compratelo cartaceo, è più godibile della versione ebook.Io ormai dico la stessa cosa sempre, io non riesco più ad aggiungere ebook sul sul computer e che non lo so, mi fanno male gli occhi, sarò diventato anziano.Prego Alessio.Mamma mia, cioè il libro di Andrea, con Andrea che ha prenduto in mano l'Andrea Cepelli.È un momento veramente speciale, tizia, cioè pensare all'opportunità di fare un framing così.Allora, io oggi vi regalo...Ecco, è stato Roberto da Crema! Allora, io oggi vi regalo una cosa che va in controtendenza rispetto a tutte le cose che avete nominato, però, o forse chissà, nel senso poi è anche interessante per il prossimo libro di Andrea, che è "Learning BPF" dell'Izrais, dell'Aureli.perché io in questo periodo mi sto a intrippare un botto con i BPF, BPF is love e BPF is life e quindi imparatevi i BPF, o meglio non ve lo imparate perché così arrivo io e mi danno un sacco di sordi, perché lo so è troppo figo, per chi non conoscesse che cos'è i BPF praticamente è una cosa che è nata in un modo e è finita in tutt'altro nel senso che era nata come una piccola virtual machine all'interno del kernel di Linux che esegue del bytecode che sostanzialmente fa inspection dei pacchetti, dei rete che arrivano eccetera eccetera e poi però è diventata tutt'altro nel senso che ci hanno aggiunto il supporto per i cosiddetti kprobe, ovvero il monitoraggio di tutte le syscall che iniziano e che finiscono, quindi pure al return, dentro il kernel e quindi noi ci possiamo agganciare all'entrata delle syscall del kernel o all'uscita e possiamo eseguire con questi hook del codice arbitrario ci è anche rast e chissà magari anche lì xir con le nif e io ho finito vostro onore fantastico un altro task io mi stanno apprendo popopopopo una serie di task devo dire che per l'ennesima volta mi ha solleticato l'idea di fare qualche prova su xir ma questo periodo doi me non ho il tempo perché sono completamente assorbito da portare gitbar e lavorare a il progetto FOURVIER che è appunto il software che stiamo scrivendo open source per la gestione di un feed RSS per il podcasting quindi open podcasting.Ieri ho fatto ho terminato una parte dell'integrazione per R2 di Cloudflare per l'upload degli episodi e del feed su R2 di Cloudflare e devo dirvi che è tanta roba R2, veramente veramente tanta roba con un free tier che non è generoso è di più.Parla la lingua franca di S3 quindi il protocollo di S3 che ormai credo siano rimasti veramente pochi o object storage che non implementano in qualche modo questo protocollo.Buttateci un occhio ripeto perché il free tier è babbo natalesco.A parte questo, sempre parlando di podcast, è altra cosa soprattutto.andate nel repo di Furvie se c'è qualche alieno che vedete nel codice se non avete voglia di fixarlo almeno tirate su una issue così capiamo quanto o capisco quanto faccio cagare come sviluppatore devo intanto ringraziare Flavio per il suo provvidenziale aiuto nella parte RUST quindi platealmente grazie Flavio comunque detto questo è fatto questo uso spudoratamente personale del podcast, voglio portarvi un balocco particolare, voglio portarvi un podcast che non pubblicava puntate da un sacco di tempo.Il podcast si chiama "Vita da informatici" che non parla di sviluppo software ma racconta le storie di un ragazzo in sala server ed è una cosa fantastica e hanno pubblicato due episodi qualche settimana fa, uno questa settimana e uno la settimana scorsa, sono molto belli, il titolo è "Fibra rottica" e siccome il host di questo podcast, questo podcast è un podcast narrato, ok? E l'host di questo podcast ha in realtà come informazione personale l'essere un fonico e tra l'altro c'è anche una copywriter che lavora con lui per fare questo podcast.Poi in realtà lui lavora davvero, fa l'informatico, gestisce l'informatico d'azienda, che gestisce la sala server.E le storie che racconta sono allucinanti.prendetevi veramente prendete il vostro client di podcast fate la subscription ascoltatevi un episodio io sono sicuro che vi pisciate addosso come mi sono pisciato addosso io ieri sera mi sono divertito veramente tanto.In coda a questo allora immagino che sarà attivo la storia e le storie della sala macchine.Una roba tipo le storie della sala macchine esatto ok esatto hai hai aperto un altro...bellissimo.Andrea, è stato un super piacere fare questa puntata che tra l'altro sta per arrivare alle due ore rispetto all'ora e un quarto che avevamo preventivato.Questo dimostra proprio quanto ci siamo di fatti divertiti.Quindi io ti ringrazio personalmente non so se Carmine e Ale vogliono dire qualcosa io ti voglio bene è stato un piacere, figa veramente figa anche per me grazie mille Quindi detto questo, Andrea, grazie davvero di cuore.Come noi diciamo di solito, una volta che si entra in Gitbar, Gitbar è come il circolo del dopolavoro, apparentemente il dopolavoro postale degli anni '80, quindi tu lavoravi alle poste, tornavi a casa, c'era tua moglie che ti preparava la cena e mentre tua moglie preparava la cena tu te ne andavi al circolo con gli amici a continuare a latitare da tutte le faccende domestiche.Ecco, Gitbar è un po' questo, o almeno per come lo racconta mia moglie.In realtà è il circolo di dopolavoro postale informatico nel nostro caso.E cosa succedeva? Alla prima volta che tu entravi nel circolo ti facevano la tessera.Da quel momento in poi tu eri socio del circolo.Quindi sentiti socio perché è tesserato con Gitbar.bar, per cui quando hai qualcosa di interessante, di figo nell'ambiente elixir, ma non solo, sentiti davvero libero di contattarci, di pingarci, perché in realtà qua da noi c'è sempre una birra fresca, handmade digitale, ma per ora questo è quello che passa in convento, però è un po' anche casa tua.Grazie mille, mi sono divertito tantissimo, grazie di avermi invitato, è stato un piacere.Grazie di cuore, grazie anche a Carmine ed Alessio che sono stati i barbara d'urso di questo episodio grandiosi.Che bello, dobbiamo riorganizzare un episodio anche dove siamo tutti insieme a fare Baldoria.Ma ci manca qualche mese, io ormai dico sempatissima, però ci manca qualche mese così.Sì, sì.Ma dici l'episodio quello dove voi vi mettete dentro un'aula che io non so qual è e poi io arrivo e ti mando...Diamo un po' di contesto ad Andrea.Si sta parlando di un episodio dove ci incontriamo quasi tutti e ci incontriamo al FOSDEM e l'anno scorso insomma siamo stati passibili di denuncia penale per effrazione.Abbiamo scassinato un'aula nel secondo piano dell'università.Cioè in realtà scassinato, abbiamo...si abbiamo aperto...dai era aperto, mamma mia, in università, so soldi pubblici, non i nostri! era aperto, però diciamo il piano era interdetto, era transennato, era aperta l'aula ma il piano era transennato quindi abbiamo scavascato e siamo andati a fare una bella puntata nell'aula quindi abbiamo fatto la puntata pirata, questa no, perché no, possiamo organizzarci per fare una puntata anche video dall'hackerspace? sarebbe fighissimo.quello sarebbe estremamente figo.se riusciamo anche se dobbiamo pagare un qualcosa tu prova a sentire i ragazzi dell'hackerspace.la puntata appena prima del rave possibilmente perché poi dentro l'hackerspace succedono cose si vede gente che insomma è meglio non mostrare quindi meglio fare a telecamere spente questa non siamo video però in realtà sarebbe veramente figo.Andrea ti abbiamo incuriosito per andare al Folden? sempre di più sempre di più.ho un albergo che mi dicono che sto facendo broma a tutti lì.ok detto questo io ragazzi vi ricordo rapidamente i nostri contati info che ho c'è la github.it @brainrepo su twitter il gruppo telegram @github nel vostro cliente di telegram preferito github e non github italia.ci abbiamo buy me a coffee nel canale preferenziale.è stato disattivato.Infatti non lo so come ci danno i soldi? Money transfer, bitcoin, cust di matrimonio non tracciato, terra luna.No in realtà oltre al classico pulsantone supportaci nel sito abbiamo anche la possibilità di venire supportati tramite il value for value attraverso dei client di podcast moderni, c'è la possibilità di poter associare il proprio o un proprio wallet Lightning e fare dei boost che sono delle donazioni con annesso messaggio di e correlato al minuto specifico dell'episodio e questo è molto figo perché è anche un modo per in qualche modo rispondere a quello che l'host dice o a quello che il guest dice e noi quei boost li leggeremo nella puntata successiva oppure c'è la possibilità di fare lo streaming di Satoshi quindi c'è una funzione dove voi potete dire ok ogni minuto del podcast dono un Satoshi.Un Satoshi è praticamente zero è una cosa che si approssima però nello stesso tempo noi vediamo questo stream di Satoshi che ci fa capire quali parti degli episodi avete ascoltato, quanto l'avete ascoltato e ci fa capire che ci siete! Prima di arrivare alla parte finale del nostro episodio vi voglio ricordare che se volete aprire o gestire la vostra partita EVA online eliminando gli ostacoli della burocrazia potete prenotare una consulenza fiscale gratuita e senza impegno con un esperto di Fiscozen qua nel link in descrizione.avrete anche 50 euro di sconto sul primo abbonamento.Detto questo io direi che possiamo salutarvi quindi vi do appuntamento alla prossima settimana un abbraccio ciao ciao ciao ciao [Musica] [Musica] Sottotitoli e revisione a cura di QTSS
