Gitbar logo

Gitbar Italian developer podcast

Conversazioni sullo sviluppo software fatte davanti a una birra.

copertina episodio

Opensource e Zig lang con Loris Cro (Zig Foundation)

Stagione 3 Episodio 130 Durata 01:48:23

Questa settimana parliamo di un linguaggio giovane ma che ha già attirato l’attenzione di molti. Dopo il lancio di Bug, il nuovo runtime js scritto in zig, molti di noi hanno provato a capire cosa sia zig. Proviamo a capirlo anche noi con il VP of community della Zig Foundation, Loris Cro. Abbiamo anche aperto una parentesi sullo stato di salute dell’opensource.

Ricordati di iscriverti al gruppo telegram

https://t.me/gitbar

Supportaci su

https://www.gitbar.it/support

Paese dei balocchi

Contatti

@brainrepo su twitter o via mail a info@gitbar.it.

Crediti

Le sigle sono state prodotte da MondoComputazionale
Le musiche da Blan Kytt - RSPN
Sweet Lullaby by Agnese Valmaggia
Monkeys Spinning Monkeys by Kevin MacLeod

Trascrizione

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 infochiocio.gitbar.it o atbrainrapper 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 Geekbar 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 andata 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.

Si 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 e principalmente tutto in inglese anche se è tenuto a Milano e quello che scrivo sotto è mi pare 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 su 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 e 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 è 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ù più alto del termine no? Gitbar è sempre molto molto attenta allora 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 poco umana o umanocentrica? Beh io posso magari fare un paio di esempi di cose che sono cose che di cui ho letto di recente cose che avvengono più o meno nella se vogliamo nella mesfera, non nella mesfera però nello 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 al lato pratico nel senso metti che tu domani vuoi creare un nuovo linguaggio di programmazione tu aziendona quindi sto parlando di 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 linguaggio di programmazione database altro tooling di questo genere framework che vengono usati molto sono tutti open source c sharp una volta non era open source adesso è diventato completamente open source 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 micro è 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 giusto il giusto quanto che serve ad assicurarsi che riescono a 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 no e fa you shall not pass alla macchina di marketing la 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 c'è un non è solo una questione di combattere contro non lo so l'erosione di un ideale che non esiste più ma a essere a tenti a queste cose qua ce n'è 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 si individui che aziende non siamo anti business però siamo sempre stati molto attenti a rimanere indipendenti la zigsaw foundation non ha aziende di big tech nella sua board of directors e funziona funziona si può fare non funziona per tutto non chiaramente non posso promettere a nessuno che domani fai un 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 spurio o fanno perdere quella quell'aura di di di di di approccio collaborativo al mondo dell'open source o sia in qualche modo 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 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 ne tiro fuori solo uno abbastanza esemplare su questo esempio la microsoft ho detto prima ha reso c sharp open source e c'è la dotnet foundation quindi credo che non sia solo c sharp io continuo a dire c sharp però in realtà è tutto il sistema dotnet tutto l'ecosistema dotnet che è stato reso open source dunque questi hanno la fondazione idealmente una fondazione dovrebbe il lo scopo la ragione di esistenza della fondazione non profit collegata a un progetto pensi o se dovrebbe essere sostenere progetto pensi o se 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 dei direttori ci sarebbe stata insomma un po di cose da fare attivamente per sostenere la fondazione non è stato così alla fine si è dimesso e va beh è 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 dotnet foundation quindi immagino che tu fai una libreria che diventa abbastanza popolare nel mondo dotnet e potrebbe essere qualunque cosa no non lo so un parser gison una cosa a caso però è abbastanza 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 va beh lo firmi hai accettato di farlo ma qui arriva la parte più interessante loro siccome controllano github e questo è successo non non sto facendo cospirazione questo sono fatti che puoi andare a leggere su internet a un progetto hanno sostanzialmente preso gli hanno l'anno dal momento in cui questi hanno firmato gli hanno preso il repository e gliel'hanno spostato cioè non gli hanno mandato una richiesta perché loro hanno hanno l'aminta hanno accesso da admin no quindi gliel'hanno spostato e poi a un certo punto la la executive director del quindi la ministra amministratore delegato la ministratrice delegata della della dot ne foundation ha mandato una pull request al progetto e se l'è mergiata da sola ma lei non aveva accesso di scrittura repository altrimenti non aveva mandato la pr avrebbe semplicemente committato 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ò queste sono il genere di cose che chiaramente da un fastidio a chi fa open source perché il tuo progetto a me fa già strano che questi ti chiedono metterlo in sotto la loro associazione però sotto l'organizzazione di github però poi quando arriva la gente che a cui non hai dato diritto di scrittura che prendi ci scrive dentro ancora un po peggio questo è per dirne una la le compagnie di software non quelle grosse non non sempre è ben chiaro cos'è l'open source e rispettare tutti i canoni open source quindi a volte fanno un po quello che devono dall'altro lato dal lato dei progetti open source che forse non non fanno tutto quello che dovrebbero fare mamma mia io ho un esempio quando l'ho scoperto questa cosa sono rimasto esterrefatto gimp hai mai usato gimp? non riuscivo a smuttarmi 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 a agosto credo dell'anno scorso nessuno dei contributori 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 erano si erano affibbiati alla known 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 known foundation potevano solo essere utilizzati per organizzare eventi e comprare nuovo 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 che adoro posso dire una cosa gli ascoltatori di github bar 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 questa tema su questo topic allora qualche tempo fa mi ero preso bene da tutta la parte del fediverso no ho poi sono andato a esplorare un po quel mondo e ho detto vabbè noi siamo sviluppatori ok noi usiamo github noi usiamo github ma perché le issue e le pure quest 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 poi mi son fermato e ho detto ma cazzo git in quanto concetto è decentralizzato no di per sé è decentralizzato e perché a e apro una parentesi 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 pure quest 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 ci proibisce di utilizzare i concetti core di git per costruire delle dinamiche di pure quest 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 delle delle delle dei grandi progetti open source no di mantenere dei grandi progetti open source e gli ho fatto questa domanda gli 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 che mi dicono è sì va beh ma git è decentralizzato quindi domani se se se se se microsoft mi taglia i rubinetti o se atlassian mi taglia i rubinetti o se gitlab mi taglia i rubinetti o lo sposto da un'altra parte vero però tutta la conoscenza delle issue delle pure quest e quella la trasferisco sì va beh ma se ti tagli 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 questo 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 su su su concetti meno politici possiamo dirlo abbiamo perso un po quella quella militanza quella e perdendo la militanza la cosa si è esasperata probabilmente arrivando a farci perdere quella che è la anche la consapevolezza sì mi torna credo anch'io c'è 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é github è così perché son startup han preso investimenti e il protocollo non ti permette di catturare valore non ti permette di tornare l'investimento no moltiplicato al venture capital che ti ha finanziato effettivamente tutte queste piattaforme hanno interesse a differenziarsi a venderti i servizi a pagamento centralizzarsi a creare a diventare grosso e poi costruire il fossato che è un po come 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 github e github sono forse le ultime compagnie che possono mettere github nel nome nel creare un prodotto a pagamento dedicato a github perché mi pare che le guideline del trademark di github ad oggi non permettano a terze parti di creare prodotti con github nel nome ma essendo github e github preesistenti prima di queste guideline sostanzialmente gli è stato dato un nasce 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 industry è cresciuta più veloce della sedimentazione dei nostri valori politici e ci stanno un botto di soldi perché un altro dei problemi è quello fondamentalmente sicuramente comunque adesso dopo dopo aver fatto insomma mi sento un po 68 no dopo quello che ho detto però in realtà è importante quello il fatto di fermarsi un attimo e provare a riflettere non di io io cerco di essere più moderato possibile non dico che microsoft e google sono facebook sono diavoli a tutti i costi però secondo me la vera responsabilità è la nostra che dobbiamo saper discernere e capire cosa sta succedendo specie se siamo dei dei dei maintainer passiamo per un attimo a zig comunque questa cosa avremo modo di discutere la più a lungo anche di persona ci conto o 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 fatto ho studiato informatica qua milano la mia specializzazione bioinformatica in teoria poi in realtà ho fatto la tesina della triennale a tema ma poi non ho mai fatto più nient'altro di bioinformatica e in generale ho sempre fatto lavori di programmazione di tra virgolette 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 giulia 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 sharp go mi è piaciuto c sharp un po meno non per il linguaggio per l'ecosistema e 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 stantie ovunque vuoi c'è un cuore di cose che vale la pena sapere da informatico io non mi vedo come adesso quando all'estero mi vedo come ingegnere del software che è quello che fanno tutti però da italiano non avendo non essendo un ingegnere mi fa strano definirmi un ingegnere no quindi continuo a pensare a me stesso come un informatico però allo stesso tempo a voler essere un a voler dire 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 di c buona fortuna devi sapere tutte le magagne relative a c devi sapere tutte le magagne relative ad autotools del make c make poi ups questo progetto ha per qualche motivo deciso che un file un header file di c viene creato da uno script perl perché queste cose esistono ovunque ed è sostanzialmente un incubo alla fine della fiera il mio problema e non è che non volevo imparare le robe di basso livello ma che ho sempre ritenuto che il costo la frizione nel farlo non poi non valesse la fatica perché poi non avevo non ho mai avuto bisogno professionale di farlo chiaro e quindi dici in dici quando ho incrociato per strada zig alla fine tutta questa complessità che vedevo un po si è si è disappannata ma allora la domanda è semplice cosa porta zig nel nel system programming si beh porta principalmente semplificazione faccio un esempio parlando sempre di problemi tragici di c e c degli ecosistemi di cc più più 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 più più ma più importante 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 lo puoi fare questo è molto più realistico come esempio e questo ha valore a valore perché a 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 sia i dedicata per ogni singola cosa se provi a fare questa cosa con se io se io ti do gcc è un progetto e basta mi 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 e compilatore poi se in mezzo c'è meiko si meica è incredibilmente complesso in zig quello che fa zig e 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 a tutte le versioni di g lib c quindi la libreria standard gnu c'ha tutte le versioni di quella così che puoi fare target di una versione specifica a muscle che è un'altra libreria di c importante aglier della libreria c di meko s aglier della libreria c di windows a min gw sostanzialmente e quindi grazie a questo fatto perché questa roba se non 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 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 quali sono state le challenge e qual è stato poi il tuo percorso di crescita professionale per arrivare a utilizzarli 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 non è non sto cercando di venderti l'idea sono lo farei io me stesso senza dubbio che scrivere ad esempio un sito web in un linguaggio come zigo o un linguaggio di basso livello non è un'idea così terribile non è così tanto peggio quanto farlo non lo so in go e se il linguaggio ti piace di più tutte le cose in più qui devi pensare di un linguaggio di basso livello non sono terribili e anzi la volta la singola volta che ti serve un controllo più preciso su una singola cosa a quel punto 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 1 la differenza tra stack e heap questa sulla sulla carta non è difficile da capire di un esempio forse un po comico di della mia università qua a milano la bicocca primo anno primo corso di di programmazione introduzione lo stack e heap e poi abbiamo iniziato a fare java dove in java non hai nessun controllo di cosa va dove non 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 erognoso è un è come quando un io si sveglia per la prima volta fuori da matrix ti fanno male dei muscoli perché perché non le 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 pensi all'inizio con il cobol a scuola php javascript passato typescript e adesso sto provando sto provando a studiare nel tempo libero bambina permettendo rust perché perché voglio spostarmi più a basso livello perché designing data intensive application mi ha fatto venire le sci la scimmia di capire come funzionano a basso livello i database e 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 no leggendo il libro di di rasta ho detto a vedi alla fine da qualche parte torna lo stack e lì e in realtà vederlo su rasta 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ì abbiamo no e siccome ha parlato di stop di stack e ip voglio chiederti in realtà una delle cose diciamo che solitamente scattenano e infiammano il mondo dei dei dei system dei linguaggi di per la system programming noi linguaggi come può essere rasta c zig gestione della memoria in realtà io studiando studiando rasta sto facendo a cazzuti col borro checker ok sicuramente tu tutte le persone del mondo che che sentito che hanno utilizzato rasta i cazzuti col borro che crea l'inizio le fanno sempre come funziona il sistema della gestione della memoria di zig dunque zig non ha un borro 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 viene consigliato di fare in zig allora sicuramente non avere il borro checker non ti protegge contro certi tipi di errori di gestione della memoria che rasta fin tanto che non apri blocchi unsafe assolutamente 100% ti proteggerebbe da però dall'altro lato quello che quello che in generale ci si aspetta è idiomatico in zig e 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 locator in italiano non so non sono neanche sicuro di quale la traduzione perfetta però quello che fa una arena locator è sostanzialmente dire immagina che tu hai torniamo a parlare di siti web tu hai 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 ti chiede una pagina client b si connette ti chiede un'altra pagina magari entrambi ti richiedono di far 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 a essere indipendenti e non solo una richiesta di solito non lascia rimasugli tu risponde alla richiesta ma quando finito risponde alla richiesta torni al punto diciamo di partenza dove nulla è cambiato all'interno dello stato del server o se cambia qualcosa cambia qualcosa nel database quindi sotto questo punto di vista ad esempio se tu facessi un database scusami un server web in zig e quello che faresti è che che ad ogni handler ad ogni request handler passi un arena locator quello che fa la rina locator è un concetto semplice e molto elegante semplicemente ti permette di allocare sul lib tutto quello tutto quello che vuoi e quando arrivi alla fine non devi fare free non devi liberare ogni singolo oggetto quello che fai è risettare l'arena e questo è molto performante faccio un esempio direttamente opposto di cui di quello che è l'arena immagino quando chiudi visual studio 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 rai pattern con tutti i distruttori dove alla chiusura ogni singolo oggetto vuole distruggere se stesso e se tieno il prezzettino tutto viene liberato tutto si sgretola nell'arena non fai così quando hai un arena locator quello che succede è che tutte le cose vengono tra virgolette liberate in blocco perché hanno per dirla in termini di rast 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 zig ha la loc ogni allocazione di memoria e 100% esplicita non c'è una non c'è un allocator globale implicito come in c e non ci sono feature del linguaggio che implicitamente allocano per te che è un'altra cosa carina perché faccio un esempio se hai un sistema che è sempre sotto grossa pressione di memoria in zig poi sempre non capita hai sempre l'opportunità di dire prova da 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 dei 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 della della camera da letto perché ci stiamo spostati in soggiorno nella camera da letto abbiamo lasciato i cartoni delle pizze le bottiglie di birra vuote passa e ripulisce no su su rast invece immaginiamo che ci sia questo cerimoniale tale 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 forse si merita anche scusami hai ragione io sono decisamente salato troppo avanti perché passo troppo tempo in questi ambienti forse si merita anche un'escrizione migliore perché quello che farà se veramente figo quello che farà ste perché garbage collector tendono ad avere un costo no ci mettono la signora del pulizie ti chiede di uscire dalla stanza quando pulisce tra virgolette invece in rast questo non succede perché rast sa dove liberare la memoria quando compila cioè mentre compila sa qual è il punto giusto per liberare ogni singolo oggetto esatto quindi immaginiamo che sia della della mondezza e delle confezioni di pizza che si autodistruggono dopo che sarà perché utilizzando una cerimonia sa che non servono più in un certo momento invece un po dovendo usare una una un'analogia no zig è un po come tu lo fai per te quindi decidi spostarti in camera di utili e di buttare poi il cartone oppure di incendiare completamente la stanza e alla fine vuotano e con l'arina dello che torno sì questo è decisamente una buona maniera per descriverlo voglio dire se ogni volta è come una stanza di hotel no tipo in un in un il centro web server è una stanza di hotel e scusami il tuo berser è un hotel ogni richiesta stanza di hotel e si dai poco a tutto e poi rimetti dentro tutta la roba nuovo quando arriva una nuova richiesta esatto molto fighe questo modo di rappresentare la gestione della memoria bello bello bello e 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 a fianco e usa e all'epoca usavo python o javascript se dovevo usare django che è fantastico python altrimenti javascript per altre cose però in nessun di questi due linguaggi quantomeno all'epoca aveva l'opportunità di mettere scrivere giusto atticamente 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 rifatto in un cambiamento introduceva una tonnellata di errori di tipi e li potrei solo scoprire runtime quindi sicuramente i tipi aiutano quando il progetto è grosso e poi lavorativamente ho iniziato a lavorare 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 apri gli occhi sparisce tutto no perché typescript è quello cioè un sistema di tipi finto perché poi alla fine non esiste e è 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 in davanti a grandi codebase 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 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 allora trattare i tipi come valori vuol dire che tu vuoi prendere una definizione di un tipo una definizione di un astract 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 in ad esempio rast e cppu sono quelle cose che loro chiamano constexpr o termini simili e per farci un esempio se tu hai da qualche parte la tua beneamata funzione fibonacci che non può mancare in nessuna code base se da qualche parte tu scrivi non so che const fu uguale fibonacci di 5 quella chiamata fibonacci di 5 non c'è motivo per il quale non possa venire non possa essere risolta una volta sola mentre compili senza doverla ricalcolare ogni volta run time e questo in generale quello che fa zig quello che zig fa che è più uno step oltre e 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 run time perché a run time zig non ha un run time non ha un faccio un esempio quando tu fai partire un programma javascript c'è tutto il run time 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 di tipi evapora dall'eseguibile finale una struttura in c sono dei byte con uno set di primi due byte sono non lo so il primo membro della struttura di altri due byte sono il secondo membro dell'astracto qualcosa del genere e questa cosa non è non è un non è una cosa dove il programma può ragionarci a riguardo normalmente zig sotto quell'aspetto è come c è come rust anche lista anche rust stessa cosa non c'è informazione a run time non c'è un run time neanche per rust che è una caratteristica di questi linguaggi di basso livello ma in zig quello che poi però mentre compili invece questa informazione c'è mentre compili tu puoi ispezionare informazioni relative a un tipo puoi chiederti se questa variabile è di tipo puntatore o è di tipo array o di tipo strut o no che faccio un esempio gente che è abituato a scrivere magari in go e quel genere di programmazione con reflection che puoi fare anche in go ma in go viene fatto tutto a run time perché go è un linguaggio che ha un run time che tiene informazioni sui tipi in zig tu non lo puoi fare a run time ma quello che non puoi fare a run time lo puoi sicuramente fare a comp time e da qui da noi nasce i tipi generici 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 può invocare a run time quindi non puoi mettere quella funzione in una posizione dove dipende faccio un esempio dall'input dell'utente non ti compilera mai in zig però se quella funzione però se ad esempio tu 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 una particolarità di zig tra l'altro è che zig non ha macro e venendo da rust sono abituato a vederle no e mi chiedo non avendo macro in realtà con che cosa le si sostituisce cioè come lo posso spiegare 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 un qualcosa di più ampio sono sicuramente paragonabile alle macro sotto certi aspetti sono diciamo così la differenza principale credo tra compile time e i sistemi macro è che quando tu pensi a una macro la macro agisce sulla sulla sintassi del linguaggio e lo puoi fare in maniere migliori e peggiori la maniera forse peggiore è quello che fa c le macro di c sono cerche sostituisci e da quello ne derivano un sacco di problemi sia di comprensione sia di quelle che vengono chiamate food gun quindi di conseguenza inattese di conseguenze inattese dall'uso della funzionalità e poi sicuramente farlo meglio che quello che fa rust dove rust non ti permette di sostanzialmente fare output di sintassi sbagliata di rust cosa che puoi benissimo fare in c rust se non sbaglio agisce sostanzialmente sulla st sulla abstract syntax tree e quindi ti assicura che certe cose che ti possono capitare in c non ti capitano in rust io 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 metaprogrammazione adoro abusare le macro in lisp l'ho fatto però proprio perché adoro la metaprogrammazione 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 sarebbe e preferibile non dover fare e comptime ti permette questo perché tu con quando fai comptime in zik non stai manipolando la sintassi del linguaggio stai manipolando dati stai manipolando un tipo che 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 della struct che è un altro tipo dove dove tipo c'è un enum e il valore enum ti dice se è una se quello che stai ispezionando è una struct un array o qualunque altra cosa e tu fai queste cose con manipoli questi dati con i normali costrutti del linguaggio zik non ha un secondo linguaggio quando tu hai generics quelli tra le parentesi angolari in java c sharp ad esempio il linguaggio che puoi usare tra le parentesi angolari è un sottolinguaggio 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 permette di fare poi puoi portarlo molto avanti ci più più il sistema di template con che puoi usare sostanzialmente e che è un po più è ben più potente dei generics normalmente però anche quello ha la sua serie di problemi quello che è molto bello di zik è 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 metà programmazione 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 una bella puntata sulla metropolitan che vi metto nelle note dell'episodio tra l'altro sempre per rividenziare la centralità del linguaggio anche nel 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 dei dei file toml o di un formato particolare ma sono dei veri e propri file di codice zig perché questa scelta secondo te? 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 impararsene doversene imparare tipo 20 di cose di terze parti perché il progetto parte con make file ma poi ups vogliamo andare su windows ma windows non c'ha make allora buttali un file batch ok ma io 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 a 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 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 è che il tuo progetto rust deve davvero magari non lo so 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 zigg 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 le 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 comando che è zigg build 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 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 tutte queste pezzettini per te no quindi dovrebbe scrivere quella definizione o fare un lavoro equivalente per ora non c'è e quindi te la devi scrivere 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 sono stati creati giusto per provare per vedere com'è quello siamo tutti aspettando il package manager ufficiale senza dubbio ma arriva arriva tra qualche mese.

