Torna a tutti gli episodi
Ep.176 - Milo, un nuovo parser http per node.js con Paolo Insogna (Nearform)

Episodio 176

Ep.176 - Milo, un nuovo parser http per node.js con Paolo Insogna (Nearform)

Oggi siamo entusiasti di avere con noi Paolo Insogna, uno staff DX Engineer di NearForm, che ci guiderà attraverso un argomento affascinante: "Milo - La Riscrittura del Parser HTTP di Node.js". Node.js è uno dei framework JavaScript più utilizzati per lo sviluppo back-end, e il suo parser HTTP svolg...

2 novembre 202301:46:24
DesignAI

Guarda su YouTube

176

In Riproduzione

Ep.176 - Milo, un nuovo parser http per node.js con Paolo Insogna (Nearform)

0:000:00

Note dell'Episodio

Oggi siamo entusiasti di avere con noi Paolo Insogna, uno staff DX Engineer di NearForm, che ci guiderà attraverso un argomento affascinante: "Milo - La Riscrittura del Parser HTTP di Node.js". Node.js è uno dei framework JavaScript più utilizzati per lo sviluppo back-end, e il suo parser HTTP svolge un ruolo cruciale nell'elaborazione delle richieste e delle risposte HTTP. Paolo ci spiegherà come il progetto Milo, sviluppato da NearForm possa rendere piu' manibile parte dello stack http di nodejs.PARTITA IVA con Fiscozen: consulenza GRATIS e 50€ di sconto ⏩ https://www.fiscozen.it/invitoGITBAR50Siamo anche su youtube: https://www.youtube.com/watch?v=g6q2h8gvSVw## Il nuovo store di gitbar- https://www.spreadshirt.it/shop/design/videoterminalista+metalmeccanico+maglietta+uomo-D60dd75d8a30ff14b5e9bfbe1?sellable=5aaY1v4we3SeYEOlVXmx-6-7## Supportaci suhttps://www.gitbar.it/support## Dobbiamo ringraziare - Luca montagnoli 🍻## Paese dei balocchi- https://amzn.to/49mAjBu- https://amzn.to/46d53Cx- https://amzn.to/40jRvnl## Link amazon affiliatohttps://amzn.to/3XDznm1## Per favore ascoltaci usando una di queste app:https://podcastindex.org/apps## Contatti@brainrepo su twitter o via mail a https://gitbar.it.

Descrizione

Paolo Insogna ci racconta l'avventura di Milo, un parser HTTP scritto in Rust per sostituire quello di Node.js. Parliamo di come si affronta un linguaggio completamente nuovo per scrivere qualcosa di complesso come un parser HTTP, di macchine a stati finiti, di WebAssembly come bridge tra Rust e Node, e soprattutto di come buttarsi in progetti ambiziosi senza aver paura del giudizio. Bonus: scopriamo che Paolo è un Node Core Contributor che conosce solo lo stack HTTP e che nomina i suoi progetti come i suoi animali domestici.

Takeaway

  • Quando impari un linguaggio nuovo, usa un progetto che conosci già nel dominio: così la complessità è solo quella del linguaggio, non del problema da risolvere
  • Il bridge WebAssembly in Node.js è più leggero del bridge C++, quindi l'overhead di copia memoria viene compensato dalla maggiore velocità del bridge
  • Contribuire a progetti come Node.js porta naturalmente a una specializzazione: conosci bene una porzione della codebase e ti concentri su quella
  • Non serve essere esperti per buttarsi: Paolo ha scritto Milo senza conoscere Rust e senza aver mai scritto un parser prima

Bold Opinion

  • Se aspetti di essere esperto prima di provare, non proverai mai: meglio buttarsi e imparare strada facendo
  • Il codice è oggettivo, gli attacchi personali si rimbalzano: se qualcuno critica senza proporre alternative concrete, sparisce magicamente
  • La sindrome dell'impostore è reale anche per i contributor di progetti enormi come Node.js: non sei solo tu
  • Non serve conoscere tutta la codebase di un progetto gigante per contribuire: specializzati su una parte e diventa bravo in quella

