*musica* Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo Ma ahimè, lo stronzo è me medesimo e l'ho scritto giusto ieri *musica* Siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery Gli stessi per il quale il testing è importante, infatti la nostra codebase ha solo due test e flakey pure Siamo noi quelli che il tuo linguaggio fa cagare, ma il mio è peggio.Quelli che la chiarezza nei comment message prima di tutto, e dentro ce l'appella tutti i santi.- Se non bestemmi o guarda.Quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto.Quelli che non si può fare di default, diventa velocemente un tutto e possibile se hai le risorse, tempo e budget ilimitato.Siamo noi quelli che l'AI va regolamentata, ma hai visto questo nuovo modello che disegna gatti di funambuli? quelli che il dipende e unisci gratis la prigione e quelli che la RAL...no vabbè fa già ridere così siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente ormai rassegnati che la definition of ready è solo una più illusione quelli che si sentano dire "ho un'idea per un'app" ed è subito l'ennesimo social come instagram ma meglio Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.Bene e benvenuti siamo tornati di nuovo su Gitbar dopo un paio di settimane di pausa un paio di settimane a PUA, ho con me il mio compare di viaggio, il buon vecchio Carmine.Ciao a tutti ragazzi, bentornati, come si dice, bene e bentornati a Gitbard.Tra l'altro, prima ho visto che avevi la cam disabilitata e sembravi quasi sparito come Homer nella tua bellissima maglietta.Carmine, ci sei? Sconpasso per davvero.Sconpasso nella scherza.In realtà stavo scrivendo nella nostra chat, ho avuto un piccolo inconveniente con il bicchiere, quindi ecco, adesso ci sono.Allora, prima di iniziare, prima di insomma chiacchierare con l'ospite di oggi, volevo chiedervi scusa o comunque condividere con voi il motivo per cui siamo stati offline.Quello che vi starò per dire è una cosa molto personale e quindi un po' mi imbarazza, però si è creato questo rapporto di lealtà nei vostri confronti e quindi voglio essere chiaro.Avevo in piano di fare delle vacanze, quindi ho preso un periodo per andare giù in Tunisia, però nei piani insomma avevo quello di registrare gli episodi di GIT/Business as usual, quindi continuare a registrarli come sempre.Sono arrivato giù, ho staccato la spina i primi due giorni e mi sono reso conto che due giorni per staccare la spina non erano sufficienti, mi son trovato completamente senza energie e allora quando sei così senza forza è meglio che tiri il freno a mano, stoppi tutto, rimetti i remi in barca come si dice in linguaggio marinaresco, cerchi di fare il pieno di forza per poi ripartire.Ed eccoci qua e siamo di nuovo pronti per far ripartire una nuova programmazione di Gitbar.Intanto chiedo scusa a chi insomma ci ha supportato in questi giorni per non aver potuto rilasciare l'episodio ma insomma sta per ripartire una nuova sessione di Gitbar, bella carica.E con questo episodio, con l'episodio di oggi, inauguriamo appunto questo nuovo trenino di episodi super interessanti.Oggi abbiamo un ospite ma è divertente in realtà raccontare la storia con il quale abbiamo scovato perché diciamo che è così questo ospite.Qualche settimana fa in realtà Daniele Campogiani ci ha scritto su...mi ha taggato su...su X scrivendo "a quando un episodio su Glim.ran?" io, devo essere sincero, in quel momento non sapevo neanche cosa fosse Glim e la sono subito andato a controllare e con i miei potenti mezzi ho capito che uno dei core...Un membro del Core Team era italianissimo e allora ho detto "a questo punto bisogna invitarlo a bere una birra con noi".Con noi infatti abbiamo Giacomo Cavalieri, come vi ho detto, membro del Core Team di Glimm, è pronto a parlarci a funghi di questo nuovo linguaggio.Ciao Giacomo! Ciao a tutti, scusate non vi sentivo più dal microfono.Ciao Giacomo, ci senti? È un piacere essere qui, grazie mille per l'introduzione intanto.Ma ci senti adesso? Ma abbiamo conosso, è il bello della diretta insomma.Sembra un po' "mi mandarai tre" quando hanno un collegamento instabile.Giacomo ci senti adesso? Ok, ora vi sento proprio pronto per sentire il collegamento di Rai3.Fantastico.Ciao Giacomo.Intanto, benvenuto qua su Gitbar.Grazie mille.Noi ti abbiamo perso ma continuiamo a mandare tanto e tutto è tutto registrato.prima domanda che ti voglio fare è, ancora prima di parlare di Glim, la cosa che mi incuriosisce è come ci sei arrivato.Allora, è una storia non troppo lunga, quindi si può raccontare.Allora, parte tutto in realtà in università e in particolare negli ultimi anni della magistrale e mi sono appassionato un sacco di programmazione funzionale.Io ho Fanboy numero uno di Haskell, per esempio, proprio amore a prima vista.Allora ho detto "dai, proviamo a imparare, mi piace tantissimo".È una cosa che nel mio corso universitario non si è vista molto perché va fortissimo con la programmazione oggetti e quindi invece è una cosa che mi interessava tanto e sono diventato il ragazzo delle moladi nel corso, nel senso che io appestavo tutti i miei amici parlandogli di Askel, di queste meraviglie che mi piacevano tantissimo.Una volta finita la laurea magistrale, più o meno un annetto fa, verso marzo, ho iniziato a guardare in giro, a me piace tantissimo guardare linguaggi di programmazione e così via, e mi è capitato di vedere questo linguaggio Glim e mi è piaciuto tantissimo per un motivo che magari per molti può essere stupido.Però la home page di Glim è carinissima, da rosa, così via.E ho detto "cavolo, mi piace tantissimo, proviamo a entrare nel Discord di Glim e vediamo cosa succede".Sono entrato su Discord pensando, non so, presente quando entri tipo in un nuovo Discord con un sacco di gente e dici "vabbè, do un'occhiata in giro, guardo in silenzio, non mi noterà nessuno".E invece, cavolo, tipo, sono entrato e cinque minuti dopo hanno iniziato tutti a salutarmi, tipo a fare complimenti per l'immagine del profilo, cose del genere.Ho detto "oddio, ma sono gente effettivamente simpatica, piacevole e quindi niente, mi è piaciuta tantissimo la community e un po' il motto che uso io per Glim è che ti appassioni per il linguaggio ma poi alla fine rimani per la community, perché è veramente pieno di gente fantastica e poi mi ha dato la spinta per provare e iniziare a contribuire.Il mio primo contributo è stato un classico tipo fixed typo nella standard library, se non ricordo male, qualcosa del genere.Dopo ci ho preso gusto e da lì sono passato al compilatore e dopo, diciamo che è stata una fortuna di trovarsi nel luogo giusto, al momento giusto, ho iniziato a contribuire molto da quell'ambito e poi è successo di entrare a far parte del core team, ecco.Quello che hai detto sulla community è veramente interessante, a parte che sia la home page di Glim è super cute, sembra di essere dentro quei videogame in Japan style, no? E ha catturato anche a me l'attenzione.Però è vero quanto in realtà la community faccia un linguaggio e questo ne è la dimostrazione.Quando hai fatto la prima contribuzione, come la community ti ha seguito e ti ha accompagnato nell'evolversi, ecco.Ci sono state proprio delle azioni specifiche o...? Allora, io ricordo quando l'ho fatto è stato proprio lui, il creatore del linguaggio, a rispondermi sulla PR della Standard Library.È stato carinissimo anche lì, tipo "ah, così immergiata molto rapidamente e quindi è stata proprio un'esperienza piacevole, diciamo, sotto ogni punto di vista, nel senso che è sempre stato carinissimo nell'indicarmi cosa fare quando ero in dubbio, nel dirmi "guarda, forse questo approccio non va benissimo, prova con qualcosa di diverso" e mi rendo conto che questa cosa mi ha permesso anche di crescere tantissimo.Io probabilmente in quest'ultimo anno ho fatto cose che non mi sarei mai sognato e che invece proprio anche grazie l'aiuto di lui e di altre persone nella community di Glim, mi hanno aiutato e proprio mi hanno guidato in questa esperienza e fino ad ora per me la luna di miele è ancora continua, diciamo.Io voglio farti una domanda.Glim è un linguaggio molto giovane e siamo super curiosi di capire come poi si evolverà e che spazio si ritaglierà anche a livello di utilizzo più globale, magari su grandi player e questo sarà un argomento che affronteremo tra abbastanza poco.Ma mi chiedo, io tutte le volte che approccio un linguaggio nuovo, una contribuzione nuova, io mi chiedo sempre "ma come posso rispendermi in altro modo l'effort che sto investendo in una certa direzione e questa poi diventa col tempo una malattia, nel senso devo sviluppare cosa ne so devo imparare Rust ok perfetto voglio contribuire a qualcosa bene come me lo posso spendere a livello lavorativo piuttosto che a livello di altri progetti quindi il cercare di cogliere due piccioni con una fava.Ecco, con un linguaggio nuovo questo è molto difficile.E come lo gestisci tu? Cioè per te il lavoro su Glimm è fino a se stesso o riesci a imbastire una strategia a due direzioni? Allora, diciamo che al momento non me la gestisco nel senso che sono disoccupato, quindi mi sono licenziato da poco in realtà.E quindi il mio tempo lo dedico a Gleam, ma è essenzialmente un lavoro da volontario nel mio tempo libero, che adesso è tantissimo.Diciamo che non sono mai partito nell'ottica di farlo per avere un ritorno o qualcosa, l'ho sempre fatto perché mi piaceva, mi divertiva tantissimo proprio.E non so se sei presente, non so, io quando programmi e devi fare qualcosa perché devi lavorare, devi avere uno stipendio per arrivare a fine mese e tutto quanto, ti tocca fare qualunque cosa e io mi sono reso conto che nel lavoro che facevo proprio non mi piaceva lavorare con le tecnologie che dovevo utilizzare.I colleghi erano fantastici, però nonostante tutto io non ero felice di programmare."cavolo ma io veramente voglio fare questa cosa che mi toglie l'anima praticamente" e quindi mi sono licenziato, ho iniziato a lavorare "tra virgolette" nel senso che poi è tutto volontario, a Glim ed è proprio divertente per me.Quindi al momento lo sto facendo puramente per il divertimento di farlo.Chiaramente se dovesse poi venirne fuori qualcosa perché verranno fuori dei lavori in Glim, ben venga, però lo faccio se non altro perché mi sto divertendo tantissimo, mi piace la community, appunto voglio aiutare.Bellissimo, guarda questa cosa te la invidio in modo del tutto del tutto bonario, cioè che poi è un po' il motivo, il modo con cui noi facciamo il podcast, però proprio a livello di sviluppo software io ho delle forti difficoltà ecco a fare questo.Vabbè c'è fur vie, no in realtà sto dicendo una cazzata, lo faccio anch'io, io adesso che ci penso però per esempio se parlo di furvie lo UI kit è per esempio completamente disaccolpiato perché ho detto ok lo faccio una volta così siccome devo fare un sas per un'altra cosa mi riuso lo UI kit però ecco quando ci sono dei contesti dove puoi fare questi giochi e dei contesti invece dove non hai grande grande scelta.A questo punto mi piacerebbe capire di più come organizzi il tuo lavoro? Perché oggi sì, tu dici non ho un'occupazione principale, però in realtà immagino tu abbia contribuito anche quando lavoravi.E come organizzi il tuo tempo nelle contribuzioni open source? Allora, quando ancora lavoravo diciamo che il classico trucco di togliere ore di sonno per fare più cose possibile, quindi una volta finito il lavoro mi mettevo lì, chiudevo il computer di lavoro, aprivo il computer personale e inizio a fare Glim.Adesso invece bene o male mi giostro la giornata più o meno come voglio, vedo quali sono delle issue che mi interessano, che mi sembrano alla mia portata e diciamo vado da lì e poi è sempre molto confrontarsi, chiedere aiuto anche ad altri.Ho imparato tantissimo questa cosa che invece diciamo non è mai abbastanza, avere l'umidità poi di cosfargersi il capo di dicendi di dire "non so fare questa cosa, ho bisogno di una mano".Invece secondo me è molto importante, ho imparato quanto sia importante farlo.Chiedere aiuto credo che sia una delle cose… come lo dissi? Come è detto in quel famoso talk a Code Emotion, chiedere aiuto è uno degli elementi che ti rende senior, saper chiedere aiuto in modo effettivo, è veramente importante nel senso che una volta che impari a chiedere aiuto poi impari a gestirti anche situazioni complesse perché non stai mettendo in ballo solo la tua forza, la tua energia, la tua conoscenza ma quelle di un'entità maggiore che è la somma delle conoscenze con le quali tu puoi raggiungere il contatto più accogliente, più psychological safe è la community, più questo può succedere, questo succede e quindi migliore è il risultato.Però adesso andiamo a parlare di Gleam.Lo pronuncio bene perché in realtà con tutto quel rosa mi veniva Gleam, però in realtà e Glim.Sì, Glim.Aspetta, prima di chiederti questa cosa, perché in realtà è anche un inside joke del podcast, c'è Glim Italia? Oppure no? La community Glim Italia? Scusa, non ho sentito l'ultima parte della tua domanda.No, c'è Glim Italia, c'è una community italiana di Glimm? [Manu] Ah ok, allora, che io sappia no, nel senso che conosco ragazzi italiani che conoscono Glimm, programmano in Glimm, ma qualcosa di organizzato proprio come consapevolezza di essere una community Glimm Italia eccetera, no, diciamo che al momento c'è l'unico discord di Glimm che è proprio il punto di ritrovo per la community, si parla lì, però diciamo che di italiani ne conosco pochi, sto cercando di far accadere questa cosa, quindi ho iniziato nella mia università per esempio a mettere su un gruppo di studio di programmazione funzionale in Gleam chiaramente e quindi mi piace pensare che si sta formando effettivamente un qualcosa di più e chissà magari poi diventerà effettivamente la base di una Gleam community italiana.Ok, sono curiosissimo di vedere come evolve.Poi offline magari se vuoi ti diamo anche qualche contatto di eventi italiani che possono essere interessanti, dove secondo me ha senso che persone come te vadano a portare un po' di novità con nuovi linguaggi, nuove strategie e tutto ciò.Andiamo un attimo su...Io sono un po' arroginito, non ne state accorgendo? Ho un po' di attrito nel muovermi, perdonatemi, ma un mese di stop fa anche questo.Andiamo a parlare di Gleam.Che cos'è? Noi sappiamo che è un linguaggio di programmazione, ma se volessimo andare nei dettagli, cos'è che lo rende unico o diverso dagli altri? Allora, Gleam è un linguaggio di programmazione innanzitutto funzionale, nel sito si dice anche amichevole.Secondo me proprio un punto di forza di Gleam è il fatto che è un linguaggio molto semplice, nel senso che ha una, diciamo, poche feature, queste sono molto potenti, molto espressive, ma diciamo sono proprio quel set minimo di feature ortogonali fra loro per avere un linguaggio espressivo, piacevole da utilizzare, e appunto questo poi è tutto impacchettato in un bellissimo linguaggio funzionale che può compilare sia verso Erlang chiaramente nella Beam, oppure verso JavaScript e quindi si presta bene anche allo sviluppo front-end, per esempio.Secondo me, come dicevo, il punto veramente di forza è la semplicità.Un programmatore, diciamo, che abbia già qualche competenza, in un pomeriggio probabilmente riesce a vedere tutto il tour del linguaggio e a conoscere tutti i meccanismi del linguaggio.Non c'è nessuna "magia" diciamo fra virgolette strana, difficile da capire.Sono poche feature, queste poche feature però sono tanto espressive e soprattutto ortogonali fra loro.Quindi uno dei, diciamo, mantra di Glimm è che non ci dovrebbero essere due modi di fare una stessa cosa.Se si aggiunge una nuova feature è perché deve sbloccare effettivamente qualcosa che prima non era possibile o che era molto difficile fare.E quindi questo proprio cuore piccolino, potente, espressivo, secondo me è molto interessante.Sento "puzza" nel senso positivo, di go, no? Nel senso che hai detto due elementi che me l'hanno riportato alla mente, no? Cioè il fatto di un linguaggio che si impara in un pomeriggio, ok? E il fatto del...un solo modo per fare una cosa.Insomma, con Go questa cosa è stata praticata, provata a praticare in tutti i modi, però poi alla fine con l'evolversi del linguaggio abbiamo visto che non c'è mai un unico modo per fare una cosa e che la community di Go si diverte a dire "questo è il modo giusto, tutti gli altri non lo sono", ma fondamentalmente è un modo diverso.la mia domanda è...siamo probabilmente in un early stage, il linguaggio è abbastanza giovane immagino, no? A pochi anni, giusto? >> DIMARCO PERLINI: Allora, io credo probabilmente il primo commit è vecchio di sei anni, se non sbaglio.Ma diciamo erano ancora momenti in cui non c'era l'idea del linguaggio probabilmente come oggi, come si è formato oggi.Ci sono stati un paio di anni di stasi totale e poi è ripartito e dopo è evoluto in quello che conosciamo oggi come game.Però sì, è giovane, la versione 1.0 è stata rilasciata da pochissimo, due mesi fa, quindi diciamo ancora sì è giovane.Si vedevo tipo marzo, febbraio marzo.Sì e quello che mi chiedo è il fatto di avere un set limitato di funzionalità, limitato nell'ottica di appunto far fare una cosa in un modo idiomatico.Quanto pensi sia legato al fatto che il linguaggio è giovane? Perché detto tra di noi, col tempo che passa un po' si smerda qua e là appena entrano degli stakeholder che dicono "se io lo sto usando in ambito enterprise o in ambito wide ho bisogno anche di di Java".Sì, è una bellissima domanda perché è vero, un linguaggio parte sempre con una bella idea ben definita e poi col tempo si aggiungono feature, feature, feature, diventa il solito calderone dove va a finire un sacco di roba.Chiaramente non posso predire il futuro, io non so quello che succederà, ma lui è molto convinto di questa cosa, cioè è proprio un punto chiave nel design del linguaggio.La sua idea è quella di non aggiungere proprio niente se non sia strettamente necessario e l'ha proprio detto "c'è poco spazio per nuovi feature", nel senso che il nostro focus principale vuole essere su rendere la developer experience il migliore possibile, migliorare tutto il tooling che c'è attorno al linguaggio senza la necessità di dover appunto aggiungere feature su feature su feature.È capitato spesso che magari arrivano persone che chiedono come si faccia qualcosa, esempio classico "perché Gleam non ha le interfacce, perché Gleam non ha i trait o come li vogliamo chiamare type class o qualunque cosa, comunque non vi vogliamo darci, sarebbe bellissimo averli perché ci permetterebbe di fare un sacco di cose diverse e la risposta è sempre la solita, non abbiamo bisogno di questi meccanismi perché vogliamo mantenere il linguaggio, diciamo, focused, concentrato su un cuore ben delineato senza aggiungere aggiungere aggiungere solo perché la feature è interessante oppure è una cosa che cattura l'attenzione, sembra interessante quindi ma sì dai aggiungiamola perché tanto cosa vuoi che sia.Quindi c'è molta attenzione da questo punto di vista.Secondo me è, diciamo, proprio una filosofia che rida il linguaggio e quindi non posso predire il futuro ma io direi con una buona sicurezza che il Gleam che programmeremo fra diversi anni non sarà troppo diverso da quello conosciamo già oggi.Guarda, pensavo a una cosa mentre parlavi.Pensavo a una bilancia con due piatti.Da una parte la parte core del linguaggio, dall'altra l'ecosistema.Più ristretta la parte core, più l'ecosistema tenderà a proporre soluzioni e tenderà a proporre alternative basate su quella parte core limitata.Qual è la mia sensazione? E' che trovare l'equilibrio per questi due pesi, adesso non parlo di Glimm nello specifico perché non conosco quello che ci sta sotto, le dinamiche, no? Però trovare un equilibrio, parlo di un qualunque, parlo di JavaScript, ok, che è il TypeScript che è son casa mia, trovare un equilibrio tra questi due elementi è veramente complicato, per cui se tu non hai, alla fine, non hai uno scope creep nel linguaggio, ce l'hai nell'ecosistema.e quindi inizia a vedere PMPM, Yarn, inizia a vedere 70 librerie per fare gli state manager e cose di questo tipo.Quindi in realtà è veramente challenging guidare un linguaggio dicendo teniamo il feature set limitato perché vogliamo limitare anche il carico cognitivo di di chi lo usa, cioè è una bella sfida e riuscirla a fare nel migliore dei modi è complesso, specie se stai guidando un linguaggio super cute che vuole passare un'immagine super cute perché secondo me l'immagine non è a caso, cioè è proprio un messaggio, quello fa parte proprio della natura del linguaggio, altrimenti l'immagine non sarebbe stata così forte, no? Quindi Lucy si chiama la mascotte, se non mi sbaglio.Lucy si la mascotte, sì.Dico, sì, sei in un contesto con una community così friendly, in un contesto molto, molto aperto e nel contempo accogliente.Però poi devi anche dire dei no serrati che sai magari in un quando il linguaggio è giovane non sono pochi poi come il linguaggio cresce diventa tutto più difficile e da questo punto di vista mi viene da chiederti a livello di linguaggio gestito? Nel senso c'è un maintainer centrale che guida tutto e si prende oneri e onori, quindi anche la responsabilità di dover dire no, o c'è uno steering, un piccolo steering committee? Come funziona la decisione? Allora per il momento per come funziona essenzialmente quando qualcuno ha bisogno di qualcosa, trova un problema, una feature mancante, qualunque cosa, quello che succede è che si apre una issue su GitHub o magari se è nel Discord di Gleam se ne parla lì e poi gli si chiede di aprire una issue per poterne discutere per esempio su GitHub e poi dopo si cerca di capire quali problemi potrebbe risolvere questa nuova feature, che il linguaggio al momento fatica a risolvere in maniera semplice, se ne parla e l'ultima decisione spetta sempre a lui in questo caso.Quindi è lui che poi si ritrova a dire "no, guarda questa cosa Gleam non ce l'avrà, perché?" e poi ti dice la motivazione di design che c'è dietro.Diciamo che non è un no secco, nel senso la tua è una brutta idea, chiaramente sono tutte belle idee, nel senso che le proposte che ci vengono fatte nella maggior parte dei casi sono per delle feature bellissime.Il problema è che non è quello il focus di Gleam, quindi avere 3 interfacce e così via, diciamo non lo vogliamo proprio per una scelta di design e poi sì in maniera proattiva propone una soluzione, quindi per esempio in questo caso non hai bisogno di usare questi meccanismi ma ti basta utilizzare quest'altra cosa, guarda potresti leggere questo articolo che è molto interessante, parla proprio di questa scelta di design e così via.Quindi diciamo che sì è molto fermo nella sua decisione di dire no, ma chiaramente non è un atteggiamento, diciamo, di attacco all'altra proposta.C'è sempre, diciamo, questo motivare la scelta poi del perché una feature non entra nel linguaggio, perché chiaramente un no può lasciare, diciamo, un po' con la mano in bocca, ma c'è sempre una motivazione dietro e, secondo me, l'importante è sempre quello di essere chiari e spiegare perché una certa feature o meno è, diciamo, desiderabile nel linguaggio, oppure no.Andiamo a parlare del linguaggio vero e proprio? Ho una domanda.Vai Carmine.Ok, che in realtà è legata al linguaggio.Io uso l'Xeer tutti i giorni.Mi piace tantissimo, è l'Xeer fan, uso Phoenix, uso Commanded che è un framework per fare event sourcing e mi piace tanto.piace tanto LXIR perché mi ricorda Ruby, Ruby è sempre il mio primo e d'unico amore, insomma io sono molto affezionato a LXIR e ho sempre visto con un po' diciamo...C'è chi ha millantato "amici secondi presidenti" per quel linguaggio eh? Ah sì? Ok.Io non...ho sempre visto con diffidenza Glim, cioè nel senso se io...io scrivo anche Rust, purtroppo o per fortuna, però nel senso l'ho visto molto molto simile a Rust, anche come Sintassi, ok? Cioè non mi ricorda molto...non mi ricorda molto ovviamente non è una colpa del linguaggio, non è quello il core, però diciamo l'ho sempre visto un po' di infidenza, anche perché diciamo il fatto che compila anche su JavaScript e poi è stato utilizzato per il frontend un po' mi ha ricordato Elm, che non è proprio il massimo dell'usabilità, io non so se qualcuno di voi ormai abbia utilizzato Elm, mi è bello il tutorial, cioè tu fai il tutorial, bello, dopodiché diventa una mazza incredibile da mantenere se tutto il team non è veramente in quel tipo di mindset, insomma.Ecco, se io come, diciamo, sviluppatore Elixir io scelgo di utilizzare Gleam, che compila anche sulla la BIM, che cosa mi ritrovo, diciamo, dell'ecosistema della BIM plastico? Ad esempio, OTP, tutta quanta la gestione dei processi.Cioè, se voglio fare un GEM server in GLEAM, lo posso fare, ne ho veramente bisogno e soprattutto, alla fine, che cosa esce? Cioè, il prodotto che va nella BIM, una specie di FFI, cioè come fa ad arrivare quel codice nella BIM.Allora vado in ordine per po' settini.Sommiglianza con Rust? Sì, in realtà la somiglianza con Rust posso dire è solo a livello sintatico, quindi parentesi graffe, public function, del genere, in realtà poi le similarità si fermano lì più o meno con Rust.Però sì, è vero, l'aspetto è molto simile, infatti molti si approcciano pensando che ci siano più cose in comune con Rust, in realtà alla fine poi non sono così tante perché chiaramente Rust ha un target completamente diverso.Poi, seconda cosa era il fatto che Gleam possa compilare sia verso, targettizzare sia la BIM che JavaScript.E come programmatore Elixir cosa aspettarsi? Allora io purtroppo metto già le mani avanti nel senso che non sono esperto della parte lato BIM, nel senso che conosco Erlang più o meno, di Elixir veramente conosco pochissimo purtroppo.È uno di quei linguaggi che mi sono sempre detto "voglio impararlo perché mi piace tantissimo l'idea" e poi invece quando mi sono messo lì per impararlo è stato proprio il momento in cui ho scoperto scoperto Glim, sono stato preso da Glim e quindi da cosa nasce cosa non sono mai riuscito poi a dedicarmici completamente.Quindi purtroppo lì conosco poco.Però ti posso dire, Glim quando viene compilato viene compilato proprio in file Erlang, quindi produce codice Erlang che tra l'altro è anche molto bello da leggere, nel senso che il codice prodotto è anche formattato bene, è molto più bello di molto codice Erlang che per esempio scrivere io che non sono disperto di Erlang, quindi da quel punto di vista il compilatore fa un lavoro molto migliore di me.Quindi il risultato essenzialmente prodotto a quel punto sono dei file Erlang che possono essere utilizzati come vuoi.Gleam poi ha un'ottima storia di FFI, Powering Function Interface, quindi quando mi chiedevi per esempio cosa posso aspettarmi dell'ecosistema Beam, da quel punto di vista è molto facile avere una dipendenza per esempio Erlang che voglio utilizzare nel mio progetto, perché proprio l'idea di Gleam è di non rendere così tanto complicata, cioè rendere molto semplice tutto l'interfacciarsi con il linguaggio target, quindi che sia Java, Script, Erlang, in futuro chissà, magari Wasm, e quindi diciamo da quel punto di vista non perdiamo tutto l'ecosistema meraviglioso della Beam, ma possiamo per esempio sfruttare altri moduli che invece ci vengono offerti.Quindi per esempio, esempi che mi ricordo, abbiamo un wrapper di un decoder JSON, se non sbaglio, che viene riutilizzato quello per esempio, se non sbaglio si chiama TOAS, non sono sicuro però non vorrei dire una cavolata.Comunque ci sono molti package, per esempio, che proprio vanno a wrappare quelli che sono delle interfacce sottostanti sia che siano Erlang che JavaScript, ecco.Quindi diciamo, OTP c'è, ne ho bisogno, mi serve...Ah, anche lì...Io ho visto...ok, sì.Sì, dipende molto poi da quello che vuoi fare.Io non sono molto esperto di questa cosa perché in un anno intero di programmazione in Gleam non ho mai sentito il bisogno di andare a avere un modello ad attori, tutte le cose meravigliose che ci offre la BIM e così via.Quindi quello che può succedere è che magari riesci a passare tantissimo tempo programmando, programmando cose anche diciamo complicate, senza avere poi bisogno effettivamente di dire "cavolo ho bisogno della BIM sotto", perché stai scrivendo logica applicativa, cose che magari non richiedono questa distribuzione che ti dà la BIM e quindi non ti capita neanche anche di sentire il bisogno di dire "vado, mi serve OTP" e così via.Però c'è un pacchetto Gleam OTP che è proprio, diciamo, l'idea tipata di OTP in Gleam.No, figo, figo.No, no, nel senso perché, ad esempio, io ho prima visto alcuni esempi di OTP in Gleam e c'era comunque lo spawning di task asynchrone, ad esempio.Era quindi senso quella roba lì poi, in maggio, tipo che su JavaScript ti venti una promise tipo e magari probabilmente l'esempio, forse intendi l'esempio sul sito, vero? Tipo nell'home page del sito dove vengono spawnati.Probabilmente è quel codice che può essere eseguito solamente quando si targettizza la BIM e quindi se si prova per esempio a dire "voglio compilare questo codice verso JavaScript" ci viene detto "guarda non puoi farlo perché richiede una dipendenza invece da Erlang e così via.E quindi anche lì, diciamo, c'è una divisione per certe cose perché se io, per esempio, a quel punto la scelta, diciamo, dell'autore della libreria è duplice.Posso provare a supportare entrambe, diciamo, entrambi i target di compilazione e spesso è ragionevole farlo per molte cose.Per esempio un decoder JSON, chiaramente utilizzerò decoder JSON diversi, ma vado a chiamare FFI e lo faccio su entrambi i target.Invece a volte non ha proprio senso dirlo perché magari c'è chi sta scrivendo dei binding verso le API del browser perché sfrutta il fatto che Gleam compili verso JavaScript e chiaramente se io voglio utilizzare quel codice perché voglio interfacciarmi con il browser in un linguaggio tipato non potrò eseguirlo invece sulla BIM e quindi il compilatore lì sarà attento a dirmi "guarda questo pezzetto di codice può andare solo su JavaScript e quindi stai provando a mandarlo su Erlang non puoi farlo".Ok, E a livello invece di linguaggio vero e proprio ci sono come dicevi tu no ci sono delle feature che hanno compilano e targettizzano per dei target specifici a questo punto mi chiedo abbiamo un linguaggio tipato quindi abbiamo la possibilità in qualche modo di avere una verifica upfront fatta magari attraverso l'uso di un language server.Intanto volevo chiedere, esiste un language server per Gleam e se sì come si comporta nei contesti dove hai proprio queste scelte legate al target? Io sto scrivendo del codice, quel pezzo di codice Gleam è specifico di un certo environment Lo vedo nel mio Visual Studio Code evidenziato in rosso perché magari nella configurazione della compilazione ho messo "target Erlang".Non lo so, non conosco il linguaggio, sto dicendo cazzate.Ci siamo andati vicinissimo.Ci siamo andati vicinissimo.No, sono molto contento che mi hai chiesto del language server perché secondo me è uno dei punti di forza di Gleam, tutta la parte di tooling.Gleam, proprio l'eseguibile Glimm, ha già al proprio interno un sacco di cose, come per esempio Package Manager, quindi tutta la gestione di dipendenze eccetera eccetera viene già in automatico, non ho bisogno di installare altri tool esterni; ha già un formattatore, un formattatore che non ha nessuna configurazione, quindi quando vado a formattare il mio codice l'aspetto sarà uguale per tutti i progetti che vado a leggere.Questa è una cosa che mi piace tantissimo, magari poi dopo ne parliamo ancora se siete interessati.E poi ha già anche un language server, quindi il language server viene già con il linguaggio e questa è una cosa fantastica secondo me.Sicuramente è la parte ancora più acerba, possiamo dire, cioè LIM ormai è già pronto per ambienti di produzione da diverso tempo.Il language server è fantastico per essere un linguaggio versione 1.0, nel senso che ci sono molti linguaggi che magari non language server che ancora non è neanche come questo e sono a release ben superiori a 1.0.Migliora continuamente ma sicuramente è il punto che ancora ha bisogno di più amore da parte del core team e dello sviluppo.Diciamo che fino alla versione 1.0 il focus era quello di fare tutti i breaking change possibili prima di arrivare all'1.0 e poi dopo iniziare a lavorare con maggior attenzione sul tooling.Posso dire che già nella versione 1.1 che è stata rilasciata da pochissimo è migliorato tantissimo, è impressionante vedere quanto si è migliorato già nel corso di un solo mese in cui poi ci si è concentrati effettivamente su quello e quindi il language server aiuta tantissimo da quel punto di vista.E poi è il compilatore che fa tutto il lavoro sporco diciamo perché è molto attento per esempio anche con i messaggi d'errore a indicare puntualmente quali sono i pezzi di codice problematici e a spiegare perché lo sono.E anche lì secondo me è una cosa molto bella di Gleam, chiaramente Rust e Elm da quel punto han fatto scuola sui messaggi d'errore e i messaggi d'errore sono molto belli, sono molto d'aiuto.Cerchiamo sempre di migliorarli.Io proprio oggi pomeriggio stavo lavorando a migliorare alcuni messaggi d'errore, introdurre nuovi messaggi d'errore più specifici che guidano proprio il programmatore nella strada per fixare il problema, non solo dire "guarda qui c'è un problema, fancavoli poi".[MAD] Guarda hai catturato subito la mia attenzione.A questo punto mi chiedo, io non so se hai lavorato nella parte core dell'error detecting, ma come funziona un sistema di quel tipo? È complicatissimo! No oddio allora, in realtà scherzi a parte, lavorare al compilatore di Gleam è veramente un piacere.È scritto in Rust il compilatore, Io non conoscevo niente di Rust a parte l'Hello World e avevo provato a fare i primi due esercizi di Rustling, la cosa interattiva, tipo con esercizi interattivi, ma essenzialmente la mia conoscenza era pari a zero.E infatti ero un po' spaventato all'inizio quando ho detto "dai, vorrei provare a risolvere questa issue del compilatore, andiamo a mettere mano, a brigare un po', vediamo cosa succede".E invece è proprio scritto veramente molto bene.è facilissimo metterci mano, andare a spaciugare nel codice, tra virgolette, spostare, vedere cosa succede, capire da dove viene qualcosa.Chiaramente ci sono dei punti che sono molto più complicati.Ci sono altri punti invece, per esempio, tutto quello di appunto analisi dei tipi del codice, dove è facile vedere quali sono gli errori, aggiungerne di nuovi e così via.E quindi io per esempio, quando è stato tre, quattro mesi fa, avevo bisogno aggiungere un nuovo tipo di errore perché secondo me non era molto molto chiaro il messaggio che veniva dato e quindi sono andato a vedere più o meno visto che l'errore era nelle liste c'è un modulo dove viene fatta l'inferenza di tipi vai a vedere infer il tipo della lista spulci dentro il metodo quello che c'è alla fine riesci a trovare bene o male raccapezzati nel codice chiaramente non è semplice subito all'inizio però diciamo che la mia tesi è che sia molto facile poi per un programmatore una volta che ha più o meno un'idea di dove andare a cercare, mettere mano e modificarlo.Infatti ogni tanto faccio degli stream su Twitch o su Discord, così quando capita, dove lavoro al compilatore per far vedere che effettivamente è una cosa alla portata di tutti, non è una cosa per solo gli iniziati che conoscono qualche segreto magico e così via.Cioè tutti possono farlo.Se ci sono riuscito io sicuramente ci riuscirà tantissima altra gente, io non ho assolutamente nulla di speciale da questo punto di vista.Questa cosa qui mi incuriosisce tanto, cioè se io domani, io Carmine, vorresti iniziare a contribuire al compiler di JGLim, c'è una documentazione, ci sono degli ADR, c'è un post-it, un gist, qualunque cosa insomma che mi dica più o meno come funziona e dove mettere le mani.O comunque è sempre, diciamo, una scoperta personale più rompere le scatole a chi c'è su Discord, insomma.[MADFISH] Allora direi che forse è più la seconda, nel senso che qualcosa c'è, ma diciamo non c'è un documento che ti dice "devi andare qui se hai bisogno di questo, devi andare qui se hai bisogno di questo".Io personalmente adesso, ogni volta che lavoro il compilatore aggiungo tantissimi commenti quando posso in modo che il prossimo poveretto che dopo di me dovrà andare lì non rimarrà un po' stupito dal mio codice, ma c'è un'idea di quello che sta succedendo e del perché.A quello io ci tengo molto, quindi provo sempre a lasciare pulito o meglio ancora di come l'ho trovato e quindi metto sempre commenti, provo ad essere bravo da quel punto di vista e così via.L'esperienza è che ho sentito dire anche altri ragazzi che per loro per esempio è stato molto facile iniziare.Poi chiaramente all'inizio c'è un po' da sbattere la testa perché come dicevi magari devi andare a chiedere "guarda ho bisogno di far questa cosa dov'è che devo andare a mettere mano" però non è una code base così gigante da non riuscire per esempio a, andando a spulciare in giro, trovare il punto che ti serve andare a modificare.Chiaro, oggi dovendo elencare quelle che sono gli elementi che ti sono stati utili nell'orientarti in quella Codebase, anche a livello di conoscenze, quindi di knowledge.È bellissimo quello che hai detto, io ero il ragazzo delle monadi.Ecco, cosa ti sei portato appresso di tutta la conoscenza pregressa nell'esplorazione la contribuzione poi all'interno della codebase di Grim? Allora ti devo dire è molto difficile rispondere perché dovrei capire un attimo, è sempre difficile un po' capire quali parti delle cose che mi sono effettivamente servite finché uno non ci fa caso.Sicuramente diciamo un po' per poter lavorare in Rust l'idea lì è, chiaramente non ho programmazione oggetti, quindi ero già più o meno abituato a ragionare in maniera diversa, con un linguaggio funzionale, la codebase in Rust è molto approcciabile conoscendo più o meno qualcuno di questi argomenti, ma anche proprio di base, quindi enum, struct, metodi, cioè funzioni e così via.Alla fine bene o male quello è tutto quello che serve.Poi la codebase è scritta, o almeno per le parti poi che ho toccato io personalmente, in un Rust molto semplice, fra virgolette, nel senso che non usa tantissimo feature più avanzate come trait e così via, quindi non c'è neanche da dire che mi è servito conoscere le type class di Haskell o così via, perché alla fine quando vai a programmare lì bene o male sono tutte funzioni concrete e così via, e non c'è bisogno di questa conoscenza diciamo dei massimi sistemi, trait e così via, questo semplifica tantissimo andare poi a programmare nella Codebase, quello di sicuro.E poi dopo c'è tanta voglia di imparare appunto, sbattere la testa, la capabilità di dire "oddio adesso voglio capire cosa fa a questo punto di codice", però lì diciamo che è un po' la motivazione personale, non tanto le conoscenze che avevo già da prima, ecco.A livello di compilatore, immagino che il compilatore non faccia altro che trasformare il tuo codice Gleam in un Abstract Syntax Tree e da là cercare errori e trasformarlo poi in linguaggi sottostanti, un po' come fa il traspilatore TypeScript, ho compreso bene? Sì, sì sì.Ok, a questo punto mi chiedo...no, questa era una conferma.A questo punto mi chiedo, Gleam è general purpose o ha degli ambiti specifici? Cioè qual è la destinazione di utilizzo? Perché io ho visto uno sponsor e mi son fatto un'idea, però non vorrei che l'idea fosse sbagliata.Sì, allora Gleam si è general purpose, nel senso che qualunque cosa ti possa venire in mente di fare puoi farcela.Chiaramente poi può avere punti di forza o meno, probabilmente non proverei a farci, che ne so, sviluppo di video o già qualche cosa simile, ad altissime prestazioni, ma io personalmente ho rintezzato i linguaggi che utilizzavo sempre con Gleam.Una cosa dove va molto forte è per esempio nello sviluppo web, quindi per esempio sviluppo di server web, c'è un framework Wisp che secondo me è fatto molto bene, ha anche tanti esempi di codice, quindi da quel punto di vista è fantastico.E poi soprattutto quello che mi piace che è proprio, secondo me, veramente fantastico per scrivere la logica applicativa, la logica di business.Cioè io devo risolvere il mio problema devo modellare il dominio del chi ne so e mi dà tutti gli strumenti per poter parlare del mondo che mi circonda in maniera chiara, pulita, senza perdermi in mille feature che mi distraggono e quindi da quel punto di vista secondo me è proprio uno strumento fantastico.E poi dopo c'è tutta la parte di sviluppo front-end, non posso non non menzionarla perché c'è un framework secondo me veramente incredibile che si chiama Luster, che è un framework per lo sviluppo web front-end che riprende la Elm Architecture essenzialmente.E quindi appunto porta poi Glim sul front-end.Secondo me è veramente un'esperienza molto piacevole di sviluppo.Mi piace molto come architettura, aggiunge qualcosa in più rispetto ad Elm e secondo me ha fatto molto bene.Poi io sono di parte chiaramente perché io poi dopo ho aiutato anche lì, quindi dopo a me piacciono molto mi affeziona.No volevo chiederti hai detto che è molto espressivo in un contesto dove si deve esprimere del domain code no? E mi chiedevo che cosa gli dà questa espressività comparato a un typescript della situazione.Allora sicuramente sono diciamo il punto chiave sono quelli che si chiamano tipi di dato algebrici o record o variants, potrebbero avere mille altri nomi, io di solito li ho sempre sentiti nominati come tipi di dati algebrici o custom types, che ti permettono essenzialmente di definire con una sintesi molto leggera dei tipi che hanno delle possibili varianti, quindi un po' come le struct e enum in Rust essenzialmente.E quindi non c'è tutto quel...diciamo io, per esempio, adesso parte il momento amarcord, quando ho iniziato l'università a programmare il primo linguaggio che ho imparato è stato C in università, poi dopo ho imparato Java nel corso di programmazione oggetti, mi sono innamorato tantissimo di Java, nel senso che queste astrazioni di classi...- Hai detto Java e è partito subito anche il Bob! - Mi piaceva molto proprio perché le astrazioni di classi, interfacce e così via, ti permettono di parlare del mondo che ti circonda in una maniera più facile da capire, da leggere il codice e così via.Diciamo che la luna di miele con Java ormai è passata più o meno, maturando e così via.Però diciamo che l'idea rimane sempre quella, nel senso che posso parlare del mondo che mi circonda in maniera molto facile e quindi aggiungere nuovi concetti, nuovi tipi.Non è un, diciamo, macchinoso come in Java dove devo creare un nuovo file, aggiungere una classe, puoi soprattutto pensare a quel punto.Metto una classe, metto un'interfaccia, metto una classe stratta, un'interfaccia, una factory, inizia a essere faticoso, c'è questa paralisi d'analisi perché appunto ho tantissime feature, tantissime cose che un po' mi bloccano, cioè mi rendono più lento nella mia capacità di rapidamente scrivere codice e così via.Quindi da quel punto di vista secondo me aiuta tanto.Poi hai parlato di TypeScript.Personalmente non sono un grande fan di TypeScript, purtroppo è un linguaggio che per me non ha mai avuto quel click, quello scatto che invece tantissimi poi dopo amano TypeScript un po' perché abbiamo proprio due type system completamente diversi.Mentre Gleam, dal punto di vista del type system, è un linguaggio molto semplice, cioè è un type system di Hindley Milner, quindi inferenza di tipi decidibile, molto classico, diciamo, fra virgolette.Noi diciamo sempre "state of the art", ma degli anni '70, nel senso che ormai è qualcosa di consolidato, tantissimi linguaggi hanno questo genere di type system.TypeScript invece proprio va in una direzione completamente diversa, un po' intanto perché ha tipi strutturali, quindi vuole chiaramente essere un livello tipato sopra JavaScript e quindi deve poter parlare di oggetti e così via, e soprattutto ha tantissime feature molto più complesse a livello di type system con il quale si possono fare delle magie incredibili, ma la cosa che a me non piace della magia è che è bellissimo scriverla, ti fa sentire potentissimo, ma quando poi mi arriva il messaggio d'errore o devo provare a scrivere codice, capire cosa sta facendo, diventa difficilissimo.È l'unico linguaggio nel quale mi sono sentito che dovevo debuggare i tipi oltre che i valori concreti e quindi per me non è mai stata un'esperienza così piacevole.Io testo i tipi in TypeScript.Io in TypeScript testo i tipi.Sì, secondo me, diciamo, forse è andare troppo.È bellissimo da scrivere molto interessante, ti spacca un po' il cervello, però poi all'atto pratico non mi piace così tanto dover leggere e mantenere il codice perché a quel punto non solo mi devo preoccupare dei miei algoritmi, dei miei valori, ma mi devo preoccupare anche dei tipi e quindi diventa un po' un macello.Almeno questo è stato nella mia esperienza, poi chiaramente altri potranno dire cose completamente diverse.No, sono d'accordo in TypeScript, da amante di TypeScript, lo dico senza remore, uno dei problemi di TypeScript è capire cosa succede quando appena ti spingi un po' oltre i tipi, nel senso che i tipi di TypeScript hanno una complessità importante, specie se tu li utilizzi a pieno e ne utilizzi le funzioni nate per mettere una pezza dove i tipi non c'erano erano scritti col culo perché fondamentalmente il problema di TypeScript stranamente appare quando ti devi interfacciare con librerie di terza parte o quando devi tipizzare una libreria che deve essere utilizzata da altri, che entri nel mondo dei generici e poi inizi a derivare tipi, a fare cose strane e poi dopo due giorni non ci capisci più niente.E quindi proprio oggi mi dicevo, mentre debagavo i tipi di un plugin di Fastify, mi dicevo "ma cacchio, si potrebbe avere un sistema di messaggi d'errore per TypeScript sui tipi un po' meno criptico e che non sia tipo 70.000 righe post compressione?" >> GIOVANNI: Sì, mi ricordo che c'era in Plamina addirittura di Discord che tipo modificava il messaggio dell'errore facciamo un po' di taglia e cucci per farlo più comprensibile.Ma non funziona uguale, quindi devi andare sul tf.config, perché spesso le parti interessanti sono anche tagliate, quindi devi andare sul tf.config e devi dire "espandi il messaggio d'errore" e diventa una cosa gigante.Io alla fine, credetemi, oggi, mi faccio ridere, una struttura di tipi veramente complessa, vi dico solo che i tipi sono derivati da un JSON schema di 4000 righe.Quindi questo è il contesto.Sembra doloroso effettivamente.No vi farò ridere, ho installato un plugin per Visual Studio Code che si chiama TypeScripting in Type Inspector o qualcosa del genere, che tu clicchi sulla variabile o sul tipo e lui ti espande tipo una folder tree, un folder tree è la roba dei tipi, tra l'altro derivandoli dal language server, io sono andato e ho fatto lo screenshot del pezzettino che mi interessava, poi ho aperto un altro tipo, ho fatto lo screenshot dell'altro pezzettino, me li sono messi uno fianco all'altro nel monitor e ho detto "ma porca puttana siamo nel 2024 e io devo fare questa cosa per capire che qua c'è un nulla bolle e qua no".Allora guarda questa cosa mi fa sempre impazzire quando ci sono quei linguaggi che dicono "e è la mia più grande paura quando arriveranno i tipi in l'Xeer, insomma, che è tutto graduale il typing, ma non lo è, cioè nel senso lo metti in un posto, poi è così graduale che smette di esserlo appena cominci.Quindi nel senso quella è una cosa che mi fa impazzire.In l'Xeer non c'è questo problema perché non ci sono, c'è, ci sono le typespatch che che sostanzialmente annoti le firme delle funzioni delle strutture dati con una sorta di tipo che però viene controllato da un altro tool.E oggi ho avuto un problema simile con Dialyzer che è il tool che controlla le typespaces XIR e Derlang e sono impazzito, insomma, ho trovato questo bug su questa issue su eric silfoni, diciamo no no no, disabilita tutto, e infatti così ho fatto.Quindi ecco, diciamo io preferisco sempre le cose diciamo che sono chiare fino all'inizio, o meglio, se un linguaggio è tipizzato deve essere tipizzato, se non è tipizzato non attivizzato.Tutto ciò che è graduale nella mia nella mia esperienza va sempre un po' a degradare quella quella che è le esperienze utente.Prima che uscisse TypeScript io ho scritto del già scritto forse se si ricorda sicuramente Mauro ho scritto dei componenti React con Flow.Non so se ci si ricorda Flow.Che era una roba abberrante cioè nel senso il commento che però diventa tipo, che però viene compiato, una roba veramente brutta.E io ho sempre quella cosa lì in mente.Quando scrivo TypeScript, naturalmente quando scrivo back-ending, front-ending in TypeScript, non ne faccio, c'ho veramente rinunciato.Anche...Spesso con React.Spesso, specialmente con React.noi nella nostra applicazione React in Trento, per il front-end, che è bello, Reactive, tutto super complesso, abbiamo deciso di non mettere, di non mettere live script, altrimenti si sente in un giro di schiaffi da cui non se ne esce.Nonostante magari anche il team sia preparato, sia strict, importi quella libreria maledetta, o magari il tipo di quella libreria maledetta non è aggiornato, e ti si smicchia tutto.Quindi, nel senso, sul front-end ce l'ho rinunciato, cioè nel senso abbiamo una suite di test sul front-end che è spaventosa e non abbiamo mai sentito la necessità di metterci TypeScript.Sul back-end a me piace molto TypeScript, però anche lì sono molto forzato, cioè nel senso quando devo scegliere una libreria e so che sto utilizzando TypeScript, vado prima a vedere come sono fatti i tipi.Perché se magari la libreria mi serve, ma i tipi sono fatti col cuore, dicono "vabbè non fa niente, faccia a mano".Nel senso spesso è più la cosa insomma di fare, di aggiustare il tipo che questa cosa qui.Ti faccio una domanda, ma quindi dentro Glim la metaprogrammazione non c'è? No.Ok, beh.Ok, beh.Forse a un programmatore Xeer è una cosa che non piacerà per niente, immagino.No no, allora, guarda, in realtà nell'Xeer e Derlang c'è questa regola, non scritta in realtà, non scritta più di tanto, che se stai facendo della meta programmazione, stai facendo una macro, probabilmente del 90% dei casi stai facendo un accrocchio, quindi c'è il modo migliore di farlo.Però ovviamente ci sono quelle cose in cui ti serve utilizzare una macro e scrivere macro.Io ho scritto tante macro in Elixir, pochissime macro in Rust e sono molto contento di aver scritto pochissime macro, perché non ce ne avevo nessuno.Però è così.Il fatto che il linguaggio non abbia questo flavor di metaprogrammazione mi piace perché lo rende molto molto più fruibile secondo me.Cioè nel senso il fatto che sia tutto molto più stricto a me piace.Poi...Riduci gli "unknown unknowns", no? Sì, sì.Io ho scritto delle cose in ruby che sono bruttissime, con i metodi creati al runtime a partire da un file di testo fatto da robe veramente brutte che tu c'hai l'errore e lo cerchi nel codice, il nome del metodo, ma non lo trovi.Carmine, io ho scritto business logic usando le reflection di PHP, quindi...Eh, capito.Cosa c'è peggio di questo? Non ci può essere.Però vedi, anche quello è un tool, cioè diciamo se vogliamo restare sulla cosa di ciò che non c'è non si rompe, ok? Secondo Teglim può avere un'attrattiva anche per questa sua, diciamo, semplicità.E non voglio paragonarlo a Go, perché è vero quello che si dice di Go, che è semplice, impari il linguaggio in un giorno, Go è pieno di pitfalls, è pieno di quirks impressionanti.Secondo te Glim può, diciamo, è attrattivo anche per questo motivo qui? Cioè, ritornando allo sponsor di prima, quindi Fly è sponsor di Glim perché lo usa o perché gli piace? [LM:] questo è l'ora.Parto dall'ultimo pezzo.[M.M.]: hai fatto la domanda che io non riesco a fare.[LM:] "Clarke è sponsor di Gleam?" Sì, sponsorizzano su Github.Se non ricordo male, la storia è molto divertente perché c'era classica discussione su Twitter, thread acceso dove si parlava se avesse senso mettere le sponsorizzazioni su Github oppure no, e se non ricordo male c'era uno che diceva "no, bisogna invece sempre mettere anche una tier altissima nelle sponsorizzazioni" uno di Fly appunto, nelle sponsorizzazioni perché non sia mai, magari uno capita, un'azienda capita che vuole sponsorizzare il progetto e c'è effettivamente la tier per cui quella può sponsorizzare in maniera significativa.Allora lui che era su Twitter scrive "ah guarda comunque io ho aperto le sponsorizzazioni su GitHub" e il giorno dopo si è trovata la sponsorizzazione di Fly.E quindi questa è la storia di come Fly abbia iniziato poi a sponsorizzare Glimma nella tier più alta e così via.Non so personalmente io se Fly ne faccia uso, gli piaccia, così via, non ne ho idea sinceramente, su questo non posso veramente parlare perché non lo so.E invece l'altra domanda è appunto l'attrattiva della semplicità al paragone con Go.In realtà il paragone con Go, diciamo, è molto… ci sta molto da questo punto di vista.Go è stato proprio uno dei… è uno dei paragoni fatti più spesso.Allora la gente dice a volte tipo "Go se fosse funzionale" o cose del genere e ci sta perché appunto sono entrambi molto semplici e secondo me è proprio una grande attrattiva, almeno personalmente, che poi io appunto lo dico da fan di Haskell dove puoi fare follie totali, invece apprezzo tantissimo un linguaggio proprio così semplice perché leggo il codice e so quello che sta succedendo.Cioè non c'è meccanismi magici, cose magiche per cui faccio fatica a seguire quello che leggo e secondo me è un grande punto di forza.E soprattutto diventa un punto di forza anche poi per tutto il mondo del tooling attorno.Quindi un esempio, parlavamo prima dei messaggi d'errore di TypeScript complicatissimi.Sono complicatissimi anche perché TypeScript è un linguaggio che ha delle feature potentissime a livello di tipi.E quindi chiaramente più si complica più diventa difficile anche dare dei messaggi d'errore che siano sempre buoni, d'aiuto per il programmatore e così via.Mantenendo il linguaggio semplice invece il nostro lavoro si semplifica tantissimo, nel senso che anche lì dare dei messaggi d'errore semplici da capire, diciamo che vanno dritti al punto perché capisce esattamente cosa c'è che non va nel codice, è molto più facile.Quindi secondo me questo è proprio un grande punto di forza.Ci sono molti per esempio che dicevano nel Discord di Glim, "ah sì, ho iniziato a programmare in TypeScript come se fosse Glim, quindi ho smesso di usare qualunque feature avanzata del Type System" così via.Alla fine è una sorta di Glim sotto mentite sfoglie, nel senso che comunque è una cosa che piace la semplicità e secondo me rende scrivere il codice molto più facile.Magari non avremo quel senso di onnipotenza che ci viene quando usiamo feature assurde, canoni e così via, però secondo me l'esperienza proprio del programmatore è molto più piacevole.È divertente perché io l'esperienza appunto dell'onipotenza e poi del non capirci un cazzo di quello che ho scritto ce l'ho avuta con la programmazione funzionale, no? Nel senso che che ho scritto una roba simpaticissima che era lo scrittore dei capitoli del podcast usando...come si chiamava? Boh, non mi ricordo.Comunque usando la programmazione funzionale, quindi mille cose, e alla fine dopo...adesso sono tre anni se io ci metto mano oggi ci capiscono a cipa.E quindi anche il poter usare, approcciare la programmazione funzionale prendendo quei quattro concetti che ti servono e nulla di più è molto figo che poi è un po' come utilizzo io TypeScript per scrivere la business logic.C'è stato un libro bellissimo, io vi ho martellato le balle a livello inverosimile qua nel podcast, che è Functional Driven Design di Slack.Bellissimo, sì.Non saprei programmarlo.Sì, esatto, è là di complessità della programmazione funzionale, c'è veramente niente, veramente poco, cioè function composition è poco altro eppure quel ritorno al minimalismo l'ho visto molto collegato a quello al posto di usare cose complicate o perdersi nei meandri dell'algebra di non so che cosa.Lo so che detto a un amante della programmazione funzionale non è bellissimo, No, no, è proprio una consapevolezza che ho maturato nel corso del tempo perché chiaramente è sempre divertente magari provare a fare la cosa strana e così via, però anche io ho tipo dei pezzetti, dei cosi in codice Haskell che vado a rileggere e dico "ma io come cavolo ho fatto a concepire questa mostruosità che adesso non so neanche più che cosa faccia, come cosarlo".Un po' perché ci si lascia prendere la mano da tutti quegli operatori quindi il codice diventa veramente illegibile.Invece l'esempio di Functional Domain Driven secondo me è bellissimo perché lì fa proprio vedere...cioè non c'è niente che ti dice "deve essere complicato", può essere tutto semplicissimo funzionale e è molto più semplice di quello che uno potrebbe aspettarsi perché magari è spaventato da una sintassi che non è proprio familiare perché magari siamo abituati a una sintassi stile Java o stile Rust e così via con le graffe e invece lì F# e compagnia usano una sintassi diversa e quindi può essere un po' spaventoso all'inizio.ma poi capisci che effettivamente una volta eliminato questo primo scoglio, diciamo, non c'è niente di intrinsecamente complicato, cioè siamo noi che ce lo rendiamo complicato per masochismo.Però vi chiedo, sai, mi è capitato di lavorare in ambito performance, no? E mi è capitato di lavorare in ambito performance in JavaScript.Anirform capita che prendiamo insomma, fixiamo delle robe a librerie particolari, nel mio caso per esempio erano delle cose su Mercurius che è il server GraphQL che sta, che funziona e gira su Fastify e quindi un server GraphQL non è logica di dominio, è uno, uno, un server che deve essere performante io mi sono reso conto che quando tu vai a scrivere con la performance in mind spesso esci fuori con della roba aberrante è decisamente poco poco leggibile mi chiedo se avendo lo stesso approccio su linguaggi dallo scopo volutamente ilimitato come Glimm si vive la stessa esperienza, nel senso si arriva, si rischia di arrivare a mettere della complessità che non è data dal linguaggio ma da come compone i blocchetti, oppure l'avere un toolset, una casetta di attrezzi di linguaggio stesso così limitata, un po' questa complessità la lima.Non ti so rispondere in realtà perché non mi è mai capitato di dover proprio limare fino all'ultimo millisecondo di performance e quindi non mi è mai successo di dover fare per esempio degli accrocchi perché l'algoritmo che utilizzavo non era abbastanza performante.C'è da dire che non ho mai scritto server, cioè proprio il server in sé io ho sempre usato il framework che ne fa uso, il server è molto performante, però non sono mai andato a sbirciare nella codebase a vedere quello che fa, quindi non ti saprei dire in realtà cosa fa sotto per essere così efficiente e se questo va a diminuire poi la leggibilità del codice.Probabilmente sicuramente uno alla fine potrebbe doversi trovare a fare cose che, quando non si preoccupa di prestazioni, chiaramente rendono il codice un po' meno bello, un po' meno leggibile, però non ti so dire veramente.Chiaro, chiaro, era solo una sega mentale la mia, non ti preoccupare.Chiedo a Carmine se ha qualche domanda.Sì, ho una domanda, in realtà ce l'ho per tutti.Io io do la mia risposta alla film, cioè questa cosa che fa molto talk show su Rete4.Allora, se voi aveste un'azienda, ok, diciamo in questo momento storico, valutereste Gleam come linguaggio per sviluppare i vostri prodotti oppure no? Cioè io spesso faccio questa domanda quando mi trovo a parlare con alcuni colleghi.In SUSE abbiamo una varietà di stack che fa impressione.Quindi ognuno dice "ah, io lo faccio in Rust perché Rust è meglio", "io lo faccio in XSERY perché XSERY è meglio", "io lo faccio in C perché è l'unico linguaggio di pro-ingrammazione possibile".questa cosa.HR è seduto a partenare in bagno che piange.Io lo faccio in Perl perché è l'unico linguaggio di programmazione possibile.Insomma, ognuno ha la sua opinione su questa cosa, ma quando chiedo "sì, ma se l'azienda fosse tua e tu devi fare questa cosa per il cliente", ragazzi le risposte che ottengo sono sempre le stesse.C'è chi dice "PHP", PHP, se si tratta proprio di roba sfacciatamente web, c'è chi dice Java, c'è chi dice Python, ma sono molto pochi quelli che dicono cose diverse.Cioè, voi che fareste e che linguaggio usereste? È un po' una domanda che va così.Dalla mia limitatissima esperienza di...intanto questo scenario ipotetico, il passo che mi ha permesso di arrivare ad avere una mia azienda deve essere messo in galera perché io non devo avere questo potere a portata di mano.Detto questo sì, io lo considero al 100%, però di nuovo io sono di parte, quindi da quel punto di vista non dovete fidarvi di quello che dico io.Diciamo che se il mio problema fosse "adesso ho bisogno di un workforce di X programmatori che conoscano Gleam", probabilmente potrebbe essere un po' più difficile riuscire a reperirli se non altro qui in Italia, però ci sono io.Però io conosco tante persone, per esempio su Discord, che sarebbero contentissime di lavorare in Gleam.E utilizzare una tecnologia che magari non è mainstream, ma per cui vai a cercarti le persone che lo conoscono, di solito attiri veramente gente fantastica, nel senso che è lì perché gli piace proprio la tecnologia, sono venduti su quella tecnologia, la utilizzeranno, sono già on board, non devi convincerli e avrai un team molto affiatato.E io, conoscendo molte persone su Discord della community di Glimp, sarei contentissimo di lavorare con loro.Cioè, se avessi un'azienda andrei lì, li assumerei tutti quanti, proprio sarei felicissimo di questa cosa.quindi sì, considererei sicuramente Gingo.Io sono stato imprenditore e quindi questa decisione l'ho presa a suo tempo e optai per PHP, che nonostante tutto mi riempì il frigo.Oggi farei un ragionamento differente.intanto fare un'analisi sulla portata del progetto/prodotto e sulle risorse a disposizione.Se io fossi SUSE o fosse un'azienda di quelle dimensioni non mi metterei problemi, lo farei anche in qualunque tipo, qualunque linguaggio volete, in D, non so se vi ricordate.L'importante è che ci sia coesione del team e quando sei così grande le risorse le trovi, in un modo lo trovi, specie se sei attrattivo, anche perché hai la possibilità di attrarre dei senior o upper levels e convertirli rapidamente.Quindi se fossi di quel tier sì.Io però sono stato imprenditore di una piccola azienda e in quel caso si aprono due branch.Hai tirato la pietra adesso devi sorbire il pipone Carmen.Si aprono due branch.Il primo è un prodotto da vendere e là c'è poco da discutere, nel senso io sono un agency, devo fare qualcosa per un cliente e gli devo vendere il lavoro che produco o il software o il coso e alla fine opterei per i linguaggi mainstream, perché sono quelli che lato commerciale, in fase di vendita col cliente, mi permettono di dirgli "tieni questa roba sappi che te la puoi gestire anche da solo" e questo potertela gestire da solo ha un valore di tipo commerciale.Vuol dire che mi paghi x mila euro in più perché c'hai anche quella libertà.Non paraculo però questo, quello è un peso.Se stessi sviluppando il mio prodotto e avessi una visione di medio-lungo termine, intanto non non userei un linguaggio FFF farei all in, ma diversificherei e farei dei pezzi ognuno dei quali con delle specifiche diverse andare a cercare il linguaggio che più fitta a quel pezzo specifico.Però ecco, se volessi optare per la semplicità e quindi se la mia scelta fosse la semplicità e mi dovessi trovare davanti a una scelta avrei probabilmente due soluzioni e volessi un linguaggio di un certo tipo tipato mi verrebbe da dire che non escluderei Glimm magari non lo sceglierei come prima scelta perché non lo so c'è Go e a me Go fa vomitare però ha un valore di mercato differente, fare recruiting è più facile, Rust non lo userei manco morto e io l'adoro e lo sto usando però l'azienda è la mia e non lo userei almeno se l'azienda è piccola Glimm non lo escluderei perché? Sta là la domanda.Perché in realtà io non ho dimenticato quello che mi ha detto ha detto Giacomo all'inizio dell'episodio.Giacomo ha detto "il codice quando io traspilo in Erlang, il codice che ne viene fuori spesso, dimmi se ho capito male, è quasi più bello di come lo scriverei io".Io un programmatore Erlang che sono scarcissimo, poi magari un programmatore Erlang lo vede e potrebbe migliorarlo, però sì, non è il classico compilato minificato, illeggibile.Ecco, quello di sicuro.Ecco, partiamo da questo principio.Se quello che ha appena detto è vero, probabilmente non è la way to go, ma potrebbe essere la soluzione in un contesto dove metti l'interesse di Glim Kala e l'impegno del core maintainer per andare su Erlang e comunque continuare ad utilizzare una codebase che ormai è già là, magari definendo dei tratti ben chiari di contorno.Quello che però in realtà mi limiterebbe, ed ecco perché ho detto non lo escluderei ma probabilmente non sarebbe una mia prima scelta, è che per questioni personali io non mi fido mai delle cose fatte con un benevolo dittatore, non so come si dica, suona malissimo in italiano, un re benevolo che sta sopra, perché per quanto lui lo faccia in buona fede e per quanto ci metta davvero tutta la passione e tutto l'impegno affidare la mia azienda, quindi qualcosa di mio, che ha un valore importante per me, a le decisioni di un'unica persona, tagliando me fuori dal controllo e affidando tutte le decisioni che non hanno una pluralità democratica, potrebbe essere l'elemento che un po' mi allontana, quindi sì valuterei la scelta, però nel tavolo ci metterei anche questa carta.Lo so, vi ho fatto un pippone e Carmine mi ha provocato, scusatemi.Carmine, hai qualche altra domanda per la quale io potrei parlare altri 25 minuti? Sì, sì, ma non la faccio, non ti preoccupare.Guarda, come ultima domanda che mi viene in mente.Ah, tocca a te tra l'altro, tu non l'hai detto.Ah, è vero.Ti stavi nascondendo.No no, perfetto.Io che cosa userei? Se avessi la piccola… Allora, se dovessi fare un prodotto mio e il team è piccolo ed è un prodotto sostanzialmente web, ok, userei probabilmente… sta entrando in diacaca mode, sta entrando in diacaca mode.Userei RubioRace per una serie di motivi che su questo podcast ho detto un po' troppe volte perché è semplice, perché è conciso, perché funziona, perché ha una...Ora, tracciando stare gli stakeholders di RubioRace, non sono nemmeno io tantissimo fan di diacaca, anzi, però ecco, è una cosa che non me lo farebbe escludere.Anzi, userei Ruby o Rails o l'equivalente di Ruby o Rails in qualunque altro linguaggio, quindi che possa essere Laravel, che possa essere Django, insomma, una cosa del genere.Non userei ad esempio Elixir Phoenix per un fatto di workforce, per un fatto proprio di costo della workforce, non lo farei in Java per il motivo opposto, cioè nel senso perché c'è tanta workforce che probabilmente non è del livello che io voglio.Quindi sì, insomma, mi sarei su qualche cosa che sia mainstream, comunque abbastanza insomma di micchia se fossi un azienda grande non mi porrei nemmeno io nessun problema insomma diciamo userei qualcosa che ha un ampio...Java 8! Sì infatti! Azienda grande, appalto pubblico, Java 11 e siamo lì proprio, mi sto...Life Ray, Java 11, Hibernate, basta, finito.Se invece...però ecco, allora, quella cosa, sceglierei qualche cosa che ha un ampio tooling per supportare lo sviluppatore nel suo insomma lavoro.Quindi qualche cosa che abbia un tooling che possa assistere lo sviluppatore il più possibile.Quindi con un language server buono, eccetera, eccetera.Le performance, a meno che non devo fare effettivamente una roba molto performance oriented, sarebbero l'ultima cosa di cui mi preoccuperei, insomma, da quel punto di vista lì.Alla fine siamo in un mondo dove è tutto veloce, ma siamo anche disposti ad accettare dei tempi un po' più lunghi se qualcosa ci piace, insomma.diciamo così.Se qualcuno mi vuole finanziare, ho due o tre idee che si possono fare.Facciamo questa "call for founding", diciamo così.No, è bellissimo quando hai detto "stiamo sempre cercando di andare veloci, però poi alla fine sia una cosa di figa.Se ci interessa abbiamo anche la pazienza di aspettare.Nel sito di Gitbar metteremo proprio un banner dicendo "se questo sito sta prendendo troppo tempo a scaricare alzati dalla sedia e guarda fuori".Allora guarda, nel senso, TikTok è veloce, ci piace, è addictive, siamo comunque abituati ha quell'interazione che è veramente veloce.Ma quando devo prenotare un albergo con booking? Booking non è veloce, ma ce l'ho prenoto lo stesso perché so il valore di quella cosa.Cioè nel senso io non mi sono mai sognato di dire "ah l'applicazione di booking non è veloce come quella di TikTok".È vero sto paragonando mele con pere però.No tra l'altro nessuno si è lamentato che l'aggregatore che ti trova il volo al minor costo ci mette anche quattro minuti a dare una risposta.Assolutamente, io ho provatato più volte su Expedia ma tu dici Expedia cominciò ora tra 20 minuti forse ho trovato l'albergo.Però nel senso non è che alla fine non lo so, siamo abituati alla velocità, all'immediatezza, ma credo sia solamente una costruzione dei nostri tempi, perché poi alla fine siamo abituati ad aspettare per le cose che ci interessano davvero.Nel senso, comprate un biglietto su TicketOne, è veloce? No, per niente.Eppure ce lo compri.Non è Amazon, ma lo fai lo stesso.Bien, bien, bien.La chiacchierata è stata super interessante e adesso arriviamo nel momento "Il Paese dei Balocchi".Il momento nel quale i nostri guest e i nostri host condividono con noi un libro, un talk, un video, qualcosa che abbia catturato la loro attenzione e che reputino importante condividere con la nostra community.Per cui iniziamo subito con Giacomo, subito dopo la sigletta.Giacomo, hai qualcosa da condividere con noi? Sì, un paio di cose.Primo fra tutti, probabilmente sicuramente sarà già stato citato, se vi interessa, Glim appunto, se vi interessa la programmazione funzionale, perché magari è qualcosa che uno non ha mai approfondito oppure gli è sempre sembrato spaventoso, il modo migliore per imparare secondo me è con Exercizum.È un sito web fantastico, tutto completamente gratuito, dove praticamente uno può iniziare facendo delle piccole challenge di programmazione, imparare un linguaggio di programmazione, Exercisum ha un track di Gleam.La cosa molto bella è che ti presenta proprio un albero delle conoscenze nel quale puoi proseguire in maniera appunto graduale per imparare piano piano il linguaggio e soprattutto la cosa bella è che piano piano diventi un programmatore funzionale senza neanche accorgersene, nel senso che fai esercizietti piccolini e piccoline e poi arrivi alla fine e dici "ah cavolo", ma quindi non era così complicato.Secondo è uno strumento incredibile per imparare nuovi linguaggi di programmazione e nuovi paradigmi, quindi anche se non doveste mai finire per imparare Gleam su ExerCision, provatelo, secondo me è fantastico.Se poi ne viene fuori che qualcuno imparerà anche Gleam io ne sarei contentissimo.Un'altra cosa che secondo me è bellissima, un articolo molto bello, che racchiude un po' la filosofia di Gleam, "All you need is data and functions".È un articolo bellissimo, appunto tutto quello di cui hai bisogno sono solo dati e funzioni, racchiude un po' la filosofia del linguaggio.È molto interessante, ti apre proprio un mondo, è proprio uno di quegli articoli che lo leggi e dici "cavolo, mi ha fatto pensare in maniera diversa rispetto a come si può programmare", perché magari sono abituato in un certo modo, invece mi rendo conto che c'è un mondo completamente diverso, mi ha proprio aperto gli occhi.Questi sono due e non so, non mi viene in mente altro in realtà al momento.Io direi che vanno benissimo tra l'altro.Sono veramente curioso di leggere l'articolo perché da un paio d'anni io vivo di funzioni e di variabili.Tu dico, con la...sai, la crisi dei 40 anni, ecco.Quando io mi sono avvicinato a quell'età, ho eliminato le classi, ho eliminato le interfacce, ho eliminato tutto.Bellissimo.Adesso anche in TypeScript se devo fare qualcosa faccio "type =", "type nome =", sì.È vero, cambia la vita.Grazie Giacomo.Carmine, hai qualcosa da condividere con noi? Sì, c'ho sia il balocco sia l'anti-balocco.Allora, vado subito con l'anti-balocco.Ho comprato qualche settimana fa, perché insomma ho visto tantissimi, nonostante già avessi abbastanza prevenuto, Cracking the Coding Interview.Bellissimo libro, famosissimo.Ragazzi, non serve a niente, sono soldi buttati.Cioè sono 44, non so quanto 44, non mi ricordo con una quantità d'euro, sono soldi buttati.Cioè nel senso tu lo prendi, lo sfogli, dici "Ninchia, con questi soldi mi compravo il litcode, quello di top" tipo.Quindi se avete intenzione insomma di prepararvi per alcuni tipi di interview, io non l'ho fatto per quello, ma l'ho fatto perché pensavo che fosse, diciamo, un approccio più semplice e guidato verso alcune challenge insomma.Sono stato, per affini che è una mia cosa insomma, che sono io ad essere particolarmente tordo, io faccio tantissimi esercizi sia su litcode che su kata, insomma, eccetera eccetera, leggere quel libro per lo stesso tipo di problemi mi ha solo confuso.Ok, quindi non lo so, investite, mi sento di consigliarvi di investire sicuramente in un approccio più hands-on e un approccio che sia un po' più guidato rispetto al libro.Secondo me è bellissimo da tenere in libreria verde, però se ve lo regalano bene, altrimenti ve lo sconsiglio.Che cosa vi consiglio invece? Vi consiglio un libro che uscirà il 30 giugno 2024, che è "From Ruby to Elixir".È in preordine su Amazon, avvadendo un po' anche l'autore, l'abstract e alcune, diciamo, recensioni online di chi ha avuto modo, insomma, di partecipare alla stesura del libro e alla review.È un bellissimo libro.insomma se volete prenotatelo.È un libro della serie Pragmatic Programmers quindi è bello anche da avere fisico, è stampato bene, libro fisico è comunque un'altra cosa.Vai Mauro.Visto che stiamo andando di balocchi multipli, anche io ne ho qualcuno.Allora, il primo è "Perché appunto le cose belle si aspettano" è questo libro di Osmani.Uno degli ingegneri che stanno dietro Chrome, fondamentalmente.si chiama Success Scale e parlando ai frontender racconta alcuni casi di successo.Uno di questi è per esempio come Meta ha ottimizzato le prestazioni del feed di Instagram lato frontend.Articolo interessante ci sono tutti questi edge case spiegati con le analisi dettagliate, roba che in un articolo su Dev2 o Medium non leggete.E allora ho pensato una cosa, ho pensato che...vabbè il pippone ve lo inizio qua e lo finisco dopo.Facevo una riflessione quando Carmine parlava e diceva di rallentare.Oggi abbiamo parlato di da una parte rallentare dall'altra con Giacomo di liberarci del superfluo.È un messaggio che va oltre GLIM, va oltre qualunque tipo di linguaggio di programmazione, ma è un messaggio importante come persone, come esseri umani.E io non posso non collegarlo con l'ultimo periodo che ho vissuto.Quando in una condizione di pesantezza del genere ti liberi della zavorra e io ho cercato, ho eliminato completamente dal mio device, bloccato almeno per quel periodo, tutte le notifiche.Ho lasciato una sola applicazione con le notifiche e questa applicazione mi permetteva di leggere dei contenuti long form.Io l'ho sempre detto devo darmi a long form, devo leggere solo le robe long form, devo leggere cose che spieghino nel dettaglio la roba, però alla fine poi Instagram appariva, Telegram appariva.Allora cosa ho fatto? Il telefono ho deciso di lasciarlo lontano, ho comprato un iPad, era un paio d'anni che l'iPad non l'utilizzavo perché lo usava mia mia moglie ne ho comprato un altro, l'ho ottenuto senza queste applicazioni di messaggistica e ho installato tre applicazioni Substack, Obsidian e poi c'è l'applicazione Libri.E come mi sono iscritto sul Substack mi si è aperto un mondo.Ho letto due introduzioni di articoli e ho detto "cacchio questo è il livello dei contenuti che voglio leggere".Ho aperto il portafoglio e ho fatto "Lei sottoscrizioni a questi articoli, a queste mailing list e devo dire che i contenuti intanto sono pochi, mi sono sottoscritto a 2, 3 a pagamento perché giustamente il budget non è infinito, però già limitando così la scelta e pagare per il contenuto cambia completamente il modo in cui tu tu approccia il contenuto.Il long form te lo leggi, ti fermi, ci ragioni, io prendo dei pezzi e me li butto su Obsidian perché ci voglio riflettere di più.E questo rallentare che secondo me inizia a dare del valore.Cioè l'ho trovato come, io ve l'ho detto più di una volta qua nel podcast, ecco questa azione l'ho trovata più come un'azione pratica in quello che vi ho sempre detto.Ho avuto la percezione di predicare bene e razzolare male per un po' di tempo e con questo ho trovato il modo veramente fattivo, pratico, effettivo di fare questa cosa e non tornerei indietro.iPad o iPad mini? iPadone.Quando ti avvicini ai 40 anni, anche là, serve il peso delle cose, quando ti avvicini ai 40 anni, gli occhiali sono un po'...in realtà è stata complessa la scelta perché Luca, che conoscete, lui è un grande sostenitore di Remarkable, no? In realtà io volevo prendere Remarkable, però in realtà alla fine nessun tablet e ink, perché poi mi si è aperto il thread e ho iniziato a cercare tablet e ink perché Remarkable è molto limitato.Molte delle applicazioni che uso, tipo Obsidian, tipo questa cosa avrei dovuto fare degli acrochi con automazione, sarebbero state non funzionali perché per me leggere, se rallento la velocità, è anche prendere gli snippet dei pezzi e metterli da parte, organizzarli e ragionarci sopra quello che leggo.Perché noi leggiamo e poi perché corriamo, perché tutto va veloce, perché i siti hanno impulsanti veloci, non ci riflettiamo.Io, scusate faccio una parentesi stupidissima, alle medie, alle superiori, a casa c'è stato un periodo che non avevo internet, a scuola in classe c'era l'internet, c'era il computer, io alla ricreazione andavo nel computer, mi salvavo gli articoli sui floppy disk di programmazione, me li portavo a casa e ci perdevo pomeriggi su un articolo di una pagina.Ecco, riappropriarsi di questa cosa, quindi sì, scusate.La pastiglia.Ok, Perfetto, io direi che è stato un super episodio ma non possiamo chiudere prima di avere ingraziato chi ci sostiene, chi si fa carico di una parte dei nostri costi.In questo periodo in realtà io non ero presente ma c'è sempre chi dietro le quinte contribuisce con una donazione.La si può fare all'interno del nostro sito nell'area supporta.ci, la si può fare acquistando una maglietta nel nostro store, non mi ricordo se ho messo il link nel sito, dobbiamo metterlo, la si può fare con gli strumenti del value for value del podcasting 2.0 con un'applicazione moderna, si possono streamare Satoshi o si possono fare dei boost e la si può fare in modi diversi, io l'ho detto un po' di tempo fa in realtà in una puntata che ho registrato quasi due mesi fa, che voi avete ascoltato circa tre settimane fa, ho detto che si può contribuire in tre modi, con il Talent, Treasure o Time.Potete contribuire a Gitbar col tempo, col vostro tempo a disposizione o col vostro talento, contattatemi, c'è il sito da sistemare, un po' di cose da fare se avete il tempo libere volete contribuire il nostro repository è aperto oppure se non avete tempo e pensate valga la pena supportarci a calltreasure detto questo a questo punto noi ringraziamo chi ci sostiene Dobbiamo alzare il calice virtuale per ringraziare Alessandro Balsa che ci ha invitato alcune birra e ci ha scritto un messaggio scrivendo grazie per la conoscenza che condividete.Noi giriamo questo ringraziamento ai nostri ospiti e nel nostro caso a Giacomo perché grazie ai nostri ospiti che GITBAR è quello che riesce a dare a generare questo valore quindi grazie ancora e con le parole di Alessandro per il quale alzo il mio bicchiere virtuale faccio un cincino alla sua salute voglio ringraziare Giacomo per per esserci venuto a trovare.Cavolo, proprio adesso, in fine dell'episodio, a due ore, sto riniziando a prendere il ritmo.Cavolo, dovremmo registrarne un altro.Comunque, davvero, grazie, grazie Giacomo per esserci venuto a trovare.A voi.Grazie, grazie di cuore.Poi, naturalmente, nuovi sviluppi su Gleam, nuove informazioni.sentiti libero di pingarci perché una birra fresca virtuale, insomma, c'è sempre.Poi non che tu ne sia sguarnito perché vedo il tuo… Esatto, no ma una birra fresca c'è sempre.Non che, come dicevo, tu ne sia sguarnito perché vedo il tuo bancone bar dietro e è ben più fornito del nostro.Mega bar.Tanta invidia.Primo o poi io voglio la mia, come si chiama, stanza maschia dove mettere queste cose, il mio bar, la mia taverna, com'è che si chiama in italiano? E' uno dei miei desideri della crisi dei 40 anni.No, sai, una metafora che ci piace utilizzare è che Gitbar è un po' come il circolo del dopolavoro postale.Negli anni '70, quando si finiva il lavoro, ci si incontrava la sera con i colleghi e si continuava a chiacchierare.Spesso si trovava a casa anche abbastanza ubriachi.Ed era un circolo arci, o simili, no, quei circoli dove si entrava con la tessera che si pagava da bere abbastanza poco.Ecco, loro lo facevano per cose di natura fiscale.Noi la nostra tessera la diamo a ogni nostro ospite perché è un modo, in qualche modo figurativo, per dire che quando si entra in Gitbar un po' si diventa soci, si diventa parte della community, perché Gitbar è la community.Quindi, insomma, una volta che hai la tessera sei libero di entrare qua e è casa tua quanto nostra.Grazie ragazzi.Detto questo io vi do appuntamento alla prossima settimana.Grazie anche a Carmine con la bellissima maglietta.Mi devi dire dove la trovo perché in realtà piace tantissimo.Facciamo lo sponsor con il sponsor.Sorpresa da Prima.Ah cavolo.adesso mi faccio se ce la prendo vado apposta per la maglietta questo fine settimana lo dico a mia moglie bellissima non la utilizzerei col green screen perché qua in realtà vedresti del legno detto questo io vi ringrazio nuovamente alla prossima settimana ciao ciao ciao ciao Ciao! Dopo altro! Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.[Musica]