Cool.

Tra l'altro pensavo a una cosa tu hai nominato più volte c e c più più no? 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 no e ho visto su più posti specie su Reddit no questa associazione molti dicono che ZIG sta a c come RAST sta a c più più cosa percepisci cioè secondo te perché porta le persone a dire questa 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 più più puoi trovare sicuramente il programmatore RAST che non è d'accordo però dettagli a parte e sto citando questo perché facendo comunicazione su ZIG di lavoro chiaramente mi imbatto in queste persone sempre al momento più inopportuno però in generale tendo allora sicuramente si può fare una descrizione più sofisticata ma come punto di partenza io tendo a essere d'accordo l'idea di base è che RAST è 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 borrow 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 RAST 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 e in generale lo stile sai c'è questa idea in RAST che forse questo è un termine addirittura che RAST ha popolarizzato che l'idea delle zero cost abstraction in ZIG nessuno crede che le zero cost abstraction esistano o meglio forse è meglio che spieghi meglio il concetto così che sia il mio punto di vista.

L'idea delle zero cost abstraction in RAST è 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 RAST che ti permette di scrivere codice più facilmente ma che non ha un costo a run time 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 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 RAST 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 è che il problema delle astrazioni è che costano magari non a run time però costano in termini di complessità il codice diventa più difficile da leggere diventa più meno ovvio.