Trascrizione

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.Ehi Mauro ferma un attimo perché prima di iniziare la puntata vi devo dire una cosa importante.Questa puntata è stata fatta in collaborazione con Fisco Zen e durante la puntata vi racconterò una cosina proprio su Fisco Zen, quindi rimanete in ascolto.Sono appena tornato da Parigi, sono stanchissimo, ancora stanco, non sono riuscito a riposarmi, è stato un viaggio allucinante.Avete visto un pezzettino nei ringraziamenti della settimana scorsa in treno? Un delirio, credetemi, un delirio totale, però finalmente sono casa sono nel mio setup sono tranquillo e quindi insomma mi trovo nella condizione di spendere due parole su quello che è stato Code Emotion.La prima cosa di cui voglio parlare è della community.Quando si parla tanto davanti a una webcam, ma tanto intendo tanto più di 170 puntate sono fiumi di parole ore ore ore spesso si idealizza l'interlocutore lo si immagina in un certo modo gli si immagina in un certo modo visto che siete tanti e li si idealizza e talvolta ci si sente anche solo io ho la fortuna di avere sempre un sacco di ospiti con me ma comunque questo tipo di solitudine c'è, rimane e quando si ha la possibilità di incontrare queste persone qualcosa succede ok è quasi una epifania qualcosa si rivela a te davanti ai tuoi occhi e rimane un po' scioccato senza capire bene quello che sta succedendo ed è un po' quello che mi è successo dopo il talk quando ho incontrato molti di voi a Code Emotion.Avere anche un solo sguardo e avervi vicino anche fisicamente è qualcosa di magico ed è qualcosa che mi spinge sempre di più verso l'idea che abbiamo bisogno di incontrarci fisicamente.Dobbiamo necessariamente trovare un momento da passare insieme probabilmente davanti a una birra reale un momento informale ma comunque un momento da condividere e quindi ci sto riflettendo tanto e questo proprio stimolato dal fatto che avervi incontrato mi ha in qualche modo colpito lo devo ammettere mi ha davvero colpito quindi vi ringrazio altra cosa che voglio aggiungere è che bom Code Motion quest'anno era un delirio fantastico io ho incontrato centinaia di persone e ho scambiato parole con una marea di gente quindi mi porto a casa veramente un bagaglio che mi fa dire ecco il motivo per cui andiamo nelle conferenze e faccio uso del tutto personale del podcast, mi porta a casa anche un grande traguardo mio personale che è stato un talk in inglese, non l'avevo mai fatto, ero cagato da morire anche perché quando tu provi qualcosa la provi di solito con un audience di 2, 3, 10 persone io...ragazzi eravate tantissimi ed ero cagato.E' andato e quindi posso dire a voce alta che se ci sono riuscito io ci può riuscire chiunque.Questo è un modo per dire che spesso la paura deve essere l'elemento che ci fa uscire dalla nostra zona di comfort.Deve essere quel gioco, quel livello del videogame che ci fa saltare al livello n+1 e quando lo finiamo siamo super super felici per cui se avete una sfida davanti non procrastinate buttateci a capo fitto questo è il mio consiglio che vi do proprio fresco fresco da di avventura.Detto questo io ho parlato già un sacco però erano delle cose che mi sentivo di dire e che non ero in grado di scrivere in un post LinkedIn voglio ringraziare tutti voi e tutti gli amici che ho incontrato a Code Motion siete tantissimi non dirò i vostri nomi ma sapete bene che i vostri volti i vostri sorrisi sono bene impressi nella nella mia mente detto questo io direi che a questo punto possiamo partire con l'episodio ma non prima di avervi ricordato i nostri contatti.Info@gitbar.it @brainrepo su twitter sono i modi canonici per contattarci.Abbiamo anche un gruppo telegram dove ci incontriamo e ci confrontiamo costantemente.Tra l'altro oggi si discuteva del post di Salvatore Sanfilippo su Linkedin, proprio Salvatore discuteva con noi del suo post e provava a spiegarlo con un pochino più di pazienza quindi se non l'avete ancora fatto iscrivetevi nel gruppo e per finire abbiamo il canale youtube, infatti mi vedete sono io, ma mi tocco, sì sono reale, quindi potete vederci anche vederci ecco su youtube youtube che è appena partito quindi è fresco fresco se non l'avete ancora fatto iscrivetevi e cliccate sul campanaccio perché è l'unico modo per entrare in contatto con noi quindi cliccate sul campanaccio così ricevete tutte le notifiche ma bando alle ciance io oggi ho con me un amico, un collega, un ispirazione per me e ho con me Paolo in sogna ciao Paolo Buonasera a tutti, qual'ispirazione dai? Troppo troppo troppo buono per me, per me, te l'ho già detta questa cosa, sei un mentor e quindi insomma sei un punto di riferimento ecco e questo volevo dirtelo pubblicamente.Troppo buono, troppo buono.Troppo buono, aspetta perché tra un po' ti farò delle domande che ti faranno cambiare idea e lo sai benissimo.Vai che non vedo l'ora, forza fammi divertire.Allora perché sei qua in realtà? Perché hai fatto uno uno sforzo abbastanza importante in questi ultimi mesi sia dal punto di vista personale che dal punto di vista professionale e volevo che tu venissi qua a raccontarci.Tu sei un Node Core Contributor giusto? Yes, sì sì, da un paio di anni.Ok quindi sei ancora lontano alla pensione per fortuna perché in realtà quanto pare Noda ha ancora tanto bisogno di contributors.Ma secondo il sito in Arcassa vado in pensione nel 2050, non glielo ho mai chiesto, me l'ha scritto un giorno che facevo il login quindi bella così, ho tempo.2050 insomma? Non c'è male, tipo 41 anni di contributi ha calcolato.Io vorrei andare a vedere nel mio sito dell'URSA, penso che dirà "fine lavoro mai", tipo "fine pena mai", ce l'hai presente? Qualcosa del genere.- Io spero molto nella qualità dei servizi pensionistici francesi, ma mi sa che sarò deluso tantissimo.Comunque, a parte i discorsi dei vecchi che iniziano, quanti anni ti mancano alla pensione? Andiamo subito al sodo.Tu, node core contributor, ti occupi della parte HTTP.La prima domanda che voglio farti è quando tu mi dicesti io mi occupo prevalentemente dello stacco net HTTP mi venne subito una domanda che voglio replicare oggi e la domanda è cosa vuol dire mi occupo di questa porzione di codice? Nel senso non tocchi le altre parti di codice, non conosci le altre parti di codice o sei tipo un guardiano, sei il caronte che traghetta le anime verso lo stack HTTP? Tutte e tre quello che hai detto.Perché allora ti spiego.Il punto è che quando tu entri nel...no faccio un piccolo passo indietro.Tu inizi a contribuire a Node su base volontaria.Ora nel mio caso era anche su base lavorativa perché comunque era coperta da NearForm, ma diciamo che in generale parte come base volontaria.Quindi quando tu parti in base volontaria se tu scegli semplicemente "guarda ho visto sto bug che mi affligge sull'http" oppure "ho visto sto bug che mi affligge sul child process" e così via diciamo naturalmente è il tuo interesse personale visto che comunque si parla su base volontaria e ti dice "io intervengo su quella parte di codice" nel tempo fai questo fai quest'altro fai insomma costruisci una conoscenza di una certa parte della codebase e quando poi passi a contributor ti viene fatto un nonboarding da un membro del TSE e ti chiede, nel mio caso era Matteo Collina, mi chiese "Tu su quale parte lavori?" e io risposto "Ho messo mano solamente ad HTTP" e di conseguenza net, perché chiaramente sono strettamente interconnessi è difficile toccare l'una senza l'altra.Ora, nulla mi impedisce domani di svegliarmi e mandare ad esempio una PR sul worker thread, non è che mi è precluso.È chiaro però una questione di praticità e vista la dimensione della codebase di Node, io tocco solamente HTTP perché è la parte che conosco, per quanto riguarda quando sono io ad essere attivo, quando sono reattivo nel senso di arrivo a una pull request da recensire, oppure arriva una issue di cui fare il triaggio e verificare eventualmente scrivere una PR per sistemarla, vi è interessante che siccome io conosco solamente lo stack HTTP, non vado a guardare l'EPR del versione di child process perché solo fare il debug mi porterebbe via proprio entro un mese.Quindi nel tempo naturalmente si porta a una certa settorializzazione del codice.A me anche io di nuovo non ti chiami Mr.Collina e metti mano a Doty para te perché sai tutto il codice a memoria, ma si parla di gente normale qui, non di altra gente.Però in generale sì, conosco altre parti del codice ma molto di striscio, quindi non potrei metterci vano.Ora è arrivato il momento di ringraziare i donatori, chi ci supporta e fa sì che possiamo in qualche modo portare avanti l'episodio.Questa settimana abbiamo Luca Montagnoli che ci ha offerto da bere, quindi ringraziamo Luca, alziamo il nostro calice virtuale per Luca e abbiamo anche un'altra un'altra entità da ringraziare pensiamo a una cosa oggi con Paolo parleremo di scrivere un parser http in Rust che poi è il parser che si propone di sostituire quello attuale di Node, scrivere un parser http in Rust è uno di quei task che presuppone un altissimo carico cognitivo e siccome siamo esseri umani limitati dobbiamo offloadare un po' di pensieri per poter gestire questo tipo di complessità.Possiamo farlo scaricando attività noiose che generano pensieri a persone che sono professionalmente preparate per farlo.Così limitiamo il nostro carico cognitivo.Una delle attività che genera spesso molto carico cognitivo è la gestione della partita IVA che se fatta da un professionista uffidato diventa molto più semplice.Ecco perché se avete la partita IVA o state pensando di aprire una partita IVA vi suggerisco Fiscozen che tra l'altro ha contribuito a realizzare questo episodio.Pensate che qui in Francia cercavo disperatamente un servizio simile o omologo.Fiscozen ci consente di aprire e gestire la partita iva online ma non è un servizio automatizzato.Si tratta infatti di un commercialista dedicato in carne e ossa che segue le nostre pratiche da quando apriamo appunto il nostro account in fisco zain finché dura il nostro il nostro contratto e ci segue sia al telefono e via email.Il commercialista che grazie all'uso della piattaforma non ci chiede di portare i documenti in ufficio e quindi ci saltiamo tutti i problemi di traffico e simili ma accede al nostro gestionare e cassetto fiscale in modo diretto senza interrompere i nostri focus time che sono diciamo la cosa che abbiamo bisogno di tutelare.Possiamo anche tra l'altro effettuare la fatturazione elettronica direttamente nell'apposita area proprio nella piattaforma di FiscoZen e dalla stessa area possiamo poi inviare le fatture ai nostri clienti.Per quanto riguarda le tasse ci dà la possibilità di avere una visione in tempo reale di quelle che sono le tasse che andremo a pagare.Questa cosa è molto figa anche per gestire appunto il nostro cash flow.Se abbiamo un dubbio, cosa che capita praticamente sempre, siamo consapevoli del fatto che FiscoZenon è un plugin per chat GPT.Questo vuol dire che abbiamo un commercialista in carne ed ossa che si prenderà cura delle nostre pratiche dal giorno della sottoscrizione del servizio e rimane lo stesso per tutta la durata della consulenza.Ci fa anche la dichiarazione dei redditi che è inclusa nel servizio annuale.Con questo commercialista possiamo parlare via chat, email o se proprio siamo old school anche per telefono sì per le cose urgenti ma fax mi hanno detto mi hanno confermato che neanche loro non lo usano altrimenti se abbiamo proprio un'informazione da prendere al volo possiamo scrivere nella chat della piattaforma e c'è un consulente che risponde ai nostri dubbi immediati.Bene se quello che vi ho appena detto pensate possa semplificarvi la vita beh potete chiedere una consulenza gratuita usando il link in descrizione che tra l'altro aiuta a supportare Geekbar e facendo così oltre alla consulenza gratuita utilizzando il codice sconto Geekbar 50 potete avere 50 euro di sconto sul primo anno di servizio facendo così potete tornare alla riscrittura in RAST dell'ultimo vostro site project senza pensieri legati alla vostra gestione amministrativa o alla vostra partita IVA.Grazie Fiskozer! Voglio chiederti una cosa, il fatto di agire su parti specifiche del codice presupporrebbe che il codice sia in qualche modo ben compartimentato o comunque i moduli siano ben isolati tra di loro ma è una situazione realistica questa o in realtà non sono così isolati quindi ti rompi le...impazzisci anche se stai agendo sullo stack HTP? Allora, mettiamola così, non lo sono tantissimo però diciamo che nel 90% dei casi non hai problemi.È chiaro per esempio a me di solito di solito il problema mi si verifica che mi perdo nella codebase quando scendo nel C++ lì per esempio inizi a perderti perché il modo di scrivere C++ è piuttosto peculiare dentro Node, allora quando io vado a...magari devo toccare una parte del HTTP lato C++ può essere un po' impicciato, però mediamente te la capisci, riesci a stare abbastanza isolato certo, a me che non ti occupi di un modulo che è pervasivo ovunque, però anche se non mi viene in mente nessun esempio, forse Buffer, l'implementazione di Buffer, che ovunque magari tocca il buffer poi da fastidio a chiunque.Mi hai appena stimolato altre due domande, per cui sto cercando di metterle in coda.La prima è la parte c++.Quando hai detto "è piuttosto peculiare" mi hai fatto pensare a questa domanda.Cioè la parte c++ in realtà, quando tu vai a fare una modifica quanto importante è almeno nello stack HTTP e net e quanto c'è invece di javascript sopra? net un po di meno forse, HTTP se riesce a dare una buon fine a quello che sto pensando sparisce tutta la parte C++.Per intenderci.Perchè...vabbè, per nè parleremo in seguito, però chiaramente la parte C++ al momento è quasi solo il parser.Su un net invece c'è una parte che rimane che è il processamento della socket a basso livello, che è piuttosto peculiare, però fortunatamente è anche la più stabile, a parte l'auto selection, il network family auto per il quale sono stato già sputtanato dal signor Collina a Desenzano.Io non so di cosa tu stia parlando, che cos'è l'auto selection? Praticamente in Nod, se non ricordo male, 18, fecero una modifica sul resolver DNS, che mentre i primi record DNS venivano ordinati secondo famiglia, quindi anche se ricevevano i record in maniera sparsa, Nod li ordinava e provava prima tutti gli IPv4 e poi tutti gli IPv6.In Node 18 hanno detto "No, manteniamo" che è anche più corretto "l'ordine restituito dal DNS".Quindi tu potresti avere un IPv6 prima e un IPv4 dopo.E quello che succede è che se, come capita a molti, lo stack IPv6 è configurato male, Nod provava solo il primo host e non era in grado di connettersi a molti endpoint.Alla gente si lamentava.Allora io ho implementato un algoritmo che si chiama Happy Eyeballs, un RFC che si chiama Happy Eyeballs, che stabilisce come effettuare simultaneamente, a linea teorica, tentativi IPv6 e IPv4, detta proprio in soldoni, ordini record in maniera alternata di famiglie, proprio in prima una famiglia e poi l'altra, semplicemente però alternati, non tutti una volta e tutti non l'altra.In reale l'algoritmo richiede che si faccia parallelamente, sul node non è possibile, quindi deve implementarlo sequenzialmente.ho implementato questa modifica che è diventata default su Node20 e come succede a tutti i migliori rilasci, nel momento in cui ho dato la vera userbase sono più avute raffiche e raffiche di issue, perché in molti casi non funzionava, anche se la test si ha e passava sempre e quindi sto ancora cercando di sistemare tutti i bug dopo 8 minor version Hai appena detto una cosa che è particolare proprio del lavorare su che sono alla fine base di milioni di applicazioni e io so che tu hai un passato da realista hai per tanti anni scritto business logic ricordo male la prima volta che ci siamo incontrati tu rantavi per react native perché di su un prodotto react native possibile? Cioè, porcheria, si, si era atroce, era veramente atroce.Ok, quindi hai un trascorso su prodotti, su prodotti digitali.Sì.Oggi lavori, a parte naturalmente la parte da dev rel che fai, lavori prevalentemente invece su Node, su gli elementi a corredo che orbitano attorno all'ecosistema Node.Cosa è cambiato nel tuo approccio proprio allo sviluppo? È cambiato qualcosa? Perché in realtà sono due sviluppatori completamente diversi.Sì, la lunghezza della visione.Nel progetto, anche se ci diciamo un sacco di bugie, ma tante bugie, mi confermerai che nella tua esperienza si lavora quasi sempre a corto termine, a breve termine e se ti va bene a medio termine.Quando progetti open source e progetti un software che non è il software finale, nel senso che il node da solo non serve a nulla se non ci esegui un file javascript sopra, inizi a percepire il fatto che devi ragionare molto sul più lungo termine.Ad esempio, un cambio impattante, a un punto lì, se metto un API su HTTP, partendo anche dal presupposto che il semplice fatto di inserire un API mi preclude di poterla rimuovere a meno che non vado su una breaking release, perché anche rimuovere l'API è breaking, no? Quindi, se io inserisco una nuova API che è SMWARE_MINOR, rimuovere la SMWARE_MAJOR.Quindi devi ragionare su un lungo periodo, visto che Node fa una cutout di una major release una volta all'anno, magari se sgarro l'API che potrebbe potenzialmente essere dannosa rimane lì per almeno un anno, se non di più.Se non puoi anche percepire che, per esempio, se l'API piace a me e magari piace a 30 persone e a 50 da fastidio, magari tu per le 30 persone comunque la lasci, anche se da fastidio, allora la devi sistemare.Quindi devi ragionare in maniera molto più ad ampio spettro, più a lungo periodo, più soprattutto applicando il vecchio motto di Google, quello originale che mi hanno per esempio non seguono da millenni ormai, il "Don't be evil", ovvero cerchi di essere sempre in buona fede, essere pro-positivo verso gli utenti.Specie nei casi di Node, dove non c'è una società dietro, che ti dice "guarda, anche se stai a fa' open source, in realtà deve essere pilotato".No, Node è puro, è puro, tant'è che per regola di TSI non ci può essere il takeover di una società del TSI o dei collaboratori e così via, vai tanto sul lungo periodo, sull'essere gentile e poter dare l'esperienza di sviluppo migliore all'utente finale, cioè avere delle API utilizzabili, comprensibili, documentate, performanti, sicure.Questo più o meno nell'ordine di importanza, l'ho detto.Forse sicuro dovrebbe andare un po' prima, ma insomma più o meno.voglio farti una domanda lo so lo so tra un po' arriviamo anche perché sto fremendo però mentre parli mi vengono centinaia di dubbi e quindi li devo mettere in questa coda first in first out altrimenti faccio casino.Nod ha il suo steering group che poi ha i vari come si chiamano ambiti comicati? Ambiti in alcuni casi di working group dipende dall'ambito, sull'http non c'è per esempio quindi gruppo di persone ma non strutturato, dipende dai casi insomma.Ok perfetto, cosa succede quando si sente l'esigenza di una feature? C'è un contatto diretto con la user base che vuole la feature XYZ implementata su node o è lo steering group che si sveglie e dice no ci serve proprio quest'altra cosa? ovviamente ci sono due casi nel caso la richiesta venda dall'utente vuol dire che tutto grosso modo parte da una issue che sia una feature request che sia un bug report che poi la finisce guarda in realtà non c'è un bug ma mi manca sta feature perché può succedere no? però diciamo che dalla ish tu più o meno hai un contatto con la user base che te l'ha chiesto, magari poi mi lanciano un sondaggio o qualcosa, insomma utilizzi GitHub come mezzo primario di collaborazione.Al contrario, allora, contrariamente a quello che si pensa, lo steering group non dà direttive, nel senso, è difficile l'iniziativa, per esempio è difficile che domani si sveglia lo steering group e dice "ragazzi abbiamo abbiamo deciso che bisogna fare la bootlink, implementare HTTP3.Paolo, pensaci tu.Non è un organo direttivo, ma è esecutivo.Lo stile in gruppo serve a dire che se ci sono ambiguità, decisioni importanti, su coinput già presi, ad esempio, abbiamo una nuova API, abbiamo un'API R pronta, che dite, la vogliamo emergere oppure sta API è pericolosa e non la emergiamo se a qualcuno sorge il dubbio perché al trend di solito chiunque si può svegliare la mattina e implementa un'API e la butta dentro quindi lo stealing group è più coordinativo che mi viene solo comandante in italiano, però avete capito che intendo imperativo, let's say imperativo esatto, è esattamente imperativo è più coordinativo che imperativo disambigua quando ci sono per esempio eventuali disaccordi tra collaboratori che non si riescono a risolvere con il buon senso e così via.E' chiaro che poi gestisce le cose più amministrative tipo fondazione eccetera di Node.js ma quello è fuori dalla questione di open source, cioè è fuori dalla questione della vita dell'open source a livello di codice, ci sono altre questioni legali, amministrative e quello lo fanno loro effettivamente.Ok, chiaro, chiarissimo.E poi insomma ci sono chi contribuisce tutti i giorni e chi si spende proprio per far sì che Node funzioni.Tra i vari appunto collaborator ci sei anche tu che hai fatto una cosa molto figa in questi ultimi mesi, hai lavorato a Milo che già il nome è una figata, che è l'HTTP parser, un potenziale sostituto dell'HTTP parser per Node.js.Allora, prima domanda, qual è ad oggi lo stato di HTTP in Node.js? Perché ci sono tante versioni, ne possiamo contare almeno tre, senza contare le sottofamiglie, le sottoversioni, le sotto cose...Sono tre.Aspetta, versioni HTTP a prescindere da Node.js in generale? In realtà sono veramente tre, perché nel senso, se tu vai a leggere gli RFC, HTTP 09 e HTTP 10 sono dei precati almeno da 30 anni.Addirittura HTTP 09 non ha mai avuto un RFC, è stato solo un draft.La 10 aveva un vecchio RFC obsoleto da almeno quattro versioni, c'è stato RFC 1, RFC 2, RFC 3, che è obsoleto e RFC di l'HTTP quindi immaginate la situazione atroce.Poi c'è l'HTTP2, che è una modifica del protocollo HTTP per sfruttare, se non ricordo male, spidi, connessioni TCP, header binari e altre varie ottimizzazioni del protocollo TCP, perché TCP al giorno d'oggi è un elefante, per intenderci, con le connessioni di oggi.E infine c'è l'HTTP3, che è appena uscito, basato su QUIC, che è una rivoluzione completa perché è su D.P.e non su T.C.P.quindi è una rivoluzione totale del protocollo dovuto al fatto che, forse molti sanno, ma non molti ci pensano, che il T.C.P.è estremamente pesante come protocollo perché è stato scritto nei tempi in cui non potevi avere fiducia neanche di un bit trasferito via rete quindi doveva essere estremamente paranoico.adesso può essere molto più linear su questo quindi l'odp va più che bene più leggero più veloce e così via quindi diciamo ci sono almeno tre versioni perché stiamo ammazzando tutte le mezze versioni si, le atrocità che hanno combinato si assolutamente ma tanto arrivo su quella, perché c'è stata una tua decisione, una tua presa di posizione quando hai lavorato su Milo In realtà tu hai lavorato uno strumento specifico che permette l'utilizzo del protocollo che è l'HTTP parser.Che cos'è e cosa fa? Banalmente il parser è chiaramente la componente software che che, dato i dati in entrata, te li trasforma nelle strutture dati che ti seguono per l'esecuzione del programma.Ovvero, si assicura che i dati che tu ricevi in ingresso seguono le specifiche del protocollo con cui avete scelto di comunicare via rete, o, per dirla in maniera più sensata, si assicura che il server che tu stai esponendo riceva solo messaggi nel formato corretto e da quei messaggi estrae le strutture dati che ti interessano per servire la richiesta, nel caso tu sia un server.Nel caso tu sia un client, si assicura che il server ti ha risposto di nuovo nel protocollo in cui tu stai procomunicando e da quel protocollo, da quella diciamo convenzione di regole dei dati, estrai i dati della risposta che ti interessano.Questo dipende da che ruolo hai nella connessione.quindi se volessimo semplificare, sbagliando, sbagliando, dimmi, corregimi se sbaglio, possiamo immaginare una stringa lunghissima, non è una stringa, lo so, non è realtà lo è, in HTTPS lo è, una stringa lunghissima che ha un sacco di informazioni e c'è questa cosa simile a Regex, che si va a prendere dei pezzi perché sono importanti per dare un senso e capire cosa succede.In realtà probabilmente non è una stringa, quasi sicuramente perché ho visto Milo, non sono delle...In realtà lo è, però è una stringa rappresentata come un vettore di interi senza segno a 8 bit.Che per realtà è la rappresentazione C, se ci pensi.Se tu pensi sul C, la rappresentazione della stringa, tu dici "unsigned char", no? Ma "unsigned char" è l'alias di un integer, di solito.In Rust è rappresentato come un "unsigned" a 8 bit, perché un carattere negativo non ha significato.Quindi tu hai questa lista di caratteri e tu uno per uno o a gruppi li parsi e da questi pezzetti estrai frazioni di informazione.Esatto, in realtà è più facile pensarlo, se ricordi di poterla buttare una cosa che non ti aspettavi mai, la macchina di Turing.Ehi, hai risvegliato i vecchi.Sarebbe brutta come cosa, però se ci pensi è quello, perché i caratteri tu li devi pensare come un nastro di carattere che ti arrivano.Quindi la puoi immaginare come una macchina di turing, mi arriva il primo carattere, è quello giusto? Sì, mi sposto avanti.È quello sbagliato? Rifiuto il parsing, cioè rifiuto il messaggio.E così via.Chiaramente puoi puoi essere un po' più goloso, nel senso di più eager e dire più gridi e dire "guarda ne leggo 10 invece che 1, li analizzo come stringa" e così via però l'idea è che devi pensare a un flusso di caratteri o un nastro di caratteri che farsi in una sola direzione e te li butti magari su delle allocazioni in memoria e dire "ok, in questo blocco di caratteri non ho raggiunto il carattere di fine, questi me li metto da parte aspettando il nuovo" Di solito non si fa, ma è una scelta implementativa di Milo.Solitamente i parser, quello che fanno, dicono "dammi questo N caratteri".C'è il concetto di consumare i caratteri, ovvero dire, i primi 50 li sono riusciti a collocare nella struttura che volevo.Gli ultimi 30 non mi consentono di collocare quello che voglio perché mi manca qualche carattere o qualcosa, quindi io ti dico "dei 100 caratteri che mi ha mandato ne ho consumati 50, la prossima volta ricordati di rimandarmi quei 50 iniziali perché mi mancano, scusami, quei 50 finali.Invece Milo quello che fa per semplificare un attimo l'area...- Una specie di rewind per capirci - Una specie di rewind, però lo deve fare il client, non lo fa il parser perché il parser per essere veloce cerca di non fare nessuna copia delle allocazioni, quindi non copia mai i dati.Infatti Milo rompe la regola solo in quel caso in cui ho scelto di semplificare la dx dell'utente e dire se io non consumo gli ultimi dieci caratteri, me li tengo io in memoria e quando tu mi rimandi a dati successivi sono io a fare il prepending, senza dover farlo a te a mano perché possono uscire errori nel codice e così via.LM: Chiaro.Quando tu parli di Milo, però, parli di un elemento, un Http parser, un componente, chiamiamolo così, forse il modo migliore per rappresentarlo.Un componente che segue due antenati che però fanno parte, ormai è sedimentata, della storia di Nod.Il primo era HTTP Parser e l'altro è LLHTTP.Partiamo da HTTP Parser che da quello che mi è sembrato capire è ancora nel il codice sorgente di...No, è stato rimosso nella 16, 18, non mi ricordo.Lo era fino a poche versioni fa, quindi non ti sbagli.Però nella 20 non c'era, nella 18 non mi pare ci fosse, sicuro.Non sono sicuro nella 16.C'era un vecchio switch che praticamente ha cambiato significato le vecchie versioni.Era una versione in CI un pochino alta, un bordello da metterci mano da quello che è.Soprattutto quello, però non ci ho messo mano ne so quanto tempo.Un pezzo di codice abbastanza convoluto e praticamente quando sono andato a leggere i repository di LLHTTP c'era scritto "praticamente esatto unmaintainable" e che praticamente aveva un charn, quindi un abbandono da persone che ci mettevano mano altissimo.E quindi si decise di fare l'LHTTP.Se mi dovessi descrivere in due parole l'LHTTP? Tra l'altro salutiamo Carmine.Ciao amico! Bella Carmina! Scusate per il ritardo, le persone non sanno fare i cid, però eccomi! Ha incidentato! Sì, un piccolo tamponamento.Ma tutto a posto? Sì, sì, sì, ero fermo, ero sceso dalla macchina e mi hanno distrusciato il paravortice.Questo qui dietro non sapia parcheggiare.Ma vabbè, a posto.Ma vabbè, bastiamo che tutti bene.A parte l'assicurazione.Assolutamente.Poi, appena puoi, accendi la cam così ti possono vedere tutti.Sì, sì.Dicevo, a questo punto quindi, Fedor...Sì, Fedor Indutti, gran pezzo di genio del male.No, nel senso buono, è un genio.Però ora che vi descriverò quello che ha fatto, perché lo descrivo anche del male perché è cattiveria.Allora Fedor nel 2019 se non ricordo male è uscito con "ho scritto un nuovo parser".Allora giustamente questo parser doveva girare su Node, quindi dovrebbe comunque finire ad essere in C, però dice "come facciamo a creare un parser che sia in C, ma che sia manutenibile?".Allora la prima idea che gli è venuta in mente, veramente non so cosa gli possa avere dato a quel bel ragazzone, è "ma perché non fare un traspilatore da TypeScript a C? Devo costruire una strada.Perché non inventare l'asfalto? Perché non inventare le palasitte? Tu mi hai accennato prima che sei andato a guardare la Codebase, hai visto che razza di follia.In realtà è una cosa un po' particolare, io ti dico quello che ho scoperto, perché mi ha anche entusiasmato, mi ha gasato tantissimo, ti dico la verità.Perché quando tu vai a leggere la codebase di LLHTTP la prima cosa che vedi è che utilizza quest'altra libreria che si chiama LLPars.Allora tu vai a vedere che cos'è LLPars, che fondamentalmente è un parser che utilizza una state machine, anzi è un generatore di parser che utilizzano una state machine o meglio pensa sto avendo difficoltà di scrivere perciò è un generatore di codice c che genera un parser che utilizza una state machine per parsare della roba il fatto che non riesce a spiegarlo la dice lunga so quando sia manutenibile vero? in realtà in realtà è una figata però perché perché comunque questa roba ti genera praticamente il file headers e il file .c e poi tu compili e tu la stai scrivendo in TypeScript.La cosa interessante in realtà è che lui nella merge request ha scritto "risolviamo il problema.Http parser è non mantenibile, c'è un significante abbandono di chiunque ci voglia mettere la mano.Quello che vogliamo fare è fare una libreria che lo renda mantenibile, verificabile e ben coperto da benchmark e test che lo rendono tale.Nel contempo mi arriva Paolo Insogna che mi dice è un bellissimo pezzo di codice però è immantenibile.E allora qua parlo di LLXPD.LLXPD.E che ci manca nel mezzo? Lo strumento che sarebbe dovuto essere la chiave di volta per rendere mantenibile quel pezzo di codice diventa non mantenibile, anzi diventa veramente l'elemento che insedisce attrito nella mantenibilità da parte di altri developer.Cosa non sta suonando nell'equazione? Allora, due cose.Primo, dov'è la documentazione? Perché non c'è una riga di documentazione.Quindi quando ho preso in mano le cttp di penso più di un anno fa, ho dovuto capire tutto da solo, a manina.Perché poi abbiamo anche dimenticato di dire che i file sono di test.Udite, udite, voi che ci ascoltate o vedete, sono dei file back down traspirati in C.Gli occhi di Carmine! E' il gioco dell'oca con...E' una follia! Allora, là ti rendi conto che è un pezzo di genio, perché io neanche per un secondo ho messo in dubbio che quel PLL-CTTP funzioni o che sia stato scritto che c'è un approccio estremamente innovativo.Però il problema è che tu già stai in Node, seguire HTTP parser, intendo dire la classe interna di Node che gestisce sto parser, cioè che si interfaccia con l'LLCTTP, non è semplice.Poi c'è LLCTTP che devi fare la traspilazione folle per capire che cavolo combina, e ancora dietro c'è LLParse.Quanti livelli ci sono di complessità da seguire per fare le operazioni di parsing.Ma porto anche oltre il sotto insieme di TypeScript che usa è piuttosto limitato e contorto.Per fare delle operazioni semplici devi utilizzare dei metodi molto contorti.Select, pick and match sono intuitive, ma c'è la select, c'è la test, linea e flag.Il più grosso problema che io vedevo è che tu non sai una volta che inserisci una regola è difficile molto tracciare quello che tu inserisci a quello che viene il codice effettivamente eseguito e ti rende estremamente difficile valutare per esempio l'impatto nelle performance.Quindi, quindi se sto capendo bene il vero problema in realtà sta nel fatto che c'è una grande distanza tra quello che c'è scritto e quello che fa.Esatto.Teniamo la mente questa perché ti prometterò dopo, basandomi su questo e tra l'altro sono in minoranza perché so che Carmine la pensa tantissimo come te e la penserà tantissimo come te.Dicevo la cosa simpatica è stata poi andare a vedere il repository di Milo.Milo è la riscrittura quindi di questo parser in Rust e già su quello c'è un po' di domande il cui Readme scrive "l'obiettivo di questo progetto è rendere più mantenibile e verificabile e facile da leggere" io secondo me qua c'è un troll DTG la prima cosa.La vignetta con gli standard di Dilworth, giusto? E in realtà è totalmente involontario, sappi che è totalmente involontario.Ho sofferto come un cane per documentare Milo perché odio scrivere documentazione, ma almeno la documentazione ci sta su Milo, su ogni modulo, persino i reference.Però ecco, l'obiettivo di Milo, la partenza di Milo fondamentalmente, è la stessa esigenza, è nata dalla stessa esigenza che poi ha creato il HTTP fondamentalmente.Quindi possiamo dire, e questo lo dico io non lo dici tu così, tengo buono tutto il tuo rapporto con Fedor che so che stimi tantissimo, che fondamentalmente l'HTTP può essere visto da un ognubo ed esterno al meccanismo come un'iterazione fallita.No, il problema è diverso.O meglio, bisogna andare su due binari paralleli.Se tu mi dici l'efficienza, la performance e la sicurezza software, no.Se tu mi dici la gestione del software open source, inteso all'ideolo del movimento open source, e quindi la sua utilizzabilità fuori dal lato tecnico, là purtroppo sì, perché Fedor praticamente è scomparso online, è molto poco attivo online e siccome prende tutta la conoscenza che aveva lui e non ha lasciato documentazione, questo non sarebbe ingestibile.Perché se io quando venivo all'Olecio potevo chiamare Fedor e dire "Fedor, che problema c'è qua? Te lo fai capire un attimo quello?" oppure lui stesso se ne occupava, non mi sarei mai messo a riscrivere Milo perché è stato un bagno di sangue scrivere Milo per vari motivi.Certi me ne sono cercati, certi no, però me la sarei banalmente risparmiato visto che il par se le batte il test ed funziona bene perché andarsi a cercare mazzate.La mia domanda, secondo me, è un po' più operativa.Nel senso, Milo parte dai test di LLHTTP o no? Perché se l'avessi dovuto fare io, non lo so, adesso così, avrei detto "ok, voglio partire da quella cosa lì", però riscrivendoli in un modo.A questo però avrei anche pensato "sì, ma perché li devo riscrivere? Non li posso utilizzare direttamente?" e forse la risposta è no, perché sono in markdown.No, no, in realtà, per come è scritto quel markdown, inizialmente avevo quest'idea, poi per le attività che sa Mauro di DX, quindi a prenderti conto è il primo giorno che sto a casa da qualcosa come un mese, ho avuto difficoltà a seguire lo sviluppo regolare, abbiamo una versione funzionante con dei test scritti a mano, però ho intenzione di migrare tutti i test di LLHTTP, che poi in realtà, cosa che non è molto conosciuta, buona parte di quei test in realtà sono i test di HTTP parser, perché HTTP parser negli anni aveva avuto una batteria di test gigantesca che Fedor giustamente ha migrato su LLHTTP e io banalmente mi porto appresso su Milo, perché se passano quelli una specie di compliance test uno può stare tranquillo, quindi ho intenzione di farlo.E' nella mia to do list diciamo realisticamente dicembre.No, nel senso che era una cosa interessante, mi stavo dicendo ok, tu lo riscrivi però alla fine per vedere se funziona come funzionava quello vecchio hai bisogno di fare una cosa del genere.L'ho fatto, ma dove non vi aspettate.Non con i test di Milo, con DLLCTP scusami, ma Milo come proprio concept iniziale l'ho già integrato dentro Node, con la compilazione statica, e quindi ho dovuto assicurarmi che girassero tutti i test di Node.Parliamo di qualcosa come...solo di HTTP sono qualcosa come 400 test.Quindi è una sorta di test integrazione alla fine, di riflesso.Esatto, perché la testi sia la verifica, la parsing del protocollo, una marea di edge case perché il node c'ha issue di tutti i tipi e anche la gestione delle callback e così via.Memory leak, quant'altro.Quindi ho una bella batteria di test già eseguita praticamente sul node.Come si inserisce Milo all'interno di node? Nel senso che Milo è comunque scritto in Rust, sono abbastanza novizio di RUST, ci lavoricchio, ma ho visto il processo sicuramente diverso di prendere una cosa scritta in RUST e farne un ANIF per Erlang, ad esempio, e non è stato semplicissimo.Come si inserisce questo dato qui all'introduso? Viene fatto qualche cosa per cui poi viene presa dal C++ oppure c'è un binding diretto? Entrambe, nel senso che ho scritto node con la compatibilità di Rust per il C, quindi una rappresentazione in C, e quello che ho potuto fare è che quando tu compili Milo ottieni una libreria appunto, nel caso di Mac OS, che attualmente è ottenuta da Mac OS, ma vale anche per Linux, devo verificarla ancora per Windows, ma c'è il modo, ottiene una statica, quelle si chiamano file.a perché è familiare con il static linking, e c'è un tool rilasciato da Mozilla che dato un file Rust ti genera gli header .h, quindi io avevo un file .a e un file .h, il .h ovviamente viene utilizzato all'interno dei sorgenti di Node e il .a viene incluso quando vai a linkare completamente Node.Questo era il mio approccio iniziale, va da sé però che quando l'ho mostrato al Node Collaborator Summit a Bilbao, quasi due mesi fa, all'inizio di settembre, in realtà mi hanno detto che è un approccio un po' scomodo perché non poter compilare da sorgente e si è preferito invece chiedermi di muovermi su WebAssembly, perché Rust compila estremamente facilmente su WebAssembly e WebAssembly è un first class citizen sul Node perché Node, ricordiamoci, comunque utilizza V8.Quindi eseguire WebAssembly sul Node è semplice, tant'è che la conversione ci ho messo due giorni perché curiosamente l'interfaccia C e l'interfaccia WebAssembly sono la stessa.Ci sono piccole cosine da sistemare, ma in generale ho avuto pochi problemi.E quindi adesso sto utilizzando Milos U11 come primo passo per WebAssembly.Successivamente lo integrerò dentro Node con WebAssembly WebAssembly non più con il punto A.Mi sono arrivato a 70 notifiche.Tutto nel gruppo Gitbar di La Verità.Assolutamente.voglio chiederti una cosa a questo punto, in WebAssembly, non so perché ma c'è questo feel che vorresti fattare, c'è un overhead rispetto allo static linking? C'è perché c'è il discorso che tutti i dati che viaggiano dentro e fuori di WebAssembly devi copiarli chiaramente, o meglio parzialmente, perché ci sono aree di memoria condivisa, è un po' complicato, però non conosco bene i dettagli, ma so che c'è un piccolo verde di copia dei file.E poi, oltretutto, quando tu generi il file web assembly da Rust, ti viene creato un file javascript intermedio che ti gestisce la serializzazione e disrealizzazione dei dati in automatico, quindi non devi farlo tu a mano, che sarebbe piuttosto contorto.E chiaramente quel file una parte un po' in più chiamata.Però, d'altro lato, c'è questo ragionamento che bisogna fare.Node ha due, in realtà di più, ma diciamo a livello core, ha due bridge.Uno è il bridge JavaScript C++ e uno è il bridge JavaScript WebAssembly.Ora, è stato testato, non so di quanto ma è stato testato che il bridge web assembly è più lightweight di quello c++ quindi significa che se io sostituisco l'lctp, anzi facciamo il caso proprio di lctp, che lctp ha sia la versione in c++ che la versione in web assembly, in mia teorica se si usasse la versione web assembly sarebbe più veloce perché l'overhead di copia della memoria è compensato dalla più leggera più grossa leggerezza del bridge quando vai da davanti e dietro tra WebAssembly e JavaScript e quindi in realtà le prestazioni non cambiano o perlomeno niente di percettibile perché se cambia un per cento voglio di infregare nessuno alla fine.Sì sì sì assolutamente.Andiamo a questo punto su Rust.Prima domanda.Una cosa per la quale hai tutta la mia stima e anche di più è che prima di scrivere Milo tu conoscevi zero Rust.Ok? Conoscevo poco e niente.Se vedi sul mio GitHub c'è solo una piccola utility per me stesso di prova che si chiama Yuna, se la vuoi tanto vedere è open source, che prende e leggeva un file, lo parsava e metteva le variabili d'ambiente appunto proprio a questo livello di diozia e basta.Era un toy project del cavolo quindi Rust lo conoscevo zero, quasi zero.Ok, parliamo dell'esperienza.Giorno 1.Cazzo, mi scrivo l'HTTP parser in Rasta, ma non lo conosco.Cosa faccio? Oltre al CargoInit insomma.Il problema è che devi già avere un'idea.Allora la mia prima idea era, prima di poter scrivere il parser, posto che, cosa che fino ad adesso non abbiamo detto, ma io ho riscritto Milo, ma l'architettura è quella dell'HTTP.È è sempre una macchina a strati finiti con lo stesso tipo di comportamento allora ho pensato voglio riprodurre quella macchina a strati finiti iniziamo con un linguaggio giocattolo per esempio A seguito da B aspetta e perdonami giusto per coprire tutti i termini che utilizziamo tre parole per la macchina a strati finiti oddio questo è una guada come la spiego non la so spiegare allora praticamente è un - Non si spiega una mafia, non so divere.- No, perché mi viene in mente la definizione formale da ingegneria, che è neanche ricordabilissimo.- No, non usarla, non usarla, sembri un barro.- Eh, appunto.Allora, praticamente, devi pensare che un grafo, ok, in cui...Puoi immaginarlo come un grafo.Si parte da uno stato iniziale, che è l'inizio del grafo, e si può arrivare a più stati che possono più o meno essere finali, seguendo una specifica sequenza di regole, ovvero per passare da uno stato all'altro non è semplicemente il collegamento tra due stati, ma si deve verificare una condizione.Penso che è il modo migliore per spiegarla, senza usare la formalità.Tornando a noi, Milo doveva essere una macchina a stati finiti, e io dico "ok, modelliamo in rasto una macchina a stati finiti".Come la scrivo? Iniziando con una macchina a giocattolo, e quindi ho fatto letteralmente, il mio primo esperimento è stato.Voglio scrivere una macchina che interpreta quattro lettere A maiuscole di fila seguite da un numero qualunque di B di fila, diciamo come se implementasse un'espressione regolare per certi versi, soprattutto perché ricorda informatica teorica, macchine a stati finiti e regolare expression sono equivalenti, ma se lo vogliamo passiamo oltre.Quindi sono partito da quello.Nel momento in cui questa macchina funzionava ho detto "ok, qual è il modo più performante per far eseguire questa macchina? Perché posso chiamare funzioni, posso scrivere un grande blocco match, posso scrivere tanti blocchi match innestati e così via".Fatto queste piccole prove, quando sono arrivato a una versione finita ho detto "ok, ora astraiamo cosa devono fare questa macchina a stati finiti".Ad esempio, come si definisce il nome di uno stato, perché tu devi avere la lista degli stati possibili, poi come si fa a muoversi da uno stato all'altro, qual è l'operazione che devi definire, come si consumano i caratteri di input e l'ultima cosa esegue uno stato quando devi fare l'evaluation di qual è lo stato successivo.Quindi ho definito questi piccoli blocchi di operazione.Quando tutti questi blocchi erano sufficienti, ho scritto FETender e quella macchina state finiti per il protocollo HTTP.Quindi stai dicendo che fondamentalmente quando hai approcciato al linguaggio avevi come chiaro in mente quello che volevi realizzare.Questa è una cosa interessante da capire perché spesso, questo è un mio problema, spesso quando utilizzo un linguaggio nuovo mi viene dannatamente difficile, lo faccio lo faccio realizzando side projects.Il problema è che il side project è uno diverso ogni volta, quindi sto approcciando a un linguaggio nuovo con un doppio carico cognitivo.Il primo è quello di capire cosa questo nuovo side project farà, non è chiaro.Il secondo è la complessità del linguaggio quello che hai detto tu è che definisco un'unità minima da realizzare con linguaggio che conosco molto bene quindi ho ben chiaro quello che sto andando a realizzare e a quel punto poi il linguaggio è il tramite ma la complessità che ho sotto mano è la complessità del linguaggio e non di quello che voglio realizzare.E' un po' come...Carmine tu e Alessio me l'avete detto questo, il vostro modo di studiare il linguaggio è un po' legato al "prendo l'applicazione o il servizietto che è il mio site project fisso e me lo riscrivo in 70 linguaggi perché almeno quello rimane" ed è di tu no? Sì, c'ho il bot telegram scritto "o camoladrast" la Rust.Sì, sì, assolutamente.Perché è qualcosa che tu conosci, di cui già sai più o meno le insidie del dominio.Poi alla fine ci sono le insidie magari del linguaggio stesso che sono effettivamente quelle cose che puoi imparare.Sì, ma è una tecnica che uso anch'io effettivamente.Cioè, spesso prendo le stesse cose, ho scritto il mio API server, l'ho scritto in Java, l'ho scritto in Go, prima o poi l'ho scritto anche in Rust perché so che non resisterò.In realtà è anche affascinante perché è cosa che in realtà uno non pensa è che non solo ti toglie complessità, ma ti dà anche spunti di apprendimento che non avresti fatto in case naturali.Perché ad esempio se in Go strutturi il codice in una certa maniera, in Rust lo devi fare in maniera diversa, ti dà già un input mentale di dire "aspetta, quando stai in Rust non puoi fare quello che fai in Go, che fai in JavaScript, che fai in C quel che ti pare insomma.Quando stavi realizzando Milo, quali erano i tuoi punti di riferimento per quanto riguarda Rust? In che senso? Per capire come dovevi fare le cose.Google.- Ah, beh, io lo so! - Sono il peggiore, lo so! Sai cosa? Io non avevo nessun riferimento, non avevo nessun podcast eseguito, nessuna documentazione.Io dicevo "devo scrivere il ciclo 4, devo fare un match di caratteri, come si fa in Rasta? Cerco su Google".Poi magari è chiaro, per esempio, nel caso del webassembly c'avevo la guida di webassembly, di wasp, bin, gen, in quel caso sì, specifico.Nel caso, per esempio, un critical utilizzato in maniera mostruosa è stato QUOT e SYN, quelli per parsare e generare codici RAST, di cui parlerò meno quanto ho capito in seguito, e quelli, però, mi sono dovuto reggiolare la loro documentazione, però l'API, non la documentazione tipo sito, in maniera estensiva, per capire un attimo come andava Poi per il resto, come ti avevo già detto in offline, quando mi si poneva il problema risolvevo quel piccolo problema.Diciamo che ho seguito un approccio molto pragmatico di dire "conosco il minimo che mi serve per andare avanti, quando mi blocco ci metto un nuovo mattone, ma non inizio a mettere sovrastrutture perché divento veramente stupido, se no mi perderai nella complessità sia..." Aperte e chiusa parentesi.Oltre a non aver mai usato Rust, io non avevo manco mai scritto un parser.questa cosa non t'ho detto.C'è stata una prima volta su entrambe le cose simultaneamente e allora ho detto io mi devo mantenere al minimo la complessità.Quali sono gli elementi che hai scritto e che dovendoli scrivere in javascript non useresti mai? A parte naturalmente il match perché quello non ce l'hai.Il match manca purtroppo.Le macro in javascript non le potresti usare? A meno che non fai il transpiling.Lo potresti fare se impicci e metti un passo di transpiling, quindi parsi e crei un nuovo AST.Tecnicamente possibile.Sarebbe complesso da fare spavento, però nulla te lo impedisce.Altri elementi...[sbuffo] In realtà questo, perché la cosa che ti stupirà è che se tu vai a vedere il codice di Milo, La complessità del Rasta scritto, a parte essere piuttosto grosso, in realtà è stupido.Match, punto.Abuso del match.E' preso chiamato di funzione, c'è StannyFor, non ho scritto per chi si fa codice Rasta, sapete che non c'è un solo lifetime, non c'è un trait, non c'è niente di niente.Quindi è scritto ad approccio funzionale, quindi non c'è L: hai usato una parola che dentro di me da gnubissimo errazma che però ci si sta mettendo, affascina e spaventa nel contempo, che è la parola macro.All'inizio ho detto che si sentiva che venivi dal mondo ruby in genere, mondo dove si abbonda di metà programmazione.Leggendo il codice di Milo si vede che hai abbondato...Abusato si dice, domino apparentemente abusato.Allora ti dico, chiunque me lo conoscerà stai a guardare e mi dice "ma che problema c'ha con le macro, per la prima volta mi dicono tutti.Allora, hai abbondato di metà programmazione e la prima cosa che ho pensato siccome ti conosco, siamo diversi anni che ci conosciamo, la prima cosa che ho pensato è "ah Paolo ha visto che c'erano le macro che sono uno strumento potente e si è sfogato di decine d'anni in javascript dove non aveva questa costituzione.Ma adesso Mauro entra nella parte bastardella.Il problema è un po' la provocazione ma secondo me ci sta.Uno dei problemi della metà programmazione è che nasconde complessità sotto il cofano.Quindi crea un layer che nasconde un certo livello di complessità e mi viene da dire provocandoti, non è molto lontano da quello che faceva lhlhtp in un altro livello.Quindi la mia domanda barra provocazione è creando un livello di metà programmazione tale per cui tu hai un livello di informazione ma ne nascondi tantissima non stai creando un'ennesima iterazione, tale per cui ci sarà un Milo + 1 che dirà "questo progetto ha come obiettivo rendere mantenuto, mantenibile..." Certo, certo, però ci sono due differenze.Ti dico dove sono le due differenze.Allora, a posto che il motivo per cui ho utilizzato le macro è per rendere molto semplice scrivere il parser, altrimenti era un livello di ripetitività che non puoi immaginare di base.Potrei persino eliminarlo volendo.E ti dirò anche di più, nelle ultime versioni di Milo ho eliminato una barca di macro, prima ce n'erano molte di più e me le sono reso conto io stesso che quando dovevo debuggare la generazione delle macro era un bordello perché l'error reporting di Rerasta sulle macro è molto scarso, quindi era difficile capire quale riga stava fallendo.quindi l'ho ridotto all'osso, quindi figurati se ti dico l'ho ridotto all'osso e tu ne trovate una barca, ma comunque divagati, azione! Le macro servono per semplificare la gestione del parser, ma la grossa differenza con LLHTTP è che c'è un tool diretto che si chiama CargoExpand che non fa altro che dirti, piglio il file in input, espando le macro che ci sono dentro e ti generano un nuovo file rust.Se le affianchi al codice originale, per come ho scritto le macro, puoi facilmente trovare il quale diventa cosa.Ma ti aggiungo anche che a differenza di lLCTP, le macro sono funzionali.Intendo dire non funzionali, nel senso che hanno una funzione, sono scritte, sono pensate come codice funzionali.Quindi significa che se tu c'è del codice di Milo dici "guarda la macro, la butto lì, state, che cosa cavolo fa?" Tu puoi andare nel crate delle macros, vabbè divagazione, parlo del dettaglio tecnico dopo, vai nel crate delle macro e c'è la funzione state che puoi ben facilmente capire com'è passato il codice e qual è il codice generato, perché è un linguaggio di interpolazione piuttosto semplice, quindi si riduce all'osso.Sì in realtà là davvero è complesso capire...adesso al di là della cosa LOL che era giusto per riprendere...Sempre Dilbert penso io quella...Ci ho pensato due giorni per questa cosa...Sì sì sì ci sta ci sta...Te ne avevo anche parlato a Codimotion che ti avrei preparato il grappolone...benissimo è meritato assolutamente, però in realtà questo per evidenziare un problema di base che è trovare il modo per rendere il codice manottenibile, rendere il codice scrivibile quando in realtà c'è un sacco di roba da riscrivere, rendere il codice comprensibile in ogni suo livello di profondità sono i tre capi di una coperta che necessariamente è troppo corta e trovare il compromesso perfetto per questa cosa è pressoché impossibile.Capita quindi che ci si trovi nel tempo t0 dove un certo capo della coperta ha più importanza di un altro, che era per esempio il T0 specifico di quando venne scritto LLHTTP, che poteva essere le performance, dobbiamo fare un per 2, mi sa che era 55% più veloce o qualcosa del genere.No, due volte più veloce.No, una volta più veloce, perché l'HTTP parser faceva un milione e quattro e l'LHTTP ne fa tre e anche milo.comunque serviva concentrarsi sulla performance e quindi si è sacrificato la dev experience.Oggi con la consapevolezza serve impugnarsi nella dev experience ma nel contempo serve anche essere pragmatici e non metterci un secolo a scrivere cose ripetitive o fare bubble up a certi livelli di complessità che vanno nascosti.perché altrimenti torni indietro, torni ai ctp parser, perché poi si aggiungeranno sempre più regole e diventa impicciato da seguire esatto e quindi questo dimostra il fatto che in realtà non c'è un una best practice, segui quella e sei a posto, cosa che in realtà è meno frequente quando tu stai andando a scrivere un'applicazione salvo casi particolari cioè quando vai a scrivere una classica applicazione sotto il cofano 90% c'è il crude e così si fa il crude sai cos'è il scope più limitato sia nello spazio che nel tempo la tua applicazione è...anche se non hai creato il nuovo facebook ma a questo punto non faresti più interviste su youtube non ha migliori di utilizzatori per troppo, giusto? la tua applicazione è generica no Mauro? Non ce l'ha ancora.Non ce l'ha ancora, si dice.Mentre Nodde è usato a milioni di persone, come dicevo prima, la tua applicazione ci avrebbe un ciclo di vita di 1, 2, 3, 4, 5 anni.Nodde potenzialmente potrebbe averne 15, quindi devi ragionare.Io non prevedo di andare da nessuna parte, ma va a vedere che cavolo mi succede tra 15 anni.E quindi, insomma, questo.Domanda proprio così, ma strana.A questo punto, nel senso, se io voglio fare, non lo so, così e sto divagando, anche io ho avuto insomma qualche tempo fa, volevo fare anche un parser, abbiamo avuto un'esigenza in una vecchia azienda eccetera eccetera, e ce l'avevo in mente di farlo in ASCII, lo puoi fare una static library anche lì e fare tutto così, effettivamente era una roba funzionale, parsec, creosbris, e poi ovviamente una cosa che si è accasciata subito sotto il peso della complessità stessa del momento.Alla fine si fece in Ruby, con Tritop, con un sorto di parlo di un po' di tempo fa.Alla fine è caduto sotto il peso della la sua stessa complessità.Hai scelto Rast anche per questo motivo qui? Perché Rast e non Go ad esempio? Dove più o meno l'auto era volontariamente lo stesso? Pensiamo che Go era comunque più semplice rispetto a quello che...scusami, era più simile rispetto a Go.Go è più semplice, parliamone.Io ho scritto "go", l'ho abbandonato, mi aveva saturato beatamente il carico cognitivo."Go" è apparentemente semplice perché è un linguaggio dai costrutti semplici, però può diventare verboso e talmente verboso che ti rimbambisce.punto.Quindi ho detto Rust è un'altra alternativa.Allora il discorso è non voglio tornare a scrivere "gu", non voglio assolutamente tornare a scrivere "c++", rimane Rust.Facciamo anche l'esperimento di dire è possibile integrare Rust dentro Node? E poi banalmente la scusa per impararmi il Rust un minimo.Ho unito nobili intenti, vecchie frustrazioni e e diletto vergognoso in tempo lavorativo, mettiamola così.In realtà era questa qui la risposta che mi aspettavo, nel senso che alla fine è il motivo per cui non si è fatto in Haskell quella cosa super completa.Anche perché probabilmente se voglio un parser HTTP c'è già pronto in Haskell.Sicuramente c'è.Nel mio caso, dovendolo fare ad Acap, ho detto "almeno fammici divertire frattempo almeno una cosa che mi piace fare, anche perché parliamo un po' di sei mesi di lavoro da solo.A questo punto c'è Paolo che si è iscritto il parser HTTP, lo mette nel suo cestino e va al Node Collaborator Summit per dire "Ehi raga, io ho iscritto un nuovo parser HTTP".Non è vero perché in realtà gliene avevi già parlato, però mi piace molto l'immagine tipo Remaggio che va al node con la bici si si, si la cosa più assurda che mi viene in mente delle tre, si si assolutamente si e in realtà arriva la e dice "oh sai cos'è? noi nello stack usiamo c++ ma io te lo voglio fare in Rust" L'ambiente Nod, che è un ambiente comunque particolarmente conservativo, proprio per come è strutturato, come ha reagito a questo fatto che tu sia andato con il regalino in un linguaggio che era...Assolutamente non come mi aspettavo, perché anche io mi aspettavo delle resistenze, per esempio del "sai i draft non c'è perché non l'hai scritto in c++" o qualcosa del genere.In realtà l'unica resistenza che ho avuto è stata una che non mi aspettavo minimamente.Vi accennavo prima che Milo in origine doveva essere compilato come file .a e .h, e io gli avevo dimostrato che si poteva linkare Milo su un node, appunto includendo nella codebase il .a e il .h.e fine.La loro obiezione non è stata "cazzo, ho iscritto in Rust", ma è stata "eh però non ci piace avere già file compilati, mica possiamo includere l'intera source base dentro Node?" e io ho fatto "sì, puoi, però si deve anche installare la Rust toolchain sulle build machine" e vabbò che fa? cioè io che cercavo di evitare il problema, avevo pensato "faccio le release su GitHub di file.wa" così non devo installare la Rust toolchain sulle build machine, perché è un carico di DevOps non indifferente, mentre io su GitHub Action lo piglio gratis, tra virgolette.Quella è stata letteralmente l'unica critica che mi è stata mossa.A questo punto mi chiedo, questo dimostra un'apertura verso Rust di un sistema che era molto legato a C++? Sì.E dimostra quindi che qualcosa sta cambiando e ti faccio una domanda bruciapelo quanto l'apertura di linus torvald per le estensioni del kernel in RAM ha influito cioè linus è stato una pristrada da quel punto di vista a sdoganare questa cosa? Chi lo sappia zero, perché nessuno me ne ha mai parlato, nessuno mi ha detto "ah sì sì, facciamo come Linux" perché no? perché in realtà quello che stai facendo tu con questa operazione è portando il source code dentro node e quindi dentro le toolchain, tu stai facendo un'operazione ben più ampia del "riscriviamo il parser HTTP" e in questo momento parliamo di politica.attingo alle mie valigie di esperienza politica prima.Quello che tu stai facendo è stai creando il precedente tale per cui questa apertura di "let's write it in rust" può rischiare di diventare uno standard.A questo punto mi chiedo, le fazioni politiche conservative del C++ che oldano, che tengono, che mantengono un certo peso in termini di knowledge e anche di importanza.Non si sentono minacciate da questo tipo di cosa? No, non tanto.Innanzitutto perché a parte il fatto che l'una non lo esclude l'altra, cioè non si arriverà mai.Allora immaginiamo tra cinque anni, tanti moduli sono scritti in Rust, ma nessuno ha stabilito che devi per forza per esempio convertire quelli scritti in C++.Poi ci sarà un core che dovrà rimanere in C++ perché V8 è scritto in C++, quindi c'è poca scelta.Ma poi di base, premettiamo che uno dei modi per cui ho scelto Rust è anche che cercavo anche di intervenire nel mio piccolo nella manutenibilità di Node per i nuovi contributor.E quindi direi, è cavolo.Se dovono scrivere in Java scritto sì, ma se dovono andare sulla parte basso dell'Ello non ci va nessuno, magari il rasta è più appetibile, vediamo se si può inserire.Quindi è esattamente quello che cercavo di fare.Anche l'apertura a nuovi contributor.Esatto.Ovviamente ho usato la tecnica del "chiedo perdono piuttosto che permesso", perché al tema di se sarebbe iniziata una discussione infinite, cioè ci sono più ardi notte che ci fattono quattro mesi a essere emergiate, e non per discussione tecnica, ma per discussione semipolitica.Allora ho detto "sai che ci sta, evitiamo, dimostro prima che fattibile e poi, quando c'è la fattibilità tecnica, vediamo se è una buona idea.Se c'è una resistenza o se perlomeno riesco a proporlo come parser alternativo, magari si lascia l'LCTTP ma si dà alternativa all'utente e così via.Però questa cosa ha un costo alto perché ci sono sei mesi che ti sei fatto un mazzo tale per… Sì, sì.Allora il punto è non per fare la paracullata della serata, ho Nier Forma che me lo permette.Da solo ci avrei messo tre anni perché il tempo che ci consente di lavoro ci potrebbe mettere due ore al giorno, ma lo moltiplichi per quattro, chiaramente.Nier Form me l'ha permesso, perché è anche parte del mio lavoro ufficiale essere innovativo su Nod.Il mio capo mi ha detto "vai a mille su questo progetto perché è un azzardo, se va a un buon fine ci sono vari ritorni per Nod, per Nier Form e per chi altro".ne ho approfittato.In realtà quello che sta succedendo può essere interpretato come un'apertura, può essere interpretato come una democratizzazione delle contribuzioni verso Node, che la parte JavaScript è fattibile, chiunque si mette in post, lo studia, capisce un po' di cose, perché ci sono un po' di cose diverse.Non è il JavaScript che vi aspettate, ve l'ho già detto in un'altra puntata, però sì, è vero.Però, diciamo, raggiungere la parte C++ io ho provato a darci un'occhiata e in realtà non era cosa.Per me almeno.Non anche per me, è un bagno di sangue.Quando ci ho messo mano l'ultima volta è stato un bagno di sangue.Nella mia idea, insomma, io ho un po' l'idea che mi sono fatto di rasta, insomma, da qualche metà a questa parte che sta diventando il linguaggio companion per quando ti serve della roba performante.Ad esempio, secondo me, un grosso messaggio, io l'ho visto quando Bundler, che è il package manager di Ruby, offre la possibilità di creare una nuova gemma con l'estensione Rust già fatta, con i binding già fatti, con il progetto Rust già impostato per poter chiamare da Ruby quel pezzo di Rust che tu scrivi, automatizzando e riducendo completamente la frizione di dove si scriverà.Chi ha fatto i sensori nativi in Ruby in C sa che sto parlando un bagno di sangue.Farlo in Rust si tratta di fare GemNew - - ExtRust, cioè nel senso l'ho fatto due giorni fa ed è qualcosa di rivoluzionale, secondo me.E sto vedendo questa cosa in tantissimi ecosistemi, che è qualcosa, ad esempio, che non ho visto con Go.Se penso a cinque anni fa che si diceva "riscriviamoli in Go perché Go risons", non sto vedendo la stessa cosa con Rust.Anzi, più che riscrivere un Rust come meme è "facciamo parte che ci serve che deve essere in un certo modo con Rust e la integriamo in quello che già c'è.Adesso io sto vedendo questa cosa.E' proprio, in realtà se ti dico per pura coincidenza, stamattina lavoravo un minuto, ho fatto un fix sulla...allora il generatore del mio sito internet è un generatore di di siti strategici che mi sono scritto io, non fate domande, mi sono scritto un generatore, ho scritto il similjack, il similjugo, per cose molto basic, però ha tante belle feature, tra cui l'atomic CSS, compressione delle classi, tante cose simpatiche.Tra le varie cose che mi servivano per scrivere correttamente il service worker, dovevo estrarre da ogni pagina HTML generata tutte le immagini che avevo renderizzato.Tenete conto che quel sito è renderizzato in JSX, in React in pratica.React si fa per JSX, perché è un lato server.Ora, in JavaScript ci metteva due secondi, d'accordo? Per ogni compilazione, solo per estrarre, solo la fase di estrazione delle immagini, cioè fare il parsing HTML, cercare tutti i tag IMG ed estrarre l'attributo src.Allora, ma fammi vedere per curiosità vediamo se c'è un parser HTML in Rust veloce già scritto ho trovato un parser che si chiama scraper che fa esattamente quello mi consente di selezionare i tag tramite selettore CSS quindi fai fragment.select.img come l'ho integrato nella mia gemma javascript ho fatto una mini una mini lib dentro il mio codice sorgente compila un web assembly e include il modulo web assembly dentro la compilazione totale tempo di compilazione passato da più di due secondi a 500 millisecondi se vado ad avere stato adesso su github vi sfido a farlo su shogunpanda/dante c'è una folder dove c'è nella lib folder c'è quella gemma sono letteralmente qualcosa come 10 righe di codice Rust.Complessità? Ci ho messo qualcosa come 20 minuti a farlo.È vero che ho scopiazzato la configurazione da Milo perché l'avevo già fatto, però in generale non ne sarebbe tanto più complicato.Io in 20 minuti ho tolto un secondo e mezzo, ho tolto quasi il 75% di tempo in un task.Perché? Perché Rust e WebAssembly con JavaScript ci vanno da Dio in determinate situazioni.C'è poco che fa.io stavo facendo, devo fare una cosa simile, l'ho iniziata a determinare per la creazione della waveform di un file mp3.Per esempio? Perché in javascript tipo, cioè lo metti, fai a prendere, per la puntata di un'ora e mezza, un'ora e quaranta, lo metti, vai a prendere il caffè, ti bevi il caffè, torni e forse ha finito.Provaci così, il web assemblibile.No, no, la stessa cosa in Rust liscio ci mette pochi secondi adesso devo capire come farlo con WebAssembly per non portarmi dentro a fare un eseguibile direttamente con Rust e se non faccio? C'è un tool che si chiama WasmPack che è responsabile di generare quel layer di compatibilità JavaScript e a quel punto tu includi il modulo JavaScript come se facessi un import qualunque e chiami la funzione non ti fa nient'altro cioè è davvero così semplice è impressionante.Riconduco nel paese dei balocchi.Ah il paese dei balocchi.E' arrivato il momento tipico e topico del nostro podcast il momento del paese dei balocchi momento in cui i nostri host e i nostri guest condividono con noi un tool un libro qualunque cosa insomma abbia catturato la loro attenzione e che si pensi sia utile condividere con la nostra community.Quindi la mia domanda innanzitutto a Paolo è hai qualcosa da condividere con noi? Yes ma non quello che vi aspettate, vi stupirò.Allora faccio una piccola premessa, sul libro vino è stato condiviso in un episodio passato di Gitbar, sì però banale, ho detto "facciamo qualcosa di estremamente diverso, ovvero voglio solo aprire una filosofia di pensiero".L'ultima volta ho condiviso il Gaviscon, se ricordate bene, quindi stavolta andiamo a qualcosa di un attimino più sostanzioso, ma più a lungo periodo.Ovvero, dopo tanti tanti anni di esperienza, mi sono ritrovato a notare che nella programmazione ogni giorno, nelle cose che faccio, utilizzo anche cose che non dovrebbero centrare in niente, anche indirettamente.Quindi vi consiglio oggi, come Paese dei Ballocchi, iniziate a praticare un'arte marziale qualunque.Sceglietemela voi.Io sono un praticante di Wing Chun da diversi diversi anni e mi sono accorto che i principi cardinali del Wing Chun li uso nella programmazione tutti i giorni, stranamente.Non vi dico quali perché ci farò un talk breve, ho già intenzione di trasformare in un talk perché mi sono accorto giorno dopo giorno che questi principi li uso.Quindi qual è mio palocco.Fate qualcosa, qualunque cosa, un'arte marziale ma anche qualcos'altro, che abbia un risvolto filosofico dentro e che ve lo portate, coscientemente o meno, nella programmazione di tutti i giorni e ve la rende uno spettacolo.Sono out of the box, vero? LL - Sì, mi hai spiazzato a questo punto, mi avrebbe da chiederti.Anche lo yoga può centrarci in qualche modo.voglia, la voglia.Perché stavo pensando a una cosa che anche io ho preso molto dallo yoga, l'unica cosa che non riesco a capire è perché il mio saluto al sole della mattina inizia con quattro bestemmie, quindi devo capire...Lo cali nel contesto, scusami.Ragazzo, nella mia arte marziale dovrei essere morbido, tu mi hai visto quanto grosso sono, che morbido vuoi che sia io su? Quindi voglio dire, ti capisco, ci combatto ogni giorno, ti capisco, ti capisco.In realtà io ho una cosa molto più banale, ho due libri.Il primo è Rust for Rustacians, che è sostanzialmente un libro che vuole insegnare Rust a chi programma già.Quindi Diciamo, c'è l'introduzione, per capire se è un'introduzione al linguaggio, ai tipi, eccetera, ma non è quella cosa come il Rustbook o comunque come il libro di programmazione classica.Allora vediamo che c'è il numero, F, floating point, 64 bit, bla bla bla.No, è una cosa molto più hands-on e riprende concetti che sono già familiari a chi programma, quindi parti sostanzialmente dalla sintassi, alla gestione della memoria, a come si struttura un progetto RUST, alla concorrenza, a come utilizzare una libreria, a come fare una libreria.Vi consiglio, non fate il mio stesso errore, prendetelo cartaceo, perché come tutti i libri dell'anno starch press c'ha una qualità impressionante.Io l'ho preso come ebook, visto cartaceo e mi sono pentito di non averlo preso cartaceo.In realtà un altro libro che è sempre della Nostar Express, che però ho cartaceo ma uno di quegli scatoli che non potrei vedere, infatti volevo anche nascondere questo ma non ci sono riuscito, è Absolute FreeBSD, che non c'entra niente in questa puntata, però lo sto effettivamente leggendo perché ero curioso di provare FreeBSD.È un libro che vi spiega un po' l'amministrazione di sistema di tutti i giorni.Può essere una lettura interessante.Il 3 e il 4 febbraio del 1994 c'è il FOSDEM, se dovete prendere voli oppure alberghi affrettatevi perché i prezzi stanno salendo a vertigino.Devo dire che Carmini mi ha consigliato un albergo che io prestamente prenotato, quindi se andate a Bruxelles per il Fosdem sappiate che ci sarà la puntata pirata anche quest'anno, non so dove se troveremo un angolo nell'hackerspace o scassineremo un'aula nei piani inaccessibili come abbiamo fatto l'anno scorso ma faremo una puntata pirata che ha un po' quel flavor, anni primi anni 90 del "staccatutto ci stanno tracciando" quindi sarà un po' così.Io ho un ballocco, lo sto provando, quello che state vedendo è un po' quello.Questa è la prima puntata che è registrata con questo ballocco.Ho preso una nuova fotocamera, fotocamera che in questo momento mi sta...si è appena spenta, non so se avete sentito il rumore, perché si è surriscaldata, ok, non regge un episodio di Geekbar, va bene, però è parecchio figa, è la nuova Sony ZV-E10, una bella fotocamera, obiettivi intercambiabili, la sto provando, l'ho provata con The Motion, tanta roba, l'unico problema che in realtà registrare tutto un episodio di Geekbar in 4k non ce la fa farcela perché si surriscalda quindi va bene però è fica.Ehi ehi ehi prima di lasciarci vi devo ricordare che se volete aprire o gestire la partita IVA online eliminando gli ostacoli della burocrazia potete prenotare una consulenza fiscale gratuita e senza impegno con uno sperto di fisco zen dal link in descrizione avrete anche 50 euro sul primo anno d'abbonamento.Quindi grazie Fiscozel per aver supportato questo episodio.Detto questo io adesso che la puntata volge alla fine mi rilasso un attimino, abbassiamo le luci, abbassiamo i toni.Paolo cosa ti porti dietro da questa esperienza della scrittura di Milo? Ma chi ve l'ha fatto fa? No, scherzo, a parte il disfattismo.Tante cose, tante cose.Allora ho imparato tantissimo, anche la tenacia, perché non ero mai stato su un progetto per sei mesi di seguito, in solitaria per intenderci.Mi ha anche insegnato a non intestardirmi con l'implementazione, perché ho dovuto cambiare molti aspetti implementativi più e più volte, quindi reiterare, reiterare, reiterare, reiterare.E poi anche sulla questione politica del dire "a volte è meglio chiedere scusa che permesso".E infine, come al solito, cosa che nella mia esperienza di Master di gioco di ruolo dal tavolo e dal vivo, ho già visto che la gente crede che pensi in un modo e loro pensano completamente al contrario.E questo dovete lo porti anche quando devi fare interfaccia utente.Ho già i beta tester migliori della storia, c'è la mia famiglia che quando gli fai vedere una cosa, cliccano la cosa più assurda possibile e mi si è confermata anche nel feedback ricevuto al Collab Summit, quindi è una legge universale.Voglio farti una domanda molto personale.Yes.Anzi, due.Iniziamo da quella light, per poi passare a quella più core.Hai fatto sei mesi dove da solo hai riscritto qualcosa in Rust.Hai sentito l'esigenza di avere un buddy, una guida, qualcuno che lo conoscesse a bene ti potesse guidare? - Sì perché a volte lo scomporterà tanto, no perché avrebbe interferito con il processo creativo.Detta proprio così.Nel senso, se il buddy mi dice "guarda Alpano, non puoi fare questa cosa" magari non esploravo la via che stavo esplorando e magari non si era arrivato al risultato.quindi avevo la necessità di non essere limitato in nessun modo.So che siamo detto da psicopatico così però mi sembrava più un lato artistico che tecnico.Dovevo avere la completa autonomia per poter creare quello che mi diceva la testa quel giorno per esplorare e cercare di tirare fuori ogni minima possibilità da questo approccio.E in effetti credo di essere arrivato a destinazione dove volevo arrivare.Mi viene in mente un esempio.Chi di voi conosce Satisfaction di Benny Benassi? È un disco che ha quel bassone distorto.Ecco, quel bassone distorto è stato creato, quindi mera parte artistica, da un misuso del compressore.Nessun ingegnere del suono avrebbe mai utilizzato il compressore in quel modo e quel compressore diventa strumento artistico usato in quel modo.Adesso un po' quello che hai detto mi ha riportato alla mente proprio quel caso specifico.Il concetto specifico è quello, magari uno avrebbe detto "non potrebbe usare le macro in questa maniera" ma butto lì e quindi non avrei scritto il sistema in quella maniera.Altra domanda legata alla precedente ma ancora più personale è tu non conoscevi Rasta, ti sei seduto, hai scritto tutto, sei andato, l'hai pubblicato su github e sei salito sul patibolo mostrandoti a una community che non ha paura di essere brutale nel giudizio perché lo sappiamo noi siamo un mondo che è brutale spesso nel giudizio, vedasi l'ultima presentazione di Vercel.Come ti sei sentito nell'essere giudicato in qualcosa che hai creato che ti ha preso sei mesi e che però eri consapevole del fatto di non essere master in quello.Cioè...Allora, ho tre considerazioni da fare.La prima che ti ucciderà...Socrate.Non me la posso prendere perché so di non sapere, quindi non so un cavolo.Grazie che se mi debono deboliscono.Anzi, se non mi deboliscono c'è qualcosa che non va perché realisticamente non ci posso aver colto la prima botta, devo aver sbagliato qualcosa.Ma non è falsa modessa, non è nemmeno un problema dell'impostore, è certezza.Non conosco Rust sicuro ho sgarrato qualcosa.Quindi quella è la prima.La seconda è che ho ricevuto praticamente nessun feedback.L'unica persona che mi ha dato un feedback sul codice in maniera estensiva, a parte perché ve lo siete guardati e parlo tra i collaboratori di Node, è stato Yagizni Zip, non riesco mai a pronunciare il suono, comunque Yagiz, a non righe per intenderci, che è una delle persone più gentili che io conosco.Quindi mi ha dato un feedback tranquillissimi, banalmente, quindi proprio una esperienza magnifica.Troppo brutte persone, non lo trovate.Finora.Perché dici purtroppo? Eri preparato al peggio? No, perché sarei corso anche di vedere come reagisco.Non mi è mai capitato.Neanche su me stesso.Come reagirei? A questo punto ti faccio un'altra domanda.Perché non è successo in Milo, ma probabilmente ti sarà capitato in altre situazioni.Tu hai scritto del codice? Il codice talvolta se non è il crudino della chiesa e se ha una certa complessità rappresenta in qualche modo il modo in cui pensiamo quindi rappresenta noi stessi.Quindi diventa noi stessi che è un problema enorme.Nel momento del giudizio, sia un giudizio verso noi stessi, anche se non dovrebbe esserlo, noi lo percepiamo verso noi stessi.Come ti difendi da questo giudizio verso te stesso? Cioè come scendi il codice alla parte personale? È proprio quello, in realtà, mantenere sul lato oggettivo.Cercare di mantenere sul lato oggettivo, oggettivo rimbalzare la gente quando va sul lato personale, perché uno non mi conoscono, quindi come puoi entrare sul lato personale? Che mi puoi offendere al massimo che mi dici che sono ciccione, sti grancazzi, so di essere ciccione, anche se sto dimagrendo, ma questa è una divagazione.Cerco di scendere la cosa, tengo le cose separate, mi vuoi attaccare sul lato tecnico? Assolutamente sì, anche perché sul lato tecnico è grossomodo oggettivo, comunque posso difendermi, posso fare dire sul lato personale, come si direbbe a Roma, ti rimbalzo, cioè ti devo lasciar perdere il più possibile.Quando quella cosa oltre, devo riportare l'utente, robe del genere, insomma in generale.No no ma quello che intendevo io è che poi non è un attacco, quando c'è un inizio sul codice e tu sei in quella fase dove il codice ti rappresenta, che ci hai messo così tanto di te, così tanto che chi ti giudica lo sta facendo in modo oggettivo, ma tu perché capita a tutti, la percepisci in modo personale perché è una parte di te quel pezzo di codice.Come fai a staccarti dal codice? Non c'è una ricetta.No, allora io ho avuto un po' di interazioni sgradevoli su Node, su quel fatto che dicevo sul network family autoselection.Ho faticato, però a parto è stata la buona beata regola del "conta prima di reagire perché finisce schifo", altrimenti.Quindi conta, conta, conta, poi reagisci con calma.Tant'è che qualcuno che mi attaccava in maniera poco oggettiva l'ho controattaccato in maniera oggettiva e non si sono più fatti sentire.Cioè, uno mi diceva "eh, però stai in alimentazione, sobbotti male, fa cacare, bugata, quel che è"."Fatto, ma bufa, ma avrei detto come l'avresti fatto".Mai più visti.A un certo punto ti metti a livello di 4 anni, probabilmente mia figlia riuscirebbe a discuterci meglio questa persona, e tu all'invece hai 4 anni e dici "sai che ci sta, se tu sei così bravo fammi vedere almeno dove..." gli ho detto "in maniera politically correct dammi un'indicazione di quello che dovresti cambiato per far risultare meglio questo codice" sono spariti magicamente.Magia.La magia del workload si chiama."Se tu sei così bravo, se no va a te, non scassare di la gentile".Poi ti dico anche una chicca che non ho detto prima, perché il talk che ho fatto in quello spiego non lo puoi aver visto tu, è successo a un'ottobre che stavo in Belgio.Ultimamente ho preso l'abitudine di dettare ai miei software tutti i nomi dei miei precedenti ottuali animali domestici.Per intenderci, per esempio Dante che ho citato prima era un vecchio cresceto, il sistema che uso per le slide si chiama Freya che era una mia vecchia gattina.Milo prende il nome dal primo scoiattolo che aveva mia moglie.Quindi c'è anche un tocco di personalità in più."Cazzo, tu mi stai offendendo lo scoiattolo? Oddio, dalla sfatica, allora, cittui!" E quindi in quel caso il carico personale che tu dici è scendere dal "guarda, è un software, non è più quello scoiattolo che non c'è più", non ti viene però.Diciamo così, non ti viene.Allora, è difficile, però la tecnica del contare, mi rispondono su GitHub, anche...guarda un buon consiglio ti scrivono su github è asincrono nessuno ti obbliga a rispondere dopo quattro secondi leggi il messaggio vada a fare una passeggiata pensi torni rispondi tutto qua c'è poco da fa bisogna essere per citare il tuo sponsor un po zen io talvolta agosto pure quindi non c'è altro modo ma non c'è altro modo perché diventa difficile.Assolutamente sì, però è un elemento importante.Quello di cui hai parlato oggi, il fatto di buttarsi in qualcosa di nuovo e non aver paura di essere giudicato, perdonami, devo dirlo, è una piccola lezione di vita.Io questa cosa la conoscevo e quando a inizio puntato detto che sei un esempio, un mentore, questo è uno degli elementi per cui sei un esempio e per cui ti ringrazio Paolo.- Io ringrazio voi perché a me mi fa strano, sindrome dell'impostore a palate.- Io ho scritto nel gruppo privato degli host di Hitler, puoi confermarlo Mauro, dopo mezz'ora con Paolo, io non è che mi sento impostore di più, mi sento proprio...voglio andare a scavare le buche, tipo qualcosa del genere.No ragazzi, ma sono un cialtrone, siete troppo buoni, lasciate, fate il cavi.Alla, che tu sia un mentor, sia un esempio, è vero.Che tu sia un cialtrone posso confermare, è vero anche quello.No, non esco sull'alto, ragazzi, assolutamente.Ma io vi voglio tutti dentro, che me frega, mi porto a casa tutto.No, scherzi a parte.Allora, il sindrome dell'impostore a palate si inizia da lì così.Allora io ti dico ragazzi, dopo un anno che faccio conferenze, la gente mi dice "Ma ti conoscevo già!" Ma a me è strano, non mi riesco ad abituare.La gente mi inizia a conoscere per davvero, nonostante io faccia pure cagare sui social.Cioè, tu lo sai, scherzo molto, sono l'unico DX che fa veramente cagare sui social.E la gente dice "Ma io ti seguo!" E io penso "Che cazzo segui? Non posso niente sui social, vabbè, be' da te!" Cioè, mi fa sempre...Ma non è falsapotenzia, per rendermi sento...è vero è vero.Triste guarda, triste triste.Ragazzi un'ora e 45 minuti sono sono tanti quindi vi ricordo rapidamente che potete supportarci direttamente al nostro sito c'è il link supportaci quindi se vi fa piacere potete aiutarci a sostenere le spese.Gruppo Telegram...scusa Carmine, dovevi dirlo tu? Potete ritrovarsi sul nostro gruppo Telegram "Cercando Gitbar" nel vostro client Telegram preferito.Il gruppo si chiama "Gitbar" e non "Gitbar Italia" e io ti fermo qua perché...C'è l'emulatore! Ti spiegheremo in post-trasmissione! Sì, sono curioso! Per noi siamo molto politically correct da questo punto di vista.Per tenere questo livello di politica linguale.Sì sì però non te ne vai a domicilio fino a che lo spieghi.Abbiamo anche il canale youtube e dai e iscrivetevi che è così piccolo così giovane ha bisogno del vostro supporto quindi se non l'avete ancora fatto aprite youtube vedete i nostri bei faccioni tra l'altro tra l'altro posteremo anche un po di contenuti nuovi e freschi di lì per cui iscrivetevi e cliccate sul campanaccio se non l'avete ancora fatto.Sapete che il nostro canale youtube di Gitbar ha il campanaccio al posto della campanella e già quello potrebbe essere un motivo per iscriversi.Detto questo io vi do appuntamento alla prossima settimana ringraziando ancora Paolo e Carmine.Grazie a voi è stato un piacere.Ci vediamo.Ciao ciao.Ciao ciao ciao Ciao! *grosso bacio* Spagna vont'è venire a ristringersi! Basta si fa le cose tuoi e loro