Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Un'altra settimana è andata e oggi ahimè sono solo.Sono solo e sto provando questa nuova jingle machine che mi sta già sul culo.Volumi troppo alti che non riesco a configurare velocemente quindi penso che la elimineremo, anzi questa musichetta mi sta già dando ai nervi ma prima di partire con la puntata vi anticipo che sarà una puntata fighissima vi devo ricordare i nostri contatti info@gitbar.it o @brainrepo su twitter sono i modi classici per contattarci poi c'è anche il nostro gruppo telegram, gruppo telegram che ha sfondato da poco il numero di mille partecipanti quindi stiamo crescendo e sono super felice di questo e mi raccomando se non vi siete già iscritti iscrivetevi perché troverete delle discussioni interessanti anche dei personaggi interessanti.Detto questo a questo punto quindi possiamo iniziare benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.La community JavaScript ha subito uno scossone in questi ultimi periodi.Infatti l'arrivo di BAN come nuovo runtime ha un po' scosso le acque e Twitter si è un po' incendiata sulla questione delle performance.Io, un po' cercando, un po' spulciando, sono andato a vedere come funzionava BAN e ho visto che sotto il cofano, in realtà, è scritto in un linguaggio che non avevo mai incrociato nella mia enorme ignoranza.il nome del linguaggio è Zig e per fare luce su questa tematica a me ignota ho invitato un super ninja abbiamo con noi Loris Crow VP of Community per la Zig Software Foundation podcaster, youtuber, ma anche curatore di una conferenza, no? Ciao Loris! Ciao Mauro, grazie per avermi invitato.Sono super felice di averti qua, devo però dare onore al merito.Il tuo nome è stato fatto da Salvatore Sanfilippo che parlava proprio della tua conferenza nel nostro gruppo Telegram.Quindi ti chiedo subito che cos'è questa conferenza.Dacci più informazioni.Sì, volentieri.Allora, la conferenza si chiama Software you can love.È una conferenza che...allora, il titolo che metto sotto, la scritta che metto sotto il titolo è in inglese.La conferenza ospiti speaker in inglese è principalmente tutta in inglese anche se è tenuta a Milano e quello che scrivo sotto è "a conference dedicated to celebrating the art of making software for humans".L'idea è che quando crei del software, il tuo software è un'esperienza per gli altri esseri umani, il fine finale di tutto il software che esiste sul pianeta terra alla fine è per l'utilità delle persone o quanto meno dovrebbe.E questo è il tema principale della conferenza.La conferenza anche di proposito non si propone come una conferenza open source perché io lavoro da ormai qualche anno nell'open source, ho iniziato lavorando a Redis Labs, che è dove ho conosciuto Salvatore.E sostanzialmente, anche se non do colpa alle persone che si avvicinano all'idea del mondo open source vedendolo come una cosa interamente positiva, sai, lavorandoci dentro ho iniziato a vedere un po' le crepe, le cose che non mi piacciono, le cose che ritengo stiano venendo un po' abusate, idee belle che forse erano parte dell'open source che ad oggi stanno venendo un po' riutilizzate per portare avanti idee che non sono proprio a favore dell'utente finale e quindi se vogliamo un po' una conferenza di protesto però non lo dico chiaramente.Allora Loris ti posso dire che sei nel posto giusto nel senso che mentre parlavi di questa cosa se vi dovessi passare un'immagine del tipo che sventolavi l'osso io cane pavlovico affamato sbavavo perché in realtà sulla parte dell'imprinting etico e politico nel senso più alto del termine no? Gitbar è sempre molto molto attenta.Allora ma la mia domanda è cosa vedi che sta cambiando ormai mi hai provocato quindi io la domanda te la devo fare cosa vedi che sta cambiando nel mondo open source che sta facendo in modo che ci si prenda questa piega un po' poco poco...come ti posso dire...poco etica, poco buona, poco umana o umanocentrica Beh io posso magari fare un paio di esempi di cose di cui ho letto di recente e cose che appengono più o meno nella, se vogliamo, nella mia sfera, non nella mia sfera, però lo spazio in cui opero io.Dunque, credo che a livello di base il problema principale è che ad oggi ci sono dei tipi di prodotti che tu non puoi realizzare se non in versione open source, a lato pratico.Nel senso, metti che tu domani vuoi creare un nuovo linguaggio di programmazione, tu aziendona, quindi se parli di un'azienda big tech, sei la Microsoft, e vuoi creare un nuovo linguaggio di programmazione, di fatto in pratica deve essere open source.Se non è open source, è difficile convincere le persone ad utilizzarlo, ad oggi.Magari una volta era diverso, ma ad oggi, linguaggi di programmazione, database, altro tooling di questo genere, framework, che vengono usati molto, sono tutti open source.C# una volta non era open source, adesso è diventato completamente open source, ha addirittura la sua fondazione.Quindi da un lato c'è questo problema dove aziende big tech che magari non hanno mai neanche veramente apprezzato open source.Microsoft è un esempio che ha una storia di non amare l'open source o il free software e tutto questo mondo qua, però ci si devono interfacciare, non possono più farne a meno, è già da un po' che è così.E dal mio punto di vista nel tempo hanno imparato sostanzialmente a prendere quelle che erano le idee dell'open source e piegarle il giusto quanto che serve ad assicurarsi che riescono fare quello che vogliono fare e non è tutto male però insomma quello che succede è che un po' a mio avviso va a denaturare certi aspetti di collaborazione spontanea tra le persone a seguito di queste cose che fanno.Da un lato, dall'altro c'è anche il problema secondo me che un po' noi glielo stiamo lasciando fare, ovviamente nessuno di noi individualmente si mette in piedi e fa "you shall not pass" alla macchina di marketing della Microsoft.Non puoi.Microsoft loves open source, sai il cuoricino, no? E tutti hanno lo sticker e non puoi andare a stafare lo sticker alla gente.Quindi c'è anche quell'aspetto lì.È complicato.Io ti posso dire che non è solo una questione di combattere contro, non l'erosione di un ideale che non esiste più, ma a essere attenti a queste cose qua, ce ne è da guadagnare se sei nella posizione giusta.Per fare un esempio, Zig è un progetto completamente indipendente, è un linguaggio di programmazione, viviamo completamente di donazioni da parte di utenti di Zig, aziende che usano Zig, quindi sono sia individui che aziende, non siamo anti business, però siamo sempre stati molto attenti a rimanere indipendenti.La Zixofre Foundation non ha aziende di Big Tech nella sua board of directors e funziona, funziona, si può fare, non funziona per tutto, chiaramente non posso promettere a nessuno domani fai un tool open source e automaticamente sei in grado di renderlo sostenibile e indipendente, però è possibile.La curiosità è questa però, pensi che siano sistemi, approcci alla Microsoft che rendono spuri o fanno perdere quell'aura di approccio collaborativo al mondo dell'open source o sia in qualche modo il mondo dell'open source che in alcuni ambiti non riuscirebbe a essere sostenibile.Tu hai detto noi di Zig ci autososteniamo, ok, ma quel modello è replicabile in tutte le realtà quindi la mia domanda di base è quanto è colpa di Microsoft tra virgolette Microsoft Facebook delle big tech in generale e quanto invece è in qualche modo responsabilità delle community open source anche quelle più radicali che si stanno un po' impigrendo Io credo che la risposta sia entrambe le cose.Non credo che...credo che la colpa è di tutti.Ti posso fare un paio di esempi concreti.Allora, un esempio di compagnie big tech che fanno cose che non dovrebbero fare.E, guarda, ne ho una valangata di questi esempi e ne tiro fuori solo uno abbastanza esemplare su questo esempio.La Microsoft, ho detto prima, ha reso C# open source.E c'è la .NET Foundation, quindi credo che non sia solo C#.Io continuo a dire C#, però in realtà è tutto l'ecosistema .NET che è stato reso open source.Dunque, questi hanno la fondazione.Idealmente una fondazione dovrebbe...lo scopo, la ragione di esistenza della fondazione non-profit profit collegata a un progetto open source dovrebbe essere sostenere il progetto open source, far crescere la comunità, rendere tutto l'ecosistema produttivo.Un po' di tempo fa c'è stato un blog post messo da una persona che è stata eletta nella board dei direttori della Dotnet Foundation dove si lamentava che sostanzialmente lui pensava che a essere eletti nella board of directors ci sarebbe stata un po' di cose da fare attivamente per restazionere la fondazione, non è stato così, alla fine si è dimesso e vabbè è finita lì, questo era giusto un blog post.Ma nello stesso periodo è successo anche che praticamente si è scoperto che quando un progetto veniva preso sotto l'ala della .NET Foundation, quindi immagino che tu fai una libreria che diventa abbastanza popolare nel mondo .NET, potrebbe essere qualunque cosa, non lo so, un parser JSON, una cosa a caso, però è abbastanza per persone che lo usano, va mantenuto, diventa una di quelle cose dove, ok, la fondazione dice "ti prendiamo sotto la nostra ala e ti diamo, sai, un po' di risorse per portare avanti il progetto" e magari anche solo una cavolata come server per continuous integration, niente di che, però lo fanno.Per fare questo ti fanno firmare un contratto dove accetti di portare i repository del tuo progetto sotto la loro organizzazione di GitHub.E questo, vabbè, lo firmi, hai accettato di farlo, ma qui arriva la parte più interessante.Loro, siccome controllano GitHub, e questo è successo, non sto facendo cospirazione, questi sono fatti che puoi andare a leggere su internet, a un progetto hanno sostanzialmente preso, dal momento in cui questi hanno firmato, li hanno preso i repository e gliel'hanno spostato, cioè non gli hanno mandato una richiesta, perché loro hanno accesso da admin, quindi gliel'hanno spostato e poi a un certo punto l'executive director, la ministratrice delegata della DotWay Foundation ha mandato una pull request al progetto e se l'è mergiata da sola, ma lei non aveva accesso di scrittura repository, altrimenti non avrebbe mandato la PR, avrebbe semplicemente commentato.Come ha fatto? Perché in quell'organizzazione lei aveva un account con i privilegi abbastanza alti quindi poteva sostanzialmente, aveva implicitamente diritto di scrittura su tutti i repository lì dentro.Sembra magari una cavolata però questi sono il genere di cose che chiaramente dà un fastidio a chi fa open source perché è il tuo progetto.A me fa già strano che questi ti chiedono di metterlo sotto la loro associazione però sotto l'organizzazione di GitHub però poi quando arriva la gente a cui non hai dato diritto di scrittura che prendi ci scrive dentro ancora un po' peggio.Questo è per dirne una.Le compagnie di software, quelle grosse, non sempre è ben chiaro cos'è l'open source e rispettare tutti i canoni dell'open source, quindi a volte fanno un po' quello che devono.Dall'altro lato, dal lato dei progetti open source che forse non fanno tutto quello che dovrebbero fare, mamma mia.Io ho un esempio, scoperto questa cosa sono rimasto esterrefatto.Gimp, hai mai usato Gimp? Ah non riuscivo a smuntarmi scusami, sì l'ho usato.Ok, la adori l'interfaccia di Gimp.No mi fa cagare.Ok, ok preparati però, io sono abbastanza d'accordo ma immagina se Gimp fosse sempre stato fatto 100% a gratis o meglio fino ad agosto dell'anno scorso, nessuno dei core contributors è mai stato pagato una lira.Benché il progetto accettasse donazioni.Ma non avevano mai fatto il lavoro di creare la loro fondazione, si erano affibbiati alla GNOME Foundation e, stando a quello che c'era scritto sul loro sito, tutte le donazioni che venivano fatte per il progetto di GIMP tramite la GNOME Foundation potevano solo essere utilizzati per organizzare eventi e comprare nuovi hardware.Quindi immagino che i maintainer di Gimp potessero usare questi soldi per avere, non lo so, l'ultimo portatile, il miglior portatile che potevano volere, però non potevano venire pagati per fare il lavoro.Quindi Gimp è sotto...una volta che vedi questo, è un miracolo! Perché non sono mai stati pagati.Sì è allucinante.Io credo che però, come dici tu, la buona parte di responsabilità sta alla comunità che c'è cascata come un pirla.Premesso che io utilizzo diversi prodotti Microsoft più o meno open source, uno di questi che utilizzo tutti i giorni è TypeScript adoro.Posso dire una cosa, gli ascoltatori di Gitbar già lo sanno, però oggi voglio essere ancora più esplicito, ma perché hai aperto la tematica tu puoi, promesso, passiamo a Zig, se no sarei capace di rimanere tutta la sera su questo topic.Allora, qualche tempo fa mi ero preso bene da tutta la parte del fai diverso no? sono andato a esplorare un po' quel mondo e ho detto vabbè noi siamo sviluppatori ok? noi usiamo git noi usiamo github ma perché le ishu e le pur request non sono decentralizzate.Come posso farle? Utilizzando il concetto di fediverso e di federazione no? E di lì sono andato a guardare un po' di cose e poi mi son fermato e ho detto "ma cazzo, git in quanto concetto è decentralizzato no? Di per sé è decentralizzato.Perchè? Apro una parentesi e la chiudo subito.Quando noi scriviamo software open source noi stiamo creando conoscenza, ok? La conoscenza però non è solo il codice.Una parte altrettanto importante della conoscenza che stiamo generando, che fa parte della comunità, sono le issue e le pull request ma perché se git è uno strumento decentralizzato noi utilizziamo software come bitbucket come gitlab come github come azur devops che centralizzano questo concetto ma allora cosa ci proibisce di utilizzare i concetti core di git per costruire delle dinamiche di pull request e di issue veramente decentralizzate.Devo dire che avevo anche fatto qualche esperimento no? Cacchio mi sembrava che si potesse fare utilizzando il plumbing di git no? Quindi le funzioni più a basso livello di git.A questo punto ho preso un po' di boss dei grandi progetti open source no? Di maintainer dei grandi progetti open source e gli ho fatto questa domanda e ho detto ma scusa tu fai open source quindi stai generando conoscenza collettiva che appartiene alla collettività perché stai mettendo tutta la tua conoscenza in un punto? E la risposta che mi dicono è sì vabbè ma Git è decentralizzato quindi domani se Microsoft mi taglia i rubinetti o se atlassian mi taglia i rubinetti o se github mi taglia i rubinetti o lo sposto da un'altra parte vero però tutta la conoscenza delle ishu delle pull request e quella la trasferisco sì vabbè ma se ti taglia i rubinetti da un momento all'altro come è successo a me con un repository che mi è stato bloccato come fai? Quella conoscenza è persa.Perché questo problema dal mio punto di vista? La causa di questo problema secondo me è che ci siamo concentrati sempre più sui prodotti e sempre meno sui protocolli.Quindi ci siamo concentrati sempre di più su concetti meno politici, possiamo dirlo, e abbiamo perso un po' quella militanza.Perdendo la militanza la cosa si è esasperata probabilmente, arrivando a farci perdere quella che è anche la consapevolezza.Sì, mi torna, credo anch'io.C'è anche da dire forse...forse anche qui è una questione che da un lato nostro noi lasciamo fare e dall'altro lato fanno.Ho parlato prima di Big Tech però perché GitHub è così? Perché GitLab è così? Perché son startup han preso investimenti e il protocollo non ti permette di catturare valore, non ti permette di tornare l'investimento moltiplicato al venture capital che ti ha finanziato.Effettivamente tutte queste piattaforme hanno interesse a differenziarsi, a venderti i servizi a pagamento, a centralizzarsi, a diventare grossi e poi costruire il fossato, che è un po' come definiscono in generale il playbook da startup.E questo ovviamente viene a discapito di qualsiasi forma di protocollo ogni volta che puoi sviarti dalla cosa.Tra l'altro, magari mi ricordo male io, ma mi pare che c'era una storia dove GitLab e GitHub sono forse le ultime compagnie che possono mettere Git nel nome nel creare un prodotto a pagamento dedicato a Git, perché mi pare che le guideline del trademark di Git ad oggi non permettano a terze parti di creare prodotti con git nel nome ma essendo gitlab e github preesistenti prima di queste guideline sostanzialmente gli è stato dato un nasce a passare quindi hanno anche parlando di fossato hanno anche il fossato del nome e è un'altra cosa che trovo interessante.Guarda secondo me il vero problema è che la nostra industria è cresciuta più veloce della sedimentazione dei nostri i nostri valori politici.E ci sta non botto di soldi perché un altro dei problemi è quello fondamentalmente.Sicuramente.Comunque adesso dopo aver fatto insomma mi sento un po' sessantottino dopo quello che ho detto però in realtà è importante quello il fatto di fermarsi un attimo e provare a riflettere.Io cerco di essere più moderato possibile non dico che Microsoft e Google e Facebook sono diavoli a tutti i costi, però secondo me la vera responsabilità è la nostra, che dobbiamo saper discernere e capire cosa sta succedendo, specialmente se siamo dei maintainer.Passiamo per un attimo a Zig, comunque questa cosa avremo modo di discuterla più a lungo anche di persona, ci conto.Oh, volentieri, guarda.Mi appassiona parecchio, mi appassiona veramente parecchio.Assolutamente.Domanda, Zig, come sei arrivato a Zig? Allora, come sono arrivato a Zig? Io ho studiato informatica qua a Milano.La mia specializzazione è bioinformatica, in teoria.Poi in realtà ho fatto la tesina dell'atriennale a tema, ma poi non ho mai fatto più nient'altro di bioinformatica.E in generale ho sempre fatto lavori di programmazione di "alto livello", quindi ho sempre usato Python, ho fatto un po' di lavoro di analisi di dati per dei centri di ricerca, quindi lì chiaramente Python all'epoca, Julia stava nascendo, quindi era proprio, Python era proprio il periodo migliore forse.Poi dopodiché sono passato a un'azienda di consulenza dove ho fatto servizi distribuiti web principalmente, Go, C#, Go mi è piaciuto, C# un po' meno, per il linguaggio, per l'ecosistema.In generale ho sempre avuto questo genere di esperienza, quindi non mi sono mai affacciato più di tanto alla programmazione di basso livello, perché la programmazione di basso livello ha il problema che ha una tonnellata di robe e stantie ovunque.C'è un cuore di cose che vale la pena sapere da informatico.Io mi vedo come ingegnere del software, che è quello che fanno tutti, però da italiano, non essendo un ingegnere, mi fa strano definirmi un ingegnere, quindi continuo a pensare a me stesso come un informatico.Però, allo stesso tempo, a voler smussare gli angoli, a voler avere una formazione veramente completa, la programmazione di basso livello è importante.Il problema, come dicevo, però, è che vuoi compilare un progetto in DC? Buona fortuna! Devi sapere tutte le magagne relative a DC, devi sapere tutte le magagne relative ad Autotools, Make, CMake, poi, oops, questo progetto ha per qualche motivo deciso che un header file DC viene creato da uno script Perl, perché queste cose esistono ovunque ed è sostanzialmente un incubo alla fine della fiera.Il mio problema non è che non volevo imparare le robe di basso livello ma che ho sempre ritenuto che il costo, la frizione nel farlo non valesse la fatica perché poi non ho mai avuto bisogno professionale di farlo.Chiaro e quindi dici quando ho incrociato per strada Zig, alla fine tutta questa complessità che vedevo un po' si è disappannata, ma allora la domanda è semplice, cosa porta Zig nel sistema programming? Sì, beh, porta principalmente semplificazione.Faccio un esempio, parlando sempre di problemi tragici degli ecosistemi di CEC++, perché non sono problemi strettamente del linguaggio.Magari il linguaggio potrebbe fare qualcosa di meglio, ma il problema è l'ecosistema che è nato 40 anni fa e poi certe cose sono migliorate, certe cose un po' no.Un altro esempio importante è la cross compilazione.Questo forse è una delle cose più interessanti di Zig, che sono interessanti prima ancora di iniziare a vedere una riga del linguaggio.Zig è un compilatore C e C++, ma più importantemente è un cross compilatore, quindi tu puoi prendere un progetto scritto in C e compilarlo da una macchina Linux x86 e creare un eseguibile per, non lo so, ARM Windows.Magari nessuno vuole usare ARM Windows, facciamo ARM Mac per un dei Mac nuovi che puoi fare.Questo è molto più realistico come esempio.E questo ha valore.Ha valore perché, beh ha valore di più ultimamente perché c'è un sacco di gente che sta iniziando a girare con i portatili ARM della Apple.Però ha valore anche perché ora non hai più bisogno di una macchina CI dedicata per ogni singola cosa.Se provi a fare questa cosa con...se io ti do GCC e un progetto e basta, ne devi fare di fatica prima di riuscire a ottenere una cross-compilazione che funziona, perché ti devi procurare la libreria C standard della macchina Target, perché devi mettere un sacco di impostazioni nel compilatore.Poi se in in mezzo c'è make o c-make è incredibilmente complesso.In Zig quello che fa Zig è azzeccare i default, semplificare un po' le impostazioni, ma soprattutto, questa è la cosa più importante, quando scarichi Zig, c'è un archivio di 40 megabyte, dentro ha tutte le versioni di Jlibc, quindi la libreria standard GNU, ha tutte le versioni di quella, così che puoi fare target di una versione specifica a Muscle, che è un'altra libreria di C importante, agli header della libreria C di MacOS, agli header della libreria C di Windows, a MinGW sostanzialmente.E quindi grazie a questo fatto, perché questa roba sennò te la dovresti procurare tu una alla volta, ogni volta che vuoi fare cross-compilazione, e tutto questo rende la cross compilazione genuinamente fattibile ad oggi.Tu mi hai detto che sei partito come sviluppatore Python, no? E che hai avuto comunque una parte di esperienza come web developer.Dal passare da sviluppatore che utilizza Python o web developer, a fare system programming e a utilizzare Zig, sono state le challenge e qual è stato poi il tuo percorso di crescita professionale per arrivare a utilizzarle in modo proficiency? Sì, c'è un po' di strada da fare, in realtà non è non è così terribile.Ad oggi ti posso dire che, te lo posso dire e non è non sto cercando di rivenderti l'idea, lo farei io me stesso senza dubbio, che scrivere ad esempio un sito web in un linguaggio come ZeeGo o un linguaggio di basso livello non è un'idea così terribile, non è così tanto peggio quanto farlo in Go e se il linguaggio ti piace di più, tutte le cose in più a cui devi pensare di un linguaggio di basso livello non sono terribili e anzi la singola volta che ti serve un controllo più preciso su una singola cosa, a quel punto lo puoi fare perché non ti viene nascosto dal linguaggio.Però per tornare alla questione del percorso, cosa devi imparare per affacciarti a un linguaggio di basso livello? Punto uno, la differenza tra stack e heap.Questa sulla carta non è difficile da capire, un esempio forse un po' comico della mia università qua a Milano, la Bicocca.Primo anno, primo corso di programmazione, introduzione, lo stack e lib e poi abbiamo iniziato a fare Java dove in Java non hai nessun controllo di cosa va dove, sono concetti che non tocchi e niente, quindi è rimasto lì un po' di filosofia del software e basta.Quando devi davvero capire cosa vuol dire quando una cosa può andare sullo stack o non può andare sullo stack un po' eroghioso.E' come quando un nio si sveglia per la prima volta fuori da matrix, ti fanno male dei muscoli perché non li hai mai utilizzati.Vero, verissimo.Guarda, io questo periodo sto studiando Rust perché...come hai fatto tu? Tra l'altro caschiamo a pennello perché fondamentalmente io sto iniziando questo tipo di esperienza.Pensa che iniziai con COBOL a scuola, PHP, JavaScript, passato a TypeScript e adesso sto provando a studiare nel tempo libero, bambina, permettendo Rust.Perché? Perché voglio spostarmi più a basso livello, perché il design di Data Intensive Application mi ha fatto venire la scimmia di capire come funzionano a basso livello i database, i sistemi di storage e quindi perché no provare a fare qualcosa io.È la volta buona che prima o poi ruotero un albero.E per la prima volta leggendo il libro di Rust ho detto "Ah vedi, alla fine da qualche parte torna lo stack e l'IP" e in realtà vederlo su Rust mi ha fatto capire alcune delle cose implicite di JavaScript.Noi non abbiamo il controllo, ma in realtà sotto il cofano sempre lo stack e l'heap abbiamo, no? E siccome hai parlato di stack e heap, voglio chiederti in realtà una delle cose, diciamo, che solitamente scatenano e infiammano il mondo dei system...dei linguaggi per l'assistent programming, come può essere Rust, C, ZIG, gestione della memoria.In realtà io studiando Rust sto facendo cazzuti col Borrow Checker, ok? Sicuramente tutte le persone del mondo che hanno sentito che hanno utilizzato Rust, i cazzotti col borrow checker all'inizio le fanno sempre.Come funziona il sistema della gestione della memoria di Zig? Dunque, Zig non ha un borrow checker, quindi Zig ti permette di fare un sacco di cose, alcune delle quali ti fanno crashare l'applicazione.Sotto quel punto di vista, diciamo così, quello che in generale viene consigliato di fare in Zig? Allora, sicuramente non avere il borrow checker non ti protegge contro certi tipi di errori di gestione della memoria che Rust, fin tanto che non apri blocchi unsafe, assolutamente, 100% ti proteggerebbe.Però, dall'altro lato, quello che in generale ci si aspetta è idiomatico in Zig è di non avere dei sistemi di gestione della memoria molto complicati, ma di fare delle cose generalmente semplici e di utilizzare cose come quelle che vengono chiamate allocatori, arena allocators, in italiano non so, non sono neanche sicuro di qual è la traduzione perfetta, però quello che fa un arena allocator è sostanzialmente dire, immagina che tu hai, torniamo a parlare dei siti web, tu stai creando un server web, Il tuo server web, a prescindere dal linguaggio che usi, ha sempre questo concetto dove ci sono n richieste che ti arrivano in parallelo che sono sostanzialmente completamente indipendenti.Quindi, non lo so, client A si connette e ti chiede una pagina, client B si connette e ti chiede un'altra pagina, magari entrambi ti richiedono di fare accesso al database, quindi magari ci sono dei punti di, se vogliamo, di risorse condivise, tipo una connessione a un database.però in generale le richieste tendono ad essere indipendenti e non solo.Una richiesta di solito non lascia rimasugli.Tu rispondi alla richiesta, ma quando hai finito di rispondere alla richiesta torni al punto, diciamo, di partenza dove nulla è cambiato all'interno dello stato del server o se cambia qualcosa, ha cambiato qualcosa nel database.Quindi, sotto questo punto di vista, ad esempio, se tu facessi un database, scusami, un server web in Zig, quello che faresti è che ad ogni handler, ad ogni request handler, passi un Arena Allocator.Quello che fa l'Arena Allocator è un concetto semplice e molto elegante.Semplicemente ti permette di allocare sull'IP tutto quello che vuoi e quando arrivi alla fine non devi fare free, non devi liberare ogni singolo oggetto.Quello che fai è resettare l'arena.E questo è molto performante.Faccio un esempio direttamente opposto di quello che è l'arena.Immagina quando chiudi Visual Studio e Visual Studio ci mette un quarto d'ora a chiudersi.Perché? Si sta chiudendo.Cosa sta facendo? Non ha niente di importante da fare.Però per come è programmato Visual Studio, Visual Studio tende a utilizzare un pattern R-A-I, il pattern con tutti i distruttori, dove alla chiusura ogni singolo oggetto vuole distruggere se stesso, pezzettino per pezzettino, tutto viene liberato e tutto si sgretola.Nell'arena non fai così, quando hai un arena allocator, quello che succede è che tutte le cose vengono "liberate in blocco" perché hanno, per dirla in termini di Rust, hanno lo stesso lifetime, vengono tutti messi nello stesso blocco di memoria, hanno tutti lo stesso lifetime, e quindi racchiudi tutto.In Zig questa cosa viene resa molto facile, perché in particolare ogni allocazione di memoria è 100% esplicita.non c'è un allocator globale implicito come in C e non ci sono feature del linguaggio che implicitamente allocano per Tech.E' un'altra cosa carina, perché faccio un esempio, se hai un sistema che è sempre sotto grossa pressione di memoria, in Zig puoi sempre, non capita, hai sempre l'opportunità di dire "prova ad allocare memoria, se funziona, bene, se non funziona, posso gestire questo errore".Ed è una cosa non banale quando si tratta di database o magari non lo so, di un editor di testo che non vuoi che crashi a caso.Facciamo un passo indietro perché forse siamo andati molto avanti.Buoni, un buon numero di linguaggi che utilizziamo, tra i quali c'è anche Go, usano un garbage collector che immaginiamolo come una donna delle pulizie che una volta che ne facciamo le nostre cose, come vede che diciamo non abbiamo più bisogno della camera da letto ci stiamo spostati in soggiorno, nella camera da letto abbiamo lasciato i cartoni delle pizze e le bottiglie di birra vuote, passa e ripulisce.Su Rust invece immaginiamo che ci sia questo cerimoniale per cui tu fai le cose con un metodo ben definito, sempre ben definito, che la donna delle pulizie si aspetta dove andare a ripulire.Immaginiamo così, no? Forse si merita anche...scusami, hai ragione, io sono decisamente saltato troppo avanti perché passo troppo tempo in questi ambienti.Forse si merita anche un'escrizione migliore, perché quello che fa Rust è veramente figo.Quello che fa Rust è...perché i garbage collectors te lo devono avere un costo, no? Ci mettono...la signora del pulizie ti chiede di uscire dalla stanza quando pulisce, tra virgolette.Invece in Rust questo non succede perché Rust sa dove liberare la memoria quando compila, cioè mentre compila sa qual è il punto giusto per liberare ogni singolo oggetto.Esatto, quindi immaginiamo che si ha della mondezza e delle confezioni di pizza che si autodistruggono dopo che sa, perché utilizzando una cerimonia sa che non servono più in un certo momento.Invece, dovendo usare un'analogia, ZIG è un po' come tu lo fai per te, quindi decidi spostarti in camera e di buttare poi il cartone, oppure di incendiare completamente la stanza e alla fine vuota con l'arina del locator.Sì, questa è decisamente una buona maniera per descriverlo.Voglio dire, ogni volta è come una stanza di hotel, no? Tipo, se il tuo web server è una stanza di hotel, scusami, il tuo web server è un hotel, ogni richiesta è una stanza di hotel, e sì, dai poco a tutto, e poi rimetti dentro tutta la roba nuova quando arriva una nuova richiesta.Esatto.Molto figa questo modo di rappresentare la gestione della memoria.Bello, bello, bello.Voglio chiederti, però, Tu arrivi da Python, cosa hai trovato passando da un linguaggio interpretato a un linguaggio compilato? Sicuramente ho iniziato ad apprezzare di più i tipi.I tipi aiutano.Diciamo così, io mi ricordo che avevo dei progetti che facevo mentre ero in università, studiavo e facevo insomma un po' di roba al fianco e all'epoca usavo Python o JavaScript.Se dovevo usare Django, che è fantastico, Python, altrimenti JavaScript per altre cose, Però nessuno di questi due linguaggi, quantomeno all'epoca, aveva l'opportunità di scrivere giù staticamente i tipi e io mi ricordo che mi è capitato più di una volta che raggiunte tipo le 10.000 righe iniziava difficile tenere controllo del progetto perché ogni volta che volevi fare un po' di refactor, un cambiamento, introducevi una tonnellata di errori di tipi e li potevi solo scoprire a runtime Quindi sicuramente i tipi aiutano quando il progetto è grosso e poi lavorativamente ho iniziato a lavorare a progetti molto più grossi, altro che 10.000 righe magari, e lì no tipi, no party.Sì, sai, una cosa che ho scoperto ed è il motivo per cui veramente quando lavoro in JavaScript utilizzo sempre e solo TypeScript, pur essendo un mondo virtuale che come aprilio sparisce tutto, perché TypeScript è quello, cioè un sistema di tipi finto perché poi alla fine non esiste.È una proiezione mentale del tuo io digitale come disse un nostro ospite all'interno del nostro podcast.Sai, quando sviluppiamo siamo spesso concentrati sul flow della nostra applicazione e poco sui dati che entrano e escono nella nostra applicazione.Avere un sistema di tipi ti aiuta a prestare attenzione anche a cosa entra e cosa esce dalla tua applicazione e quindi avere un controllo maggiore.Sai quante volte mi son trovato per esempio davanti a grandi code base javascript fatte magari con fastify dove vedevi queste funzioni ma dicevi "cribio questi oggetti che entrano che schema hanno? cosa sono?" e allora vai di console log per vedere cosa c'era dentro e questa cosa mi ha un po' cambiato la vita Una cosa che ho letto, stavo un po' dando un'occhiata a Zig in modo abbastanza superficiale, per cui corregimi se dico castronerie, ma una cosa che ho letto è che Zig tratta i tipi come fossero valori.Sto dicendo una cazzata? No, lo fa.Cosa vuol dire questa cosa? Trattare i tipi come valori vuol dire che tu puoi prendere una definizione di un tipo, una definizione di un abstract ad esempio, e passarla in giro come un parametro normale, come puoi fare anche in javascript, come puoi fare in python, come puoi fare in tutti i linguaggi di alto livello.La differenza, però fondamentale in Zig, è che puoi fare questa cosa solo in quello che noi chiamiamo comp time.Quindi sostanzialmente ci sono delle parti del tuo codice che possono essere completamente risolte, diciamo a comp time, ma nel processo di compilazione.Ad esempio Rust e C++ sono quelle cose che loro chiamano constexpr o termini simili.Per farci un esempio, se tu hai da qualche parte la tua beneamata funzione Fibonacci, che non mancare in nessuna codebase.Se da qualche parte tu scrivi, non so, che const foo=fibonacci di 5, la chiamata fibonacci di 5 non c'è motivo per il quale non possa essere risolta una volta sola, mentre compili, senza doverla ricalcolare ogni volta a runtime.E questo in generale è quello che fa Zig.Quello che Zig fa, che è più uno step oltre, è non Non solo cercare di risolvere, permetterti di risolvere tutte queste cose che sono risolubili mentre compili, ma anche allargare il linguaggio con delle semantiche che poi non esistono a runtime, perché a runtime, Zig non ha un runtime, non ha un...faccio un esempio, quando tu fai partire un programma JavaScript, c'è tutto il runtime di JavaScript dove ha informazioni di ogni tipo, sa ogni singola cosa, che cos'è.Invece, per contrasto, un programma scritto in C, quando tu compili un programma in C, tutta l'informazione dei tipi evapora dall'eseguibile finale.Un abstract in C sono dei byte con un offset.I primi due byte sono, non lo so, il primo membro dell'abstract, gli altri due byte sono il secondo membro dell'abstract o qualcosa del genere.E questa cosa non è una cosa dove il programma può ragionarci a riguardo normalmente.ZIG sotto quell'aspetto è come C, è come RAST, anche RAST è la stessa cosa, non c'è informazione a runtime, non c'è un runtime neanche per RAST, che è una caratteristica di questi linguaggi di basso livello.Ma in ZIG, però, mentre compili invece questa informazione c'è.Mentre compili tu puoi ispezionare informazioni relative un tipo, puoi chiederti se questa variabile è di tipo puntatore o è di tipo array o di tipo struct o no.Faccio un esempio, gente che è abituata a scrivere magari in Go, è quel genere di programmazione con reflection che puoi fare anche in Go, ma in Go viene fatto tutto a runtime, perché Go è un linguaggio che ha un runtime, che tiene informazioni sui tipi.In Zip2 non lo puoi fare a runtime, ma quello che non puoi fare a runtime lo puoi sicuramente fare a comp time e da qui da noi nasce i tipi generici.I tipi generici in Zig non sono una feature del linguaggio particolare, è semplicemente un tipo generico in Zig è una funzione che prende come argomento un tipo e ritorna un tipo.Non è una funzione che puoi invocare a run time, quindi non puoi mettere quella funzione in una posizione dove dipende, faccio un esempio, dall'input dell'utente, non ti compilerà mai in Zig.Però se quella funzione però se ad esempio vuoi fare una lista tu c'è la funzione list a cui passi non lo so un numero o un astratto quello che vuoi e Zig ti crea una lista di quel tipo è molto figo.Sì è veramente interessante devo dire che una particolarità di Zig tra l'altro è che ZIG non ha macro.Venendo da Rust, sono abituato a vederle e mi chiedo, non avendo macro in realtà con che cosa si sostituisce? Cosa sono le macro di Rust? Facciamo due passi indietro magari le macro di Rust sono, lo dico in modo vichingo, sono delle vere e proprie annotation che vengono lette a compile time e trasformate in codice.Adesso da una parte quindi c'è Rust con le macro, dall'altra mi dici che c'è Zig con dei costruti, delle funzioni come quella delle generics che vengono risolte a compile time.Quindi diciamo che queste funzioni risolte a compile time possono essere paragonate alle macro o sono qualcosa di più ampio? Sono sicuramente paragonabili alle macro.Sotto certi aspetti sono...diciamo così la differenza principale credo tra compile time e i sistemi macro e che quando tu pensi a una macro, la macro agisce sulla sintassi del linguaggio e lo puoi fare in maniere migliori o peggiori.La maniera forse peggiore è quello che fa C.Le macro di C sono un cerchio che sostituisce C e da quello ne derivano un sacco di problemi, sia di comprensione, sia di quelle che vengono chiamate foot gun, quindi di conseguenze inattese, di conseguenze inattese dall'uso della funzionalità e puoi sicuramente farlo meglio che quello che fa Rust dove Rust non ti permette di sostanzialmente fare output di sintassi sbagliate di Rust, cosa che puoi benissimo fare in C.Rust se non sbaglio agisce sostanzialmente sull'AST, sull'Abstract Syntax Tree e quindi ti assicura che certe cose che ti possono capitare in C non ti capitano in Rust.Guarda, se io dovessi dirti ad oggi qual è il mio linguaggio preferito, la mia risposta è Lisp.Non mi interessa neanche un tipo specifico di Lisp, mi vanno bene tutti.Io adoro la metà programmazione.Adoro abusare delle macro in Lisp, l'ho fatto, però proprio perché adoro la metà programmazione penso che le macro siano una pessima idea, o meglio, è chiaro il vantaggio che deriva dalle macro, però credo che alla base ragionare un programma a livello di sintassi sia una cosa che è preferibile non dover fare.Comptime ti permette questo perché tu quando fai Comptime in Zig non stai manipolando la sintassi del linguaggio, stai manipolando dati, stai manipolando un tipo che manipoli come manipoli qualunque cosa.Quindi faccio un esempio, se tu hai una struct c'è una funzione built-in che ti ritorna una descrizione dell'astract che è un altro tipo dove c'è un enum e il valore enum ti dice se quello che stai ispezionando è un astract, un array o qualunque altra cosa.E tu fai queste cose con, manipoli questi dati con i normali costrutti del linguaggio.Zig non ha un secondo linguaggio.Quando tu hai i generics, quelli tra le parentesi angolari in Java, C# ad esempio, il linguaggio che puoi usare tra le parentesi angolari è un sotto linguaggio ristretto, non è il linguaggio normale, ha un sistema dichiarativo, ha dei vincoli ben precisi perché il sistema di generics del compilatore di solito anche lì ha i suoi limiti, ha delle cose che ti può permettere di fare o non permettere di fare.Puoi portarlo molto avanti, più a il sistema di template che puoi usare sostanzialmente che è ben più potente dei generics normalmente, però anche quello ha la sua serie di problemi.Quello che è molto bello di Zig è che non è un secondo linguaggio.Quindi ci sono a volte delle cose che magari tu puoi scrivere in Rust come una macro che ti permettono di ottenere un DSL, un Domain Specific Language, che è più carino perché ti permette di...Tu puoi mettere in una macro una cosa che non è una chiamata funzione, mentre in ZIG tutta la metaprogrammazione passa solo tramite costrutti normali del linguaggio, quindi qualunque cosa deve essere una chiamata funzione.Questo da un lato, devo ammettere, è un po' più limitante delle macro, ma io la vedo più come una feature che una limitazione, perché la verità è che tutti vogliono scrivere macro, ma nessuno vuole leggere il macro di qualcun altro.certo certo tra l'altro ricordo che abbiamo fatto una bella puntata sulla metropolita che vi metto nelle note dell'episodio tra l'altro sempre per rividenziare la centralità del linguaggio anche nel suo stesso ecosistema una cosa che ha catturato la mia attenzione la parte di tooling no? Tipo i build file non sono dei make file o dei file toml o di un formato particolare ma sono dei veri e propri file di codice zig.Perché questa scelta secondo te? Beh prima di tutto l'idea di avere un sistema di build nel linguaggio stesso è una buona idea perché così la gente non deve impararsi una cosa di terze parti, che poi vuol dire sempre doversene imparare tipo 20 di cose di terze parti perché il progetto parte con Makefile, ma poi, ups, vogliamo andare su Windows, ma Windows non c'ha Make, allora buttali un file batch.Ok, ma io voglio usare PowerShell, ok, buttali un file PS1, che poi non si finisce mai, e diventa una zuppa.Quello è sicuramente una buona idea e tutti i linguaggi moderni hanno iniziato ad andare in quella direzione in una maniera o nell'altra.Rust stesso anche ha, se non sbaglio tu puoi fare un file build.rs e utilizzarlo per fare la build del tuo progetto, tutto interamente a Rust.- Sono troppo gnubo quindi ancora non lo so.- No ma hai ragione perché non è la maniera principale, credo, di fare build di progetti Rust di base.Tu semplicemente usi Cargo, usi il sistema dichiarativo di Cargo, però poi se hai bisogno di cose avanzate, tipo ti auguro che non dovrai mai farlo, ma la volta in cui il tuo progetto Rust deve davvero magari fare build anche di un progetto C++ che serve come una dipendenza o un progetto C, probabilmente lì potrebbe essere che una volta o l'altra tirare fuori il file build.rs è l'unica maniera di integrare tutto assieme.Scusa, vai vai.No, sostanzialmente è una buona idea, è una buona idea fare queste cose.Poi in Zig in generale ci piace il codice, quindi forse quando metteremo anche noi il nostro package manager che ancora non abbiamo, magari metteremo un file dichiarativo stile Rust però per ora non c'è ancora e quindi build.zig.Come legge e gestite invece le dipendenze non avendo un package manager? C'è allora il linguaggio supporta il concetto di dipendenze e quello che tu fai è c'è questo questo comando che è "zigbuild" che può leggere appunto un file "build.zig" e da lì capire dove ogni dipendenza, dove è quindi sostanzialmente la dipendenza che tu chiami, non lo so, "clap".Anche noi abbiamo il nostro command line argument parser che il nome è 100% copiato da quello di Rust e quindi se tu hai "clap" dentro il tuo file "build.zig" scrivi...c'è questo pacchetto che si chiama CLAP e il file, il root file, il punto d'ingresso della libreria è questo file qua.Quello che dovrebbe fare il package manager è sostanzialmente scaricare queste cose per te, ad oggi non c'è il package manager quindi te le scarichi a mano, e poi collegare e connettere tutti questi pezzettini per te, quindi dovrebbe scrivere quella definizione o fare un lavoro equivalente.Per ora non c'è, quindi te la devi scrivere a tua mano.Quindi, morale dalla favola, le dipendenze sono gestibili a livello di linguaggio, però non avendo ancora un package manager ufficiale, o te le fai a mano oppure usi un package manager della comunità.Però anche qui i package manager della comunità sono stati creati giusto per provare, per vedere com'è quello che siamo tutti aspettando, il package manager ufficiale, senza dubbio.Ma arriva, arriva tra qualche mese.Ah, cool.Tra l'altro pensavo a una cosa tu hai nominato più volte C e C++ e quando poi davo un'occhiata a Zigno per preparare questo episodio perché se no avrei mostrato veramente i livelli di gnubezza fuori da qualunque tipo di limite ho letto e ho visto su più posti specie su Reddit, questa associazione.Molti dicono che Zig sta a C come Rust sta a C++.Cosa percepisci? Cioè, secondo te perché porta le persone a fare questa associazione? Credo che dipenda forse anche un po' a chi lo chiedi, perché credo che se becchi la persona giusta puoi trovare il programmatore C che non è d'accordo, puoi trovare il programmatore Zig che non è d'accordo, puoi trovare il programmatore C++, puoi trovare sicuramente il programmatore Rust che non è d'accordo.Però, dettagli a parte, sto citando questo perché facendo comunicazione su Zig di lavoro chiaramente mi imbatto in queste persone sempre nel momento più inopportuno.Però, in generale, allora, sicuramente si può fare una descrizione più sofisticata, ma come punto di partenza io tendo ad essere d'accordo.L'idea di base è che Rust è un linguaggio che, alla fine, il borrow checker aggiunge un po' di complessità al linguaggio, ma ci sono state fatte delle altre scelte del linguaggio che a mio avviso non sono strettamente dipendenti dal design del border checker, che in generale sono diventate parte della filosofia del linguaggio, parte della maniera idiomatica di scriverlo, che però tendono un po' ad andare verso la complessità.Quindi faccio un esempio, in Rust tu puoi scrivere delle cose in uno stile magari un po' funzionale, gli errori hanno payload, però poi quando inizia a comporre le cose può diventare un po' complicato, a volte la gente fa fatica anche solo a combinare gli errori e usa dei pacchetti tipo Anyhow che ti permettono di combinare errori assieme senza dover scrivere troppo a mano.In generale, sai c'è questa idea in Rust, forse questo è un termine addirittura che è Rust, ha popolarizzato, che è l'idea delle zero cost abstraction.In Zig nessuno crede che le zero-cost abstractions esistano, o meglio, forse è meglio che spieghi meglio il concetto, così che si capisca il mio punto di vista.L'idea delle zero-cost abstractions in Rust è che tu puoi usare un'astrazione, come ad esempio iteratori o altre cose di questo genere, e l'idea è che l'iteratore è una feature di Rust che ti permette di scrivere codice più facilmente, ma che non ha un costo a runtime o che il costo che ha è il minor possibile che se tu scrivessi quella cosa a mano ad hoc non saresti in grado di fare sostanzialmente un lavoro migliore.E in particolare chi non usa quella feature non è soggetto a nessun costo.L'esempio di un'astrazione che non è a costo zero, ad esempio, è la metaprogrammazione in Go.In Go, anche se se tu non fai reflection, il run time di Go te lo cucchi lo stesso, non puoi farne a meno.Anche se tu non sponi una singola goroutine, adesso non so per filo e per certo, forse qualche cosa te la puoi risparmiare.Ma in generale in Go non esiste il concetto di non avere run time.In Rust, se tu non usi certe cose, il prezzo non lo paghi.Il problema, dall'altro lato, però, che rende certe persone meno...come dire, che a certe persone non fa accettare questa definizione e che il problema delle estrazioni è che costano, magari non a run time, però costano in termini di complessità, il codice diventa più difficile da leggere, diventa meno ovvio.E poi costa anche in performance di debug, perché cose come i tiratori magari spariscono dopo che tu fai una build di release con tutte le ottimizzazioni.Ma quando fai una build di debug, tutto è molto più lento.Tanto più estrazioni usi, tanto più è lento.Magari in certi casi non c'è problema e tutti sono contenti, ma se tu stai sviluppando un videogioco, la tua build di debug del videogioco deve più o meno girare, altrimenti è un incubo da debuggare.Altrimenti ti trovi a dover scegliere un frame al minuto oppure l'applicazione esplode e io non ho la minima idea di perché esplosa.Nessuna delle due cose va bene, quindi anche la performance di debug a volte è importante.In Zig è l'esatto opposto.In Zig in generale si tende a tenere tutto esplicito, semplice, magari a volte un po' verbose.Quindi faccio un esempio.Ogni volta che una funzione vuole allocare memoria, tu devi passargli un allocator come argomento, perché la convenzione è che qualunque cosa che vuole accedere all'IP deve accettare, o quantomeno vuole accedere a memoria dinamica, deve accettare un allocator come argomento.È una convenzione che noi facciamo, rende tutto un po' più, se vogliamo, rugnoso, che è a non doverlo fare, però il vantaggio, per fare un esempio, è che se tu poi prendi quella libreria, e non lo so, un parser JSON o un'implementazione di una HashMap e la vuoi compilare per WebAssembly, lo puoi fare.Perché il sistema di memoria di WebAssembly può essere incapsulato dentro un allocator speciale e funziona.O addirittura ci sono sistemi dove non esiste l'IP e tu puoi creare un allocator che invece lavora con...è un grosso array sullo stack.Queste sono cose che puoi fare in Zig, che sono carine.Il prezzo però è che è tutto molto più esplicito.Sotto quell'aspetto quindi, Zig è un po' più C che C++.Diciamo che C++ forse è un po'...Ah, le persone che programmano in Rust, che non sono d'accordo con l'esempio di C++, forse è perché vedono che C++ è unsafe, mentre Rust invece l'aspetto della memory safety è più importante.E C++ ultimamente in particolare è diventato una cozzaglia di feature che non finiscono mai.Rust a mio avviso ci si sta avvicinando pericolosamente però non è ancora lì dove ci più più Chiaro Hai per un attimo toccato il mondo dei del game development no? e mi è sembrato di vedere in realtà qualcosa c'è qualcosa di significativo cioè possiamo fare game game development con con Zigg Sicuramente ci sono un paio di esempi carini, di recente c'è stata la WASM4 Game Jam, WASM4, WASM-tartino-quattro, è un'idea veramente carina, la chiamano una fantasy console scritta in WebAssembly.L'idea di una fantasy console è che fa finta di essere una console, però non è una console fisica, non è un Super Nintendo, ma è un Super Nintendo digitale che accetta cartucce scritte in WebAssembly, fa girare codice WebAssembly e ha una serie di limitazioni artificiali che aiutano con la creatività.Quindi la Wasm 4 ad esempio mi pare che è 512x512 pixel o circa, ha solo tre colori disponibili alla volta per frame.Tu puoi cambiare quali sono questi colori in ogni frame, ma ogni singolo frame ha solo tre colori alla volta.E per il suono ha tutti quegli agiggini che fanno un tipo di onda sonora ben specifico, quindi quella che fa le onde a sega, onde quad.Le musichette 8 bit verrebbero fantastiche.Ti prego, mandami poi come finiamo l'episodio il link che lo mettiamo nelle note degli episodi o che mi ha incuriosito.Assolutamente, Wasm4 è molto carino su tutto quell'aspetto.L'ultima game jam che c'è stata, la maggior parte dei giochi sono stati programmati in zig.In quella precedente era pari merito zig e c, e Rust era molto rappresentato, però era sotto zig e c.Questo è un esempio, poi la sovra...zig è molto più piccolo di Rust, in realtà la sovra rappresentazione di zig nella gem di Wasm4 in particolare, probabilmente perché ci sono un po' di fissati nella nostra comunità che adorano fare questo genere di cose.Però credo sia un esempio carino.Un altro, un ultimo esempio secondo relevante è che ci sono delle persone che stanno lavorando a un framework per fare videogiochi, in realtà ci sono più di uno, però uno in particolare che secondo me vale la pena dargli un'occhiata si chiama MacEngine ed è questo framework per fare videogiochi improntato a essere multiplatform, quindi è in grado di offrirti una finestra, è un buffer per dentro qui disegnare, sia se tu stai compilando per Windows, per Linux, per Mac, per WebAssembly, farlo andare con la WebGPU.La programmazione dei giochi è complicatissima, c'è un sacco di prognaccia cui devi pensare.In realtà, onestamente, io non so...ho un'idea generale delle cose che fa Mac, però non le so tutte per filo e per segno.Però è interessante perché l'idea di essere multiplatform è una delle cose, se vogliamo, più iconiche di ZIG.Hai detto che ZIG è un linguaggio abbastanza giovane in realtà e quando si parla di system programming o comunque di linguaggi compilati tolti un po' i nonnini C e C++, tra l'altro però ho visto che hanno fatto il fan cop-op del fondatore, del creatore di C++.No, davvero? Sì.Oh mio Dio.Detto questo, sto aspettando quello di Cunningham Ricci dai vecchi tempi dell'università, detto questo a oggi nello spazio per questi linguaggi di assistent programming abbiamo Abbiamo Go, abbiamo C, e poi abbiamo Zigg, che è un linguaggio abbastanza giovane in realtà.Sono andato un po' a guardare com'è nato, fondamentalmente i primi commit risalgono attorno al 2015.Come fa oggi un linguaggio così giovane a ritagliarsi il suo spazio? Non è facile, io credo che quello...è un problema che mi pongo anch'io, addirittura io me lo pongo in una maniera estremamente più cinica, sei pronto per un'avventura? Vai! Allora, forse prima dovrei fare una domanda di apertura.Qual è in generale l'opinione delle criptovalute di Gitbar? Eterogenea.Eterogenea, ok.Allora io parto da un punto di vista dove per me le criptovalute hanno un problema dove io non vedo cose utili che vengono fatte per me dalle criptovalute.Questo credo sia un'affermazione non troppo controversa spero.Io ad oggi personalmente di tutti i prodotti legati al mondo delle blockchain che ho visto non ho trovato uno che mi interessasse personalmente e quindi rimango un po' scettico della tecnologia, benché sia super interessante a livello teorico, però all'atto pratico vorrei facesse qualcosa per me e ancora non l'ho visto.Questo stesso ragionamento, secondo me, vale per un sacco di altre cose, non è un ragionamento dove solo la blockchain è l'unica cosa che deve essere valutata secondo questo metro abbastanza duro.Ci sono un sacco di cose, a mio avviso che noi facciamo l'informatica dove la cosa viene fatta, di per sé crea la sua piccola bolla, il suo piccolo ecosistema di cose che sono necessarie per crearla, metterla in vita, però poi alla fine sta roba serve a qualcuno, serve a qualcosa e a mio avviso i linguaggi di programmazione sono un esempio di una cosa del genere dove un linguaggio può non essere utile e allo stesso tempo un linguaggio che prende piede, diciamo così, magari una persona molto scettica, molto negativa riguardo potrebbe dire "prende piede per tutte le motivazioni sbagliate" poi genera un sacco di hype, lavoro.Io lavoro full time per Zig e non ce ne sono ancora molti in giro, però ci sono delle persone che hanno un lavoro dove scrivono ZIG a tempo pieno.La domanda che a mio avviso trovo sia legittimo, una persona scettica verso ZIG che si chiedesse è "ma vale davvero la pena?" oppure questi stanno inventando l'ennesimo linguaggio che non porta niente di nuovo sul tavolo e creano un sacco di lavoro relativo a questo, qualcuno deve scrivere libri in ZIG, qualcuno deve insegnare agli altri come fare roba in ZIG, aprire canali di YouTube relativi a ZIG.Io sono colpevole la maggior parte di queste cose.Io stesso mi sono posto questa domanda.A mio avviso il valore vero che Zig può portare secondo me sono due cose.Da un punto di vista meno monetario, meno veniale, più morale, è che io credo che la programmazione di sistemi sia veramente una figata, sia veramente una di quelle cose che possono permettere alle persone di crescere come informatici, come artigiani del software, come diceva l'intro, però allo stesso tempo la programmazione di sistemi è troppo erogiosa.È il discorso che dicevo all'inizio, ci sono troppe cose brutte, non necessarie, che sono lì per colpa dell'ecosistema vecchio a cui uno giustamente non vuole dover sottostare.E Zig sotto quell'aspetto un po' aiuta.La seconda cosa più monetaria è che effettivamente ad oggi ci sono un sacco di aziende che hanno sempre bisogno di lavorare con progetti scritti in C++ perché se hai un progetto di 500.000 righe di CI e sei un'azienda grossa non te ne puoi liberare in una settimana.hai bisogno di una maniera per andare avanti.E a mio avviso Zig può portare un punto di vista che Rust non vuole portarvi di tanto, perché tu puoi interfacciarti da Rust a Progett-IC, è fattibile, però tutto il guadagno che hai in Rust è quando stai nel mondo di Rust, sono le certezze che ti dà il borrow checker.E c'è questo meme che è nato un po' tempo fa, dell'idea del "Rewrite it in Rust".In ZIG no, in ZIG c'è un blog post proprio titolato "Maintain it with ZIG" dove l'idea è che ZIG può interoperare con C in una maniera molto stretta.Tu puoi letteralmente importare in ZIG un header file di C e funziona.Stai già usando una libreria C.Proprio import del punto H della libreria C, sia posto.E quindi ti permette di fare questa transizione molto più graduale perché non hai i vantaggi più grossi che ti arrivano solo alla fine, quando hai trasportato tutto, ma hai i vantaggi in più anche nelle parti intermedie.Faccio un esempio di perché dico che Rust non può fare questa cosa alla stessa esatta maniera.Rust non è un compilatore C e C++.Questa è una cosa veramente importante.Addirittura ci sono progetti di Rust che usano Zig per compilare le loro dipendenze C, per cross-compilare in particolare.Quindi a mio avviso Zig può davvero permettere una transizione reale per aziende che sono in una situazione simile.E secondo me ci sono un sacco di aziende poi veramente importanti che sono cose del genere perché onestamente che Facebook usi o non usi Zig non mi interessa.Google non lo so.Però ci sono aziende tipo io adesso che ho ho iniziato a fare streaming in compagnia bella, YouTube, ho iniziato ad appassionarmi un po' di videocamere e le videocamere sono dei sistemi hardware complicatissimi, esagerati e lì usano C e C++, non si scappa.Quindi la mia speranza è che Zig possa portare un po' di innovazione in questo genere di aziende, più che pensare a Big Tech.verissimo ecco il mondo embedded invece quindi vabbè ormai l'hai detto le telecamere fanno parte di quel mondo no? però c'è per esempio tutto il mondo dell'automotive che è super interessante e soprattutto super in fermento no? sì onestamente dell'embedded devo cercare di informarmi un po' di più perché la mia percezione e lo dico subito, è proprio percezione da un esterno che cerca di avvicinarsi.Quando si tratta di embedded inteso come tu, il microcontrollore, un cavo USB e un computer chiuso in una stanza, Zig è interessante.C'è quello che noi chiamiamo lo Zig Embedded Group, che è un gruppo di persone che sta lavorando a un framework per programmare microcontrollori, dove l'idea è questa, che ogni microcontrollore ha tutti i suoi dettagli, che leggi nel datasheet per sapere il pin 1 che cosa fa, il pin 2 che cosa fa, cose di questo genere, qual è l'indirizzo della memoria, a cui se scrivi 1 succede questo, più che con quest'altro.Tutte queste informazioni sono, come dicevo, cambiano da controllore a controllore e ci sono questi progetti che che cercano di raccogliere tutte queste informazioni e fornirti un'interfaccia uniforme, omogenea.Quindi tu importi questa libreria, dici il modello del microcontrollore che hai o un Raspberry Pi così cos'ha e a quel punto ti permette di avere dei default già configurati bene.Credo che Rust abbia anche dei progetti simili.Con la programmazione comptime in seguito ci sono un sacco di cose carine che puoi fare.C'era un blog post che è uscito un po' di tempo fa, l'esempio di una persona che ha deciso di riscrivere il firmware della propria tastiera custom da Rust a Zig e raccontava dell'esperienza e delle cose che ha dovuto rinunciare a dando via da Rust e delle cose che ha guadagnato provando a fare Zig e in generale quella che è stata la qualità dell'esperienza.Però dall'altro lato, parlando al proprio livello più sulla larga scala, quindi quello che hai citato tu, l'automotive e se vogliamo l'industria.Onestamente non sono ben sicuro di qual è la situazione, perché io ho degli amici che lavorano in questo ambiente e ogni volta che mi raccontano le cose che fanno, in generale tende a trattarsi di sistemi già prepacchettizzati da Siemens o da giganti di questo genere, dove tu prendi lo scatolotto, magari salvi i cavi, però poi tutto lo stack lo controllano loro e chiaramente c'è l'offerta cloud relativa, perché chi non vuole mettere nel cloud i propri dati? Quello è un po' deprimente forse, però la verità è che forse l'embedded è così.No sai perché te lo dico? Perché in realtà mio cognato lavora per Sagemcom, Sagemcom è una di quelle società che fanno embedded e loro usano ancora, mi verrebbe da dire da sardo, H7C, ma H7 per fare sistemi di computazione parallela, cose di questo tipo, per cui mi chiedevo se c'era uno spazio in quell'ottica, capito? Capito, in quell'ottica secondo me sicuramente sì.Se un gruppo di programmatori C in particolare, che immagino il motivo per il quale continuano a usare C è magari un po' per dipendenze, un po' perché gli piace lo stile di programmazione C, secondo me, possono trovare le zighe e trovarsi bene.Magari non tutti, però.Curiosità.Abbiamo iniziato la puntata di oggi parlando di BAN.Cosa ha portato BAN al mondo di zig? BAN, per capirci, è il nuovo, tra grandi virgolette, runtime javascript che è un po' emerso mostrando delle performance significative.Questa è una ottima domanda.BAN ha portato sicuramente un sacco di attenzione.BAN ha assolutamente fatto il botto a livello di attenzione.Addirittura su github ad oggi ha già più star di Zig che in realtà, dal mio punto di vista, è un achievement.Parlavo all'inizio dell'idea che il linguaggio deve fare qualcosa di nuovo e se i progetti scritti nel tuo linguaggio superano i popolari del linguaggio, adesso non è necessariamente prova definitiva che ho diritto a un superattico in paradiso, però meglio di niente.Sì, Banner ha portato un sacco di attenzione, un influsso molto grosso di gente nuova che ha iniziato a interessarsi a Zig e questo si è visto nella nostra comunità di molto.Sfortunatamente una buona parte di queste persone è arrivata un po' troppo presto, perché Zig ancora non ha tutto quello che è necessario per avere un'esperienza di sviluppo non da super early adopter.Quindi faccio un esempio.Vuoi fare un web server in Zig? Ad oggi lo puoi fare, però non è come in Go che fai il web server e lo esponi su internet e non ti devi preoccupare.Noi ad oggi ad esempio non abbiamo un'implementazione di una libreria TLS per avere connessioni HTTPS.Questo è una di quelle cose ovviamente fondamentali che deve avere, se sei un linguaggio di basso livello devi fare la fatica di fartela o usi la versione C, puoi anche fare quello, però insomma è una di quelle cose dove a livello di progetto vuoi avere controllo, vuoi farlo bene.Oltre all'attenzione Banna ha portato un esempio di un progetto che, Banna ha preso anche dei finanziamenti da Venture Capital dopo essere stato reso pubblico e quindi ha portato l'esempio di un progetto che ha preso dei finanziamenti iscritti in zig e un po' ha dimostrato che forse non è proprio proprio un giocattolo, forse non tutti per forza devono usare Rust se vogliono provare a fare programmazioni di sistemi nel 2022.Adesso però io devo fare un po' lo stronzo della situazione.siccome siamo in un bar la mia domanda sarà facile.Quanto del successo di BUN viene dal troll level di Jared Summer, il suo fondatore? Sicuramente un bel po', sia nel bene che nel male.Nel bene perché chiaramente Jared in qualche modo adesso non so se è inciampato o sapeva e ci si è piondato come uno squalo, ma sicuramente è incappato in qualcosa che ha valore per la comunità JavaScript, altrimenti non credo ci sarebbe stata così tanta risposta.E lui ha questo atteggiamento dove continua a postare cose relative alla performance E in realtà la performance per quanto riguarda JavaScript è un punto debole.Magari non necessariamente per il linguaggio stesso, ma quando inizi ad avere un sacco di tool, bundler, pre-bundler, post-bundler, scritti in JavaScript, quindi neanche scritti con un linguaggio a massima performance, no? E inizi a concatenare tutto assieme.Non so, io avevo un blog scritto in Gatsby e il mio blog che aveva, non lo so, 10 post.post il suo minuto e mezzo per compilare per generare gli asset statici ce li metteva ed è un po tanto.E ti compilava, il blog di Gitbar è scritto in Gatsby in modalità dev non compila più.Sai che io ho dovuto abbandonare Gatsby perché ironicamente quando sono passato ai i Mac M1, il mio blog in JavaScript è l'unica cosa che si è rifiutata di girare sulla nuova architettura.Perché con Gatsby usavo dei plugin che a loro volta dipendevano su delle librerie C che però fallivano la compilazione su ARM, erano solo in grado di compilare su x86? Dio quanto ti capisco! E si, comunque interessante la questione di Bane, un'altra cosa che è interessante è appunto il fatto che ci sia ancora...quando un linguaggio è giovane e tu vedi il trend che il linguaggio sta prendendo, quindi lo sviluppo, l'attenzione, tutto quello che ti pare, se tu sei uno sviluppatore che vuole fare il salto di carriera, davanti a un linguaggio così giovane ci sono gli spazi.Tu hai parlato dell'implementazione TLS, ma sicuramente ci saranno un sacco di posto per implementazioni varie, che ne sono? Ne dico una.non so se esiste un faker o simili per generare dei dati fake, no? Non esiste.Utilizzabili per i test.Beh, cacchio, se tu ti studi il linguaggio e fai la libreria e per sbaglio la libreria funziona diventi quello che ha fatto Faker per Rust, per Zig e quindi c'è uno spazio interessante a livello anche di carriera.Mi sbaglio? No, assolutamente, assolutamente sia per quello sia per altre cose tipo scrivere magari...non abbiamo il libro di Zig ancora e questo è un altro esempio o addirittura parlavamo di Ban fino a un attimo fa.Ban ha preso degli investimenti e già lo ha iniziato ad assumere e se tu sei una delle...Ricordiamo la sua offerta di lavoro.Sì, ha imparato un sacco di cose relative a Twitter, credo, dopo aver postato l'offerta di lavoro con dei toni un po' aggressivi.E quasi ai livelli di Elon Musk su Twitter.Però se sei uno sviluppatore Zig, sei una delle, non lo so, poche centinaia di persone che ad oggi sa programmare in zig hai un vantaggio.Sicuramente un programmatore con la necessaria esperienza nell'ecosistema prende zig, lo impara in due settimane ed è a posto.Quindi diciamo sì, il tuo vantaggio non è un vantaggio universale soprattutto.comunque sia sicuramente questo ha la tua rarità ad oggi ha un effetto sulla sulla tua capacità di negoziare ad esempio un sanario per BAN e compagnia bella.Detto questo per tornare al tuo discorso su BAN e su Jared sicuramente non è solo il tweet ma anche a mio avviso l'idea di lavorare per una startup che ha preso Venture Capital e che è in diretta competizione con un'altra, con Dino, ha i suoi pro ma anche i suoi contro.A me questa cosa di tipo uno degli aspetti magari se vogliamo un po' più tristi a mio avviso della storia tra diciamo una delle conseguenze un po' negative dovute alla scesa di Ban a mio avviso è quello che è successo con Dino.Dino, creato dallo stesso creatore di Node, era partito come questa nuova svolta.Lui aveva fatto questo talk dove raccontava le cose che secondo lui aveva fatto bene in Node, le cose che aveva fatto male, le cose che voleva cambiare.Una di queste era, ad esempio, distaccarsi dall'ecosistema di NPM, usare invece un sistema di import basato sugli URL e essere, forse credo, anche decentralizzati.poi BAN è uscito.Infatti si è vista che ha dovuto sviluppare l'interopperabilità se no domani lo usavano Dino.Però è molto divertente perché è uscito BAN che ha promesso tutte queste cose non so quanto è passato dieci giorni forse e Dino ha fatto l'annuncio dove dove aggiungevano supporto per NPM, mettevano layer di compatibilità con Node e casualmente anche avrebbero pubblicato l'implementazione più veloce mai esistita di server HTTP per Dino.A mio avviso la parte diciamo così triste è che sostanzialmente la nuova competizione ha costretto Dino a cambiare rotta repentinamente perché sono in competizione.Allora, posto che quando è uscito Dino abbiamo avuto anche modo di parlare con Matteo Collina di questa cosa.Quando è uscito Dino la percezione mia e di tanti è stata quella che la necessità di monetizzare in qualche modo una cosa non più monetizzabile come era Nod ha portato la nascita di Dino, questo è il mio punto di vista, magari mi sbaglio, quando invece molte di quelle migliorie si potevano portare tranquillamente all'ecosistema Node che però non gli apparteneva più.Secondo me hai ragionissima, scusami se ti interrompo, ma secondo me hai ragionissima.Sai qual è un altro progetto che avrebbe benissimo potuto vivere di donazioni dall'istante in cui esploso quando è andato pubblico? BUN.Però Jared non ha voluto farlo, non ha neanche provato ad attivare GitHub Sponsors, invece è andato a prendere investimenti del venture capital.Scelte? Sì, assolutamente.E scelte che poi le vedremo pagate tra qualche anno, secondo me.Comunque è interessante perché? Perché ha mosso le acque.Perché per esempio il team di DNOD e ritornato indietro in alcune parti, basta guardare le conversazioni tra Giared e Matteo Collina, gli sfottò, dove però il team di Nod è andato a ottimizzare alcune parti che erano un po' trascurate.Quindi diciamo che anche la concorrenza aiuta da quel punto di vista, perché Nod sentiva un po' il peso dei suoi anni fondamentalmente ed era un po' ingessato.invece in questi ultimi pochi anni si è risvegliato un po' e questo è assolutamente apprezzabile.Vedo che il tempo sta volando, voglio farti però due informazioni rapide sulla parte della community.Tu sei VP of Community per la Zig Software Foundation.A livello di community, quali sono le sfide in realtà che Zig deve fare per svilupparla? e come immagina Zig la community di Zig? Bella domanda.La comunità è complicata.Da un lato io credo che...parlavamo di questioni di come rendere un progetto sostenibile e tutto quanto, una cosa di cui sono fermamente convinto che ho imparato sulla pelle, credo, partendo dalla mia esperienza a Redis Labs quando ho conosciuto Salvatore e continuando alla Zsoft Reformation.Punto fondamentale, regola numero uno del Open Source Club, la gente gliene deve fregare qualcosa di te, la gente deve sapere che cosa stai facendo e gli deve importare.Se nessuno gliene frega a livello emozionale di quello che fai, nessuno ti ti dona, nessuno ti guarda nella tua direzione quando ti succede qualcosa di brutto che magari non ti meriti.Fintanto che le persone ti guardano e ti supportano riesci ad andare avanti.In realtà molte delle donazioni che riceviamo non sono donazioni grosse, sono donazioni piccole, 5-10 dollari al mese, però quando hai un pubblico abbastanza ampio, questo è una cosa vera e sono soldi veri che ti permettono di sostenere, ad esempio nel nostro caso, tre sviluppatori full time più una serie di altri sviluppatori core che non hanno un contratto full time ma sono in grado di fatturare un po' di ore ogni settimana.Questo secondo me è il punto di partenza e questo ti permette anche di avere un sacco di persone che ti guardano, ti permette anche di tenere le cose un po' in equilibrio perché se poi tu non fai questo, però ti capita di avere la fortuna di avere un po' di aziende invece che ti supportano, le aziende quando ti donano, donano molto di più.Però il problema è che hanno poi anche un'influenza relativa alla donazione che fanno, magari non direttamente, magari non è contrattuale, però se tu ad esempio, supponiamo, hai tre persone full time e due terzi dei soldi che fai ti arrivano da un'azienda, quando quell'azienda ogni tanto vuole qualcosa, non puoi andare a spavar dire "sai cosa? Facciamo che no" perché le conseguenze sono molto grosse.Quindi un'altra cosa che noi cerchiamo di fare è tenere un equilibrio tra donazioni corporate e donazioni pubbliche e quando abbiamo ad esempio dei soldi in più che arrivano dal mondo corporate, facciamo un po' finta di non averlo perché dipenderci troppo strettamente significa esporci sotto quell'angolo.Dall'altro lato la comunità a volte è una rogna, perché è una matassa di persone, adesso non voglio fare, non voglio tirare fuori i promessi sposi col passaggio dove c'è la massa e le cose brutte o così, però è vero, la gente quando si incacchia su Twitter si incacchia di brutto e queste cose hanno conseguenze, soprattutto quando è uno scontro culturale, ad esempio, da italiano, io ho certe cose americane e le posso seguire, certe altre sono cose culturali loro che pensano, che alcuni, molti di loro pensano siano realtà universali perché, diciamo così, noi magari ci sentiamo un po' fuori dai giochi, un po' seduti ai piedi del palco e vorremmo essere sul palco.Loro pensano che sia tutto, che che tutto quanto sia il palco e non esista niente al di fuori.E questo è problematico, è problematico a sua volta.Vero, verissimo, un Dio, quando si approccia in un mondo internazionale questa cosa si percepisce.Veramente vero.Ultima domanda vera e propria.Cosa consigli come learning path per chi vuole approcciare a Zig e alla sua community? Step 1 vai sul sito di Zig, ziglang.org, scarica Zig.Ci sono tante maniere per scaricarlo, ci sono dei package manager, però è molto consigliato semplicemente scaricare l'archivio.Non ha dipendenze, quindi lo estrarrai da qualche parte se sei sostanzialmente a posto.Così ce l'hai.Step 2.Leggi la documentazione, la language reference.Non è molto lunga, il linguaggio non è molto complicato e io di solito lo dico un po' diciamo così, in maniera spavalda, quando la gente dice "ah non so se voglio, sono indeciso tra Rust e Ziggy" io di solito dico "prova Ziggy un weekend e prova Rust un paio di settimane" dove l'idea è che in SIG un weekend ti basta a vedere e essere pericoloso con il linguaggio.In Rust forse ti richiede un po' di più.Comunque sia, il mio punto qua, scherzo a parte, è che non è molto complicato.Step 3, e non la devi magari leggere tutta, però così inizia a farti un'idea, guardi quello che c'è sul sito, guardi la documentazione, ti fa un'idea.Step 3, join a una comunità su Discord oppure su una delle altre, e RAC, ce ne sono un sacco, sono linkate dal sito, e così puoi chiedere aiuto alle persone.Sfortunatamente, ad oggi, e questo è un altro punto che trascende Zig, non ci sono, a mio avviso, dei buoni libri di programmazione di sistemi che ti insegnano la programmazione di sistemi.Ci sono manuali di C, ci sono manuali di C++, c'è il libro di Rust, e tutte queste cose ti insegnano un po' della programmazione di sistemi, ma sempre nell'ottica del linguaggio che stai utilizzando.Quindi noi non avendo un manuale di Zig ancora pubblicato, perché il linguaggio è ancora un po' in flusso, lo stiamo facendo, è versione 0.10 che sta per essere rilasciata ad oggi, a breve, non c'è sfortunatamente un libro che dici "ah, voglio il...", almeno io non lo conosco.Quindi in generale quello che ho fatto io, quello che fanno le altre persone che si avvicinano a Zig è che hanno un'idea di cose che vogliono fare un po' di curiosità e poi interagiscono con altre persone della comunità per sostanzialmente aiutarsi ad andare avanti.Noi siamo estremamente attenti ad avere...abbiamo un canale di...si chiama Zig Help, nel server di disco più grosso, dove stiamo...ci assicuriamo sempre di rispondere alle persone che hanno domande, perché tutti hanno domande sullo stack, l'IP, tutti, quasi tutti di fatto arrivano da linguaggi di alto livello perché lavorativamente è così e questa è la vita ad oggi.Bellissimo, mi hai incuriosito, sicuramente un weekend lo investo in un test anche perché in realtà Rust in un weekend forse capisci la differenza però vabbè, lasciamo stare, sono ancora in quella fase dove devo raschiar via la prima...il primo strato di ruggine.Sai una cosa carina che può magari interessarti? Hai mai usato...hai mai visto Rustlings? Rustlings? No? Sì, con la G, RustLinks, è praticamente una serie di programmi con errori di sintassi dentro o pezzettini che mancano scritti in Rust.L'idea è che tu risolvi questi esercizi e piano piano impari un po' di Rust mentre li fai.Magari ad oggi, se hai già investito un po' di tempo in Rust, non ti vale la pena farli, tendono ad essere molto introduttivi.Ma noi non ci facciamo mai problemi a rubare idee che sembrano buone ad altri linguaggi d'ecosistemi.c'è ZigLinks, che può essere una buona introduzione a Zig senza troppa fatica.Assolutamente sì, e anche questo mi raccomando mi manderai il link sicuro e io lo metterò nelle note dell'episodio.Però adesso è arrivato il nostro momento tipico e topico di Gitbard, il momento in cui i nostri host, i nostri guest ci parlano e ci portano una serie di o una o più link, talk, video, libri, vini, quello che vogliono insomma e ciò che reputano importante e carino condividere con la nostra community Vi conduco nel paese dei balocchi! Ah, il paese dei balocchi! Loris, hai qualcosa da condividere con noi? Ho qualcosa da condividere con voi, sì.Anzi, allora Mauro, tu sei di Olbia, giusto? Sì, sono di Nuoro, ma in Sardegna...Quando sto in Sardegna, perché attualmente vivo a Lione, ma quando sto in Sardegna, sì, abito vicino a Olbia.Ok, io non sono mai stato a Nuoro, sono stato una volta forse in zona, però ho degli amici di Cagliari e con questi amici mi capita di ritrovarci a Cagliari, mi capita di trovarci anche in giro, parlottiamo sempre e loro mi hanno introdotto a una cosa molto iconica, Sarda, che adoro così tanto che anche non da Sardo mi sento in dovere di dover condividere con tutte le persone che incontro.Mi devo preoccupare? Non lo so.Ci sono sicuramente un sacco di cose interessanti sarde.In questo caso, la cosa che io voglio condividere è un rapper sardo.A mio avviso uno dei migliori rapper italiani.Si chiama MC Cavallo.E in particolare raccomando a tutti gli spettatori di iniziare con "Basta con la morte", che una canzone, il rap come si sa è il rap di protesta, no? Però a mio avviso i cantanti di rap tendono a protestare contro cose che non sono a volte poi così importanti.Sai, è facile dire io protesto contro qualcosa giusto per...MC Cavallo prende la protesta veramente sul serio e fa la protesta forse contro uno dei veri più grossi mali della vita, la morte.Questo e basta con la morte.Ci sono un sacco di liriche profonde, ci sono un po' di parole in sardo, se avete degli amici sardi vi possono aiutare a tradurle, però in realtà il contesto generalmente vi aiuta a capire anche cosa si intende, anche se non sapete esattamente qual è la parola.E poi una volta che l'avete scoperto basta con la morte, siete pronti per affrontare tutti gli altri pezzi un po' più impegnativi.Un solo consiglio, si tratta di rap, non aprite questa canzone davanti a vostra madre, davanti se siete di quell'età, ascoltate privatamente, nella calma.Possibilmente con le cuffie.Con le cuffie, sì.Sì, bellissimo.Mi hai riportato in mente, guarda, una storia, fa parte delle nostre radici culturali.Ci sono i Menhir, i Nuraghe, c'è MC Cavallo.Si, MC Vallo è fantastico.Mi chiamo Iknusa che sono...No, buttateci un orecchio sicuramente.Io ho anche io un balocco.Sono una serie di video su YouTube.Sono 180 e qualcosa, video da 4-5 minuti.Come sapete sto provando a studiare Rust.Vedremo tra un mese cosa ne avrò combinato.il mio voto finale cioè sono in grado di usare Rust solo se entro il mese prossimo riesco a riscrivere il programmino che scrive i capitoli nell'mp3 del podcast, lo porto da TypeScript a a RAST, quindi se ci sono buono, ecco, vuol dire che ci sono riuscito.Nel frattempo, la sera, quando sono sul divano, sto guardando una serie di video, vi ho detto sono 180, 190, comunque sono un po', si chiamano Easy RAST e toccano praticamente quasi tutti gli angoli del linguaggio.Quindi per chi vuole approfondire, secondo me, uno di quei punti insieme a Rustin Action da buttare un occhio.Fun fact ci sono sia in inglese che in coreano se vi piace.Loris ti faccio una domanda se qualcuno volesse trovarti sulla rete dove ti trova? Io perdo un sacco di tempo troppo su twitter mi trovate @croloris quindi con i nomi e i nomi.Ho un blog personale, Cristof.it, dove scrivo abbastanza regolarmente di lamentandomi del mondo open source e spiegando concetti di zig.E ultima cosa, sono su Twitch, il nome del canale è Cristof_IT perché non potevo prendere il nome che volevo, però se andate sul mio blog trovate il link a tutto.Non riuscivo a calcare il pulsante perché dovete sapere che la trackball si è bloccata.Sto usando un mouse che non tiene il click prolungato, quindi...Detto questo, la puntata con l'Oris mi è super piaciuta.Grazie di essere venuto a trovarci, Loris.Grazie a te per avermi invitato.Questa è la prima comunità in italiano di italiani di programmazione per davvero.Ho provato a vedere quella su Reddit, ad esempio, che esiste.E' supporto tecnico, non è programmazione.Siete fantastici.Sì, noi siamo a 360 gradi e quindi ci piace divertire.parliamo un po' di tutto e tra l'altro anche i linguaggi che trattiamo sono eterogeni non facciamo helpdesk perché crediamo che in realtà lo stimolo sia molto più efficace della risoluzione stessa del problema questo è un po' la nostra visione Loris, come noi solitamente diciamo siccome Gitbar è un bar, l'effetto che tendiamo a ricostruire l'effetto da birretta post conferenza, ti diciamo che il nostro bar da oggi è anche casa tua! Sto già aggiornando! Quindi vienici a trovare quando vuoi, c'è una birra sempre fresca per te! Assolutamente, appena aggiornato il canale di Telegram! Lorisio ti ringrazio nuovamente per esserci venuto a trovare A nome mio, a nome di tutta la community, do appuntamento alla prossima settimana.Ciao! Ciao! Ciao! [jaw thump] Vedere.