E poi anche costa anche in performance di debug perché cose come i terratori magari spariscono dopo che tu fai una release quindi fai una build di release con tutte le ottimizzazioni ma quando fai una build di debug tutto è molto più lento e tanto più astrazioni usi tanto più è lento e magari in certi casi non c'è problema e tutti sono contenti ma se tu stai magari sviluppando per esempio un videogioco la tua build di debug del videogioco deve più o meno girare altrimenti è un incubo da debuggare e altrimenti ti trovi a dover scegliere un frame al minuto oppure l'applicazione esplode e io non ho la minima idea di perché esplosa e 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 quanto meno 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 puoi prendi quella libreria non 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' 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 C++.

Hai per un attimo toccato il mondo del game development e mi è sembrato di vedere in realtà qualcosa c'è qualcosa di significativo cioè possiamo fare game development con Zig? Sicuramente ci sono un paio di esempi carini che di recente c'è stata la WASM4 Game Jam.

WASM4 è un'idea veramente carina e 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 WASM4 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 quelle onde a sega o 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.

Mi ha incuriosito.

Assolutamente.

Wasm4 è molto carino su 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.

Rust era molto rappresentato però era sotto zig e c.

Questo è un esempio poi la sovra rappresentazione.

Zig è molto più piccolo di Rust.

La sovra rappresentazione di zig nella jam di Wasm4 in particolare perché ci sono un po di fissati nella nostra comunità che adorano fare questo genere di cose.

Un ultimo esempio secondo me rilevante è che ci sono delle persone che stanno lavorando a un framework per fare videogiochi.

Ci sono più di uno però uno in particolare che va nella pena dargli un'occhiata si chiama Mac Engine ed è questo framework per fare videogiochi improntato a essere multiplatform.

Quindi è in grado di offrirti una finestra e un buffer dentro qui disegnare.

Sia se tu stai compilando per Windows, per Linux, per Mac, per WebAssembly farlo andare con la WebGPU.

La programmazione di videogiochi è 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 tutti per filo 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 ho visto che hanno fatto il fan cop-op del fondatore del creatore di C++.

No davvero! Oh mio dio! Detto questo, sto aspettando quello di Kernigham Ricci dai vecchi tempi dell'università, detto questo a oggi nello spazio per questi linguaggi di system programming abbiamo Rust, abbiamo Go, abbiamo C e poi abbiamo Zig che è un linguaggio abbastanza giovane in realtà.

Sono andato un po' a guardare come è nato.

Fondamentalmente i primi commit risalgono al 2015.

Come fa oggi un linguaggio così giovane a ritagliarsi il suo spazio? Non è facile.

Io credo che quello è un problema che mi che mi pongo anch'io.

Addirittura io me lo pongo in una maniera estremamente più cinica.

Sei pronto per un'avventura? 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, ma io ad oggi personalmente di tutti i prodotti legati al mondo delle blockchain che ho visto non ne ho trovato uno che mi interessasse personalmente e quindi rimango un po' scettico della tecnologia.

Benché sia uber 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 in 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 della maggior parte di queste cose e quindi io stesso mi sono posto questa domanda e 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&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 progetti C, è 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 e stai già usando una libreria C, proprio import del punto H della libreria C, si è 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 dei 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? Eh non mi interessa, Google? Non lo so, però ci sono aziende tipo io adesso che 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.

Vero, 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, 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 il 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 data sheet 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 e questo altro.

Tutte queste informazioni sono, come dicevo, cambiano da controllore a controllore e ci sono questi progetti che praticamente 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 Zig 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 le cose che ha guadagnato provando a fare Zig e in generale quella che è stata la qualità dell'esperienza.

Però dall'altro lato, parlando a 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, non lo so magari salvi i cavi, però poi tutto lo stack lo controllano loro e chiaramente c'è l'offerta cloud relativa, no? Perché chi non vuole mettere nel cloud i propri dati? E 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? In quell'ottica secondo me sicuramente sì.

Se un gruppo di programmatori C in particolare che immagino il motivo per il quale continuino a usare C è magari un po' per dipendenza e un po' perché gli piace lo stile di programmazione C, secondo me possono provare Ziggy 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 è un'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.

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.

BAN ha portato un sacco di attenzione, un influsso molto grosso di gente nuova che è 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.

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 devi 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, Bann ha portato un esempio di un progetto che...

Bann ha preso anche dei finanziamenti da Venture Capital poco 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 programmazione di sistemi nel 2022.

Adesso però io devo fare un po' lo stronzo della situazione.

Qua siccome siamo in un bar la mia domanda sarà facile.

Quanto del successo di Bann 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 è fiondato 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 e inizi a concatenare tutto assieme.

Io avevo un blog scritto in Gatsby e il mio blog che aveva, non lo so, 10 post, 15 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 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.

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.

Non esiste.

Utilizzabili per i test.

Beh, cacchio, se tu ti studi 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.

Addirittura parlavamo di Ban fino a un attimo fa.

Ban ha preso degli investimenti e Gianluca ha iniziato ad assumere.

Ricordiamo la sua offerta di lavoro.

Sì, ha imparato un sacco di cose relative a Twitter credo dopo aver postato quell'offerta di lavoro con dei toni un po' aggressivi.

E quasi ai livelli di Elon Musk su Twitter.

Sì, però se sei uno sviluppatore Zig, se sei una delle, non lo so, poche centinaia di persone che ad oggi sa programmare in Zig, hai un vantaggio.

Sicuramente, chiaramente un programmatore con la necessaria esperienza nell'ecosistema prende Zig, lo impara in due settimane ed è a posto.

Quindi, diciamo così, il tuo vantaggio non è un vantaggio universale soprattutto.

Però comunque, sicuramente questo, la tua rarità ad oggi ha un effetto 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 all'ascesa 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, se vista che ha dovuto sviluppare l'interopperabilità, se no domani lo usavano Dino.

Però è molto divertente, no, perché è uscito Ban che ha promesso tutte queste cose, non so quanto è passato, dieci giorni forse, e Dino ha fatto l'annuncio 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, insomma, la necessità di monetizzare in qualche modo una cosa non più monetizzabile come era Node, 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 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.

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 Node è ritornato indietro in alcune parti, basta guardare le conversazioni tra Jared e Matteo Collina, gli sfottò, dove però il team di Node è andato a ottimizzare alcune parti che erano un po' trascurate.

Quindi diciamo che anche la concorrenza aiuta da quel punto di vista perché Node 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 la community? 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 tra le regolette sulla pelle credo partendo dalla mia esperienza a Redis Labs quando ho conosciuto Salvatore e continuando alla Zig Software Foundation.

Punto fondamentale, la 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 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 spaventando e 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 le 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ò però è vero la gente quando si incacchia su twitter si incacchia di brutto e queste cose hanno conseguenza soprattutto quando uno scontro culturale esempio da italiano io ho certe cose americane 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 il palco che tutto quanto sia il palco e non esista niente al di fuori e questo è problematico è problematico a sua volta.

Verissimo, quando si approccia in un mondo internazionale questa cosa si percepisce è veramente 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 nei package manager però è molto consigliato semplicemente scaricare l'archivio e non ha dipendenze quindi lo estrarre 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 sono indeciso tra Rust e Zig, io di solito dico prova Zig un weekend e prova Rust un paio di settimane dove l'idea è che in Zig un weekend ti basta a vedere e essere pericoloso con il linguaggio, in Rust forse ti ridi un po' di più comunque sia quindi non è molto 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, c'è 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 è ancora versione 0.10 che sta per essere rilasciata ad oggi a breve non c'è sfortunatamente un libro che dici ah voglio almeno io non lo conosco e quindi in generale quello che ho fatto io quello che fanno le altre persone che si avvicinano a Zig e 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 Zig che 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, lip perché 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 tra...

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? Si con la g Rustlings è 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 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 a essere molto introduttivi ma noi non ci facciamo mai problemi a rubare idee che sembrano buone ad altri linguaggi e ecosistemi c'è ZigLinks che può essere una buona introduzione a Zig senza troppa fatica assolutamente sì 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 GitBar 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 è ciò che reputano importante e carino condividere con la nostra community.

Loris hai qualcosa da condividere con noi? Ho qualcosa da condividere con voi sì anzi allora Mauro tu sei di Ovio giusto? Sì io 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 da 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 è un 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 tradurre però in realtà il contesto generalmente vi aiuta a capire anche cosa si intende anche se non sapete esattamente quale è la parola e poi una volta che 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 ascoltate non non aprite questa canzone davanti a vostra madre davanti ai vostri figli se siete di quell'età ascoltate privatamente nella calma possibilmente con le cuffie con le cuffie si bellissimo mi hai riportato in mente guarda un storia fa parte delle nostre radici culturali ci sono i minir inuraghe c'è mc cavallo si è iniziale ai canosa che sono no è buttateci un orecchio sicuramente io ho anch'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 rasta vedremo tra un mese cosa ne avrò combinato il mio voto finale cioè sono in grado di usare rasta solo se entro il mese prossimo riesco a riscrivere il programmino che scrive gli mp i capitoli nelle mp3 del podcast lo porto da da typescript a rasta quindi se ci sono buono ecco vuol dire che ci sono riuscito e nel frattempo la sera quando sono sul divano sto guardando una serie di video vi ha detto sono 180 190 come sono un po si chiamano isi rasta e toccano praticamente quasi tutti gli angoli del linguaggio quindi per chi vuole approfondire secondo me è uno di quei punti insieme a rasta in action da buttare un occhio fan fact ci sono sia in inglese che in coreano se se se mi piace loro isti faccio una una una domanda se qualcuno volesse trovarti sulla rete dove ti trova io perdo un sacco di tempo troppo su twitter mi trovate a ette croll oris quindi cognome nome ho un blog personale cristo con due f.it dove scrivo ma abbastanza regolarmente di lamentandomi di del mondo pensors e spiegando concetti di zic e ultima cosa sono su twitch il nome del canale cristo underscore it perché non potevo prendere il nome che volevo però se andate sul mio blog e 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 loris super piaciuta grazie di essere venuto a trovarci loris grazie per avermi invitato questa è la prima comunità in italiano della italiani di programmazione per davvero sono 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 help desk perché crediamo che in realtà lo stimolo sia molto più efficace della risoluzione stessa del problema questo è un po un po la nostra la nostra visione loris come noi solitamente diciamo siccome kit bar è un bar non l'effetto che andiamo a ricostruire l'effetto da birretta post conferenza diciamo che il nostro bar da oggi è anche casa tua o già gioinando quindi vienici a trovare quando vuoi c'è una birra sempre fresca per te assolutamente appena giornato il canale di telegram loris io ti ringrazio nuovamente per esserci venuto a trovare a nome mio a nome di tutta la community e do appuntamento alla prossima settimana ciao ma che stronzi questo programmatore telefono a quelli di metri a cambridge.