Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio.L'episodio di oggi è registrato in condizioni praticamente critiche, nel senso che io sono ancora in viaggio e non sono riuscito a trovare un modo per avere una connessione abbastanza stabile per appunto fare registrare questo episodio con i miei compari di viaggio.Però non volevamo mancare il nostro consueto appuntamento seppur in ritardo con appunto uno degli episodi del nostro podcast.Di cosa parleremo oggi? Alla ho voluto fare un gioco, ho voluto chiedere ai miei compari qual è il loro linguaggio preferito di molti, anzi di tutti conosco insomma qual è, però era un modo carino per condividerlo con la nostra community e soprattutto condividere quelli che sono le particolarità del linguaggio è perché lo apprezzano, quindi una specie di piccola autoanalisi quasi di coscienza.Quello che appunto sentirete tra qualche minuto sono le risposte che Alessio, Carmine, Mattia, Andrea, Leonardo, Luca e io hanno dato appunto a questa domanda.Ma prima di passare appunto ai vari interventi, il mio ruolo, anche palloso, è quello di ricordarvi rapidamente i nostri contatti.Info che ho c'è la github.it, @brennrap su Twitter e il nostro famigerato gruppo Telegram che ha appena sfondato gli 800 partecipanti.Quindi siccome molti di voi ancora non si sono iscritti e io vi vedo perché in realtà mancano diverse centinaia di persone nel gruppo Telegram, centinaia di persone che ascoltano il nostro podcast, allora vi chiedo se non l'avete fatto facetelo perché dentro il gruppo Telegram succedono le cose più fighe di Gitbar, quindi che state a fare? Aspettate! Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack 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 Non ho mai fatto grande mistero di quale fosse il mio linguaggio preferito però oggi voglio partire da un ragionamento a priori se questa domanda qualcuno me l'avesse posta dieci anni fa 15, facciamo quasi 20 anni fa probabilmente avrei risposto a ASP Classic ma l'avrei fatto giusto perché in quel periodo e in quell'epoca utilizzavo ASP Classic tutti i giorni e soprattutto perché era uno dei linguaggi che avevo scelto perché il deploy era facile quindi potevo mettere in Similproduzione/produzione qualcosa in modo facile accessibile nel senso che mi potevo permettere i costi di deploy a quell'epoca Aruba era comunque abbastanza accessibile con se non mi sbaglio attorno alla ventina di euro si aveva lo shared hosting e quindi la scelta del linguaggio veniva appunto dada da questa situazione.Però il driver vero di questa scelta e anche della vemenza con la quale avrei difeso questo linguaggio veniva dal fatto che vivevo in un giardino cintato, cioè per me quello era il linguaggio che utilizzavo tutti i giorni e che conoscevo e quindi per il quale avevo abbastanza informazioni per dire che era il migliore ma per dire che è il migliore si bisogna avere anche informazioni degli altri linguaggi bisogna conoscere o almeno aver buttato un occhio all'ecosistema che lo circonda e quindi era un modo di difendere il linguaggio un po' guidato da quella stessa sensazione, quella stessa situazione che ho avuto poi tanti anni dopo, qualche mese fa, quando ho deciso di abbandonare le macchine Apple per andare alla scoperta di nuovi sistemi operativi infatti quando si difende un linguaggio a spada tratte in modo così forte probabilmente, e non dico sempre, ma probabilmente spesso, uno dei driver è appunto dato dal fatto che si è all'interno di un giardino cintato, un po' appunto come succede quando si sceglie una macchina o si usa Mac o Windows per tanti anni, dove in realtà si conosce bene quell'ambiente e si accettano probabilmente anche i limiti perché non si conosce bene come li si può superare.credo che però una volta raggiunto un certo livello di seniority che vuol dire una volta aveva sbattuto abbastanza volte il muso sul muro e aver preso delle botte si riesce a capire che in realtà quest'approccio di tifo similcalcistico è limitato e va superato esattamente stesso approccio che si ha quando ci si incontra, questo approccio lo si vede quando si incontrano i fanboy di Apple.Per cui un modo per affrontare dal mio punto di vista il modo anche maturo il proprio linguaggio preferito è partire da quelli che sono i lati negativi.un'analisi partendo da questi lati ci permette di essere consapevoli di ciò che apprezziamo quindi di capirne i limiti, tracciarne il perimetro e quindi poi in funzione di questo coltivare l'amore verso il linguaggio che ci piace un po' insomma come facciamo nella relazione matrimoniale o di coppia, conosciamo il nostro partner profondamente, ne capiamo i suoi limiti e in funzione di questo sviluppiamo poi e possiamo apprezzare serenamente anche i lati positivi.Non ho, ripeto, mai fatto mistero del fatto che io ami alla follia TypeScript devo dirlo ma non ditelo in giro, secondo me TypeScript è un JavaScript che ha ha fatto un bel corso di galateo e sa come comportarsi in pubblico.No, seriamente, adesso cazzate a parte, vi voglio spiegare perché e che percorso ho fatto per poter prendere questo tipo di posizione.TypeScript potrei dirvi che è il quarto linguaggio per utilizzo da una statistica dell'anno scorso 2021 di github ma insomma vi annoierei a dirvi queste cose allora voglio come vi dicevo partire dai lati negativi intanto typescript presuppone che noi dobbiamo fare la appunto la traspilazione quindi la trasformazione tra typescript e javascript questo vuol dire che nel nostro flow c'è e ci sarà un step intermedio step intermedio che secondo me potrebbe essere evitato facendo in modo che l'interprete java script semplicemente ignori i tipi e tutto appunto le definizioni e l'utilizzo dei tipi di questo superset ma ancora non abbiamo niente di questo tipo a disposizione typescript e i suoi tipi in realtà hanno un altro limite che non esistono come mi disse Matteo Collina qualche tempo fa TypeScript non esiste è una roba che c'è nell'attuale mente io l'ho ribattezzata la proiezione mentale del tuo io digitale no? in realtà questo nasconde un tranello che bisogna saper maneggiare con cura cioè il fatto che io sì ho una definizione e un sistema di tipi ma questo sistema di tipi una volta traspilato il typescript in javascript sparisce questo vuol dire che le variabili o le funzioni possono prendere dei tipi inconsistenti per cui gli stati della variabile possono essere inconsistenti a runtime e questo appunto fa sì che si vedano i mostri a runtime.C'è da dire però che avere comunque un sistema di tweaking in un linguaggio dinamico ed utile come il javascript è tanta tanta roba.Un altro problema in realtà di TypeScript è che viene dal suo vantaggio in in realtà diciamolo cioè TypeScript eredita tutto l'ecosistema JavaScript questa cosa è molto figa perché l'ecosistema JavaScript è immenso e certe volte può anche essere overwhelming, sopraffacente, non saprei come dirlo in italiano, cioè ci può schiacciare e in realtà la stessa cosa può avvenire in TypeScript con un altro difetto supplementare che ereditiamo proprio dal sistema di tipi e che tante librerie e tanti tool e tante robe che ereditiamo da javascript in realtà spesso sono tipizzate col culo spesso ci sono definizioni di tipi fatte in modo superficiale giusto per dire supportiamo typescript spesso queste definizioni di tipi sono attaccate a sputo e quindi ci si ritrova davvero a dover fare dei magheggi affinché il nostro codice traspili e questo no buono ho visto cose tipo casting di tipo i fatti che ne so da numero a stringa to undefined to string cose veramente aliene e questo appunto spesso veniva ereditato da librerie tipizzate male.Detto questo però TypeScript è tanta roba, come vi ho detto eredita tutta la duttilità di JavaScript con in più un sistema di tipi abbastanza snello on top.Un'altra cosa figa che apprezzo è che essendo un full stack io scrivo spesso codice back-end e front-end e poter condividere back-end e front-end con un solo linguaggio mi è molto comodo, non dico che è il modo più performante per farlo, non dico che è il modo migliore in termini anche di qualità del codice, ma è il modo più comodo, quello che mi rende più produttivo e quindi lo apprezzo.E un'altra cosa che apprezzo in realtà è l'approccio in stile funzionale, non voglio utilizzare la parola funzionale perché presuppone presuppone un sacco di roba in realtà dico in stile proprio per questo motivo cioè io da quando sono ritornato a usare in modo pesante TypeScript e Javascript ho praticamente dimenticato le classi parte dell'Object Oriented Programming io credo di essere ormai un anno e mezzo, due anni che non scrivo non scrivo una classe ehm...il vantaggio vero in realtà di TypeScript lavorando in grandi codebase è che il check compile time mi salva la vita in questi ultimi due anni in realtà mi è capitato di lavorare ad alcune cose in javascript ho fatto delle contribution per alcune librerie Node.js dove in realtà il codice era scritto in javascript e non in typescript e quando il codice si complicava mi sono ritrovato veramente ad avere problemi nel navigare il codice o nel predire il tipo di una variabile, cioè cosa c'è dentro ma anche a navigarlo quindi leggendo il codice a predire cosa quella variabile conteneva mi possono dire "sì vabbè, ma perché il naming delle variabili non è fatto bene?" In realtà quando si esplorano delle codebase grandi, delle quali non si ha una conoscenza profonda, poter utilizzare TypeScript aiuta nell'esplorazione, perché una parte di informazioni sono rese esplicite e quindi questa cosa semplifica di molto e alleggerisce il carico cognitivo che si ha proprio in questa fase.In più diciamocelo, noi sviluppatori siamo pigri e io tipo sono il re dei pigri, per cui la Dev Experience per me è un elemento discriminante, Il linguaggio può non essere performante o essere performante quanto basta per raggiungere l'obiettivo ma io mi devo stare comodo quando sviluppo Molti potrebbero criticare quello che dico e avrebbero tutte le ragioni di farlo Molti potrebbero dire che questa cosa è una puttanata, dobbiamo fare del codice che funziona, che funziona bene, che sia performante al posto di costruirci un divano dove sederci comodi e concordo anche con questo però in fondo a me il divano comodo piace e quindi poter utilizzare TypeScript è il mio linguaggio comodo mi permette un refactoring facile mi permette di utilizzare tool come Intellisense in modo veramente funzionante specie in un ecosistema JavaScript credetemi molti possono dire "eh vabbè ma l'editor riesce a capire anche il javascript, riesce a dirti che questa roba è qua, riesce a farti navigare il codice cliccando sulle varie funzioni" sì ma non è lo stesso livello di esperienza, le ho provate entrambe e quindi mi sono pienamente convinto di questo e poi lo ripeto la cosa veramente figa è che avere un sistema più o meno tipizzato dove il più o meno dipende dalla quantità di eni e di un known che ci sono nel nostro codice e mi permette veramente di avere i benefit da da entrambi i mondi.Questa è la mia visione non è un'analisi completa e spero non vi stiate aspettando da me un'analisi completa perché probabilmente non essere neanche all'altezza di farlo però è è quasi una presa di coscienza e la cosa importante sulla quale voglio tornare è appunto il fatto di provare a capire il proprio linguaggio desso i limiti.Perché una volta che si riescono a identificarne i limiti si riesce anche a capire cosa c'è altro nel panorama, si riesce a capire anche come migliorare il linguaggio.Perché il linguaggio va migliorato da chi lo utilizza, chi ne ha l'esigenza e poter stimolare l'esigenza è sempre un elemento che fa crescere il nostro codice ma ci fa crescere come sviluppatori, fa crescere la community e fa crescere anche il nostro linguaggio.Beh ragazzi, già lo sapete, io sono quello del "usate jQuery per riconoscenza", quello che nella lotta dei framework io sono quello che dice "non usateli per cui cos'altro vi posso dire per farvi prudere le mani dal picchiarmi, cos'altro vi posso dire oltre al "keep it simple and stupid", scegliete un linguaggio semplice e un linguaggio che vi permette di fare quello che dovete fare senza troppi sforzi e senza troppi giri.Per cui non posso dire altro, ho deciso di usare questo mio spazio dedicato al mio linguaggio preferito per deviare un pochino il tema.Il tema principale forse è un po' per nostalgici, sì lo so ci siete, ci siete, siete tanti, siete tanti, forse siete anche troppi, lo so che ci siete.Il tema che voglio portare, vi siete mai chiesti come sarebbe stato Action ActionScript 3 oggi, si ActionScript, ActionScript ve lo ricordate più di 15 anni fa ormai il famoso flash, quello che ha portato il pane sulle nostre tavole di noi quasi boomer per tanti giorni.Ecco, forse non tutti sanno che dal 2005 un ragazzo francese di nome di Nicola Scannas, ha creato un linguaggio che era un superset di ActionScript 3.Il suo scopo era quello principalmente di traspilare codice in PHP, JavaScript, Flash stesso, C++ e Neko.Questo linguaggio lo ha chiamato "Hex" o "Hax" o come diavolo si pronunci in francese.comunque, "hex" credo che significhi "ascia".La cosa davvero sorprendente è che questo linguaggio si è evoluto col tempo e ancora oggi, ancora oggi, quindi nel 2022, parliamo che è nato nel 2005, nel 2022, è ancora vivo e vegeto, è mantenuto dalla Hex Foundation, è un progetto open source e non solo sopravvive ma ha anche aumentato il linguaggio del supporto quindi Java, Python, Lua, C# ed ovviamente non può mancare la parte mobile con Android e iOS questa parte qua l'ho provato un annetto fa se non sbaglio e funzionava funzionava, non ci ho fatto grandi cose però faceva il lavoro che doveva fare questo l'ho usato comunque hex, l'ho usato 6-7 anni fa credo per fare un giochino l'avevo usato con Neko mettendo come target un'applicazione Neko Neko è, per chi non lo conosce, non credo che qualcuno lo conosca comunque è un altro tipo di linguaggio dalla stessa filosofia di Lua, quindi è un linguaggio pensato di essere passato in modo efficiente dalla sua stessa VM e generato in modo semplice da qualsiasi altro linguaggio di alto livello, non è un linguaggio appunto pensato per essere scritto da un programmatore Quello che avevo fatto con Neko, anzi con Hex, che ha poi generato un file Neko, è stato un socket server multithread per gestire un gioco, appunto, una specie di chat dove la gente entrava, sparava, c'era uno bot, insomma, una roba fantastica che mi piange ancora il cuore.Purtroppo il client era in flash e non ho mai avuto tempo e voglia di rifarlo, quindi purtroppo il progetto l'ho lasciato morire, si chiamava Limbus.Comunque, alla fine questo socket server multi-thread è la cosa più stabile che abbia mai visto, aveva un uptime di due anni, non ha mai avuto sintomi di sconnessione o instabilità, è stato veramente fantastico, veloce, certo avrà supportato al massimo un 200 tenti contemporanei, però all'epoca, per le mie capacità soprattutto dell'epoca e per quello che c'era all'epoca penso che sia stato un traguardo notevole.Inoltre sostanzialmente è stato semplice da usare, qualche 7/8 anni fa non avevo nessun'idea di cosa fosse un target server multitread, però l'ho fatto e quindi questo dà un'idea e anche una misura della facilità del linguaggio.Quindi, se siete dei nostalgici e volete dare un occhio a questo linguaggio, ripeto, si chiama Hex, lo trovate sul sito hex.org, non è una marchetta, è una cosa che viene dal cuore, potete darci un'occhiata, perché no, nel 2005 è stato creato, Quindi si può dire forse che nel genere è stato quasi un pioniere di quello che poi adesso sono tutte le altre piatteforme mantenute e create dai vari meta di Google.ActionScript è sempre stato, scusami, Hex è sempre stato in una nicchia, però a quanto pare è sempre stato lì.Parliamo dal 2005, quindi sono ben più di 15 anni che è vivo e vegeto.Provatelo e magari fatemi sapere anche nel gruppo Telegram, non so se qualcuno l'ha già detto, lo dico io.Perché no, se avete tempo da investire, da fare, per provare, potete magari provarlo e poi fateci sapere.Ciao! Allora, eccoci qua.Mauro mi ha chiesto di parlarvi di un mio linguaggio a scelta, di un linguaggio che mi piace, che adoro e che tutto quanto.Quello che ho scelto io ne uso tanti perché ritengo che ogni caso d'uso abbia il suo linguaggio e che il compito di un programmatore sia in realtà quello di aggiungere frecce al proprio arco piuttosto che utilizzare l'approccio one size fits all che parecchi in realtà persone vanno sponsorizzando nei confronti di determinati linguaggi, determinati approcci, per esempio Vedasi, l'approccio ai microservizi eccetera diciamo molte persone vanno sponsorizzando tutto questo, io non sono per niente d'accordo.Fatto questo dovuto premessone, io di solito uso JavaScript per il frontend e per prototipare alcuni tool a riga di comando perché è velocissimo fare un tool a riga di comando con JavaScript, nonostante tutto, e nonostante escano 27 framework al giorno, uso molto Rust, ho usato Go, per quanto la mia esperienza sia stata non raw, sia assolutamente limitata e soprattutto in realtà per lo sviluppo web io utilizzo Elixir, che è il linguaggio di cui ho scelto di parlarvi oggi che tendenzialmente, giusto per andare un po' contro la premessa che ho fatto, per me riguardo il web è un po' one size fits all di tutta una serie di bisogni che io ho.Nel senso che, chiaramente, ci sono frecce migliori, ci sono assolutamente, quando abbiamo bisogno di performance spintissime, Sicuramente altri linguaggi magari possono dire la loro in quel campo, però Elixir effettivamente è nato come un better Ruby sotto questo punto di vista, soprattutto sotto il punto di vista delle performance perché al contrario di Ruby è praticamente compilato e gira anche esso, diciamo, come, che ne so, linguaggi come Java su una virtual machine che è detta Beam questa virtual machine ci permette di fare delle cose clamorose ma che vedremo in realtà tra un po' andiamo intanto a esplorare un po' di più il linguaggio che a me è la prima cosa che ha fatto appassionare a tutto quello che è in realtà un vastissimo ecosistema fatto di linguaggio fatto di persone anche, devo dire, cioè ci sono delle persone veramente super disponibilissime che personalmente mi hanno dato anche una spinta in termini di carriera in quanto a formazione.Ci sono persone che utilizzano elixir a cui è molto facile accedere diciamo per una chiacchierata con le quali è molto facile confrontarsi relativamente a tematiche su cui un senior engineer o uno staff engineer, insomma persone over senior, di solito rischiano di trovarsi un po' da sole, per esempio come si costruisce un sistema web con capacità di backpressure, eccetera eccetera.queste cose Elixir le fa praticamente in automatico e dato che le fa quasi in automatico, tra virgolette, è molto facile parlarne per le persone, perché determinati argomenti non costituiscono un tabù di fatto.Quello che a me piace in particolare di Elixir è che è espressivo e quindi praticamente Noi piuttosto che scrivere delle righe di codice imperative andiamo a dichiarare che cosa fare.È fortemente espressivo e dichiarativo.Che significa? Che noi andiamo a dichiarare che cosa facciamo e dichiarando quello che facciamo scriviamo delle espressioni che possono essere molto concise e molto potenti.In questo, purtroppo non abbiamo un mezzo video per farvi apprezzare, ma abbiamo un operatore che è quello di Match, che è praticamente l'uguale, che ci consente di fare pattern matching.Quindi a sinistra e a destra dell'uguale possiamo fare destrutturazione, come avviene in JavaScript per esempio.e possiamo in generale far sì che il linguaggio in qualche modo lavori per noi praticamente andando a modellare le nostre strutture dati in un modo che poi verrà automaticamente riconosciuto dal runtime stesso.Questo che cosa...mi rendo conto che è complesso ma praticamente in che cosa si traduce? Nel fatto che noi possiamo avere, tra l'altro questa è una delle feature che a me a livello di linguaggio piacciono di più di Elixir praticamente quello che andiamo ad avere è un...per esempio possiamo scrivere delle funzioni che hanno tutte lo stesso nome ma hanno una firma differente che cosa significa? Che, per esempio, possiamo scrivere una funzione che prende un parametro, la stessa funzione che prende due parametri, la stessa funzione che prende tre parametri e soprattutto possiamo definire queste funzioni con i parametri arcodati.quindi se il primo parametro è, dirò un'italianata per tutti quelli all'ascolto, se il primo parametro della funzione è "pippo", cioè definirò proprio una funzione che si chiama funzione(pippo) e poi gli altri parametri, nel momento in cui il primo parametro di quella funzione sarà "pippo", io entrerò automaticamente in quel caso.In questo modo praticamente possiamo scrivere funzioni e codice totalmente senza if.Questo è il più facile dei side effects perché nel momento in cui praticamente non andiamo più a fare il check se una cosa è null, perché praticamente all'interno della firma delle funzioni possiamo definire una funzione che è la funzione con il parametro nil e una funzione con il parametro che è arbitrario e a quel punto dentro il nil andiamo a fare un eventuale catch di un caso d'errore o di un caso particolare, un edge case che a noi interessa mentre nel resto della funzione andiamo a...nella seconda funzione a questo punto andiamo a scrivere quello che ormai per noi è il nostro Happy Pat perché il resto l'abbiamo tutto gestito attraverso delle altre funzioni dopodiché abbiamo parlato di espressività, di pattern matching Elixir è un linguaggio Ruby style, a me per esempio i linguaggi Ruby style non piacciono molto perché io sono molto affezionato banalmente alle parentesi graffe e mi piacciono molto esteticamente però effettivamente una volta che ci si fa l'abitudine è qualcosa su cui si passa sopra La cosa importante poi è che appunto, come abbiamo detto, Elixir diciamo si basa su Erlang, in realtà, che è un linguaggio che ha 20-30 anni, e in realtà transpila, compila il proprio codice nel bytecode di quella che è la virtual machine di Erlang, che è la BIM.All'interno della BIM poi succedono cose meravigliose perché la BIM è fatta per essere un sistema operativo in miniatura, multiprocesso, out of the box quindi possiamo andare...e soprattutto è distributed out of the box quindi se io ho due macchine virtuali Erlang che condividono quello che è detto segreto o cookie e le metto in comunicazione, quelle cominciano a parlare e nel momento in cui io faccio partire un processo in una maniera simile a quella dei thread per esempio su Java, all'interno della virtual machine di Erlang se sono collegate due macchine tra di loro e io uccido un processo da una parte, magari succede che dall'altra il processo ritorna a vivere.Questo ci dà praticamente, se non alta affidabilità di default, delle primitive su cui scrivere delle librerie, che sono appunto state scritte, che ci consentono praticamente di rendere la nostra applicazione un'applicazione data intensive di super alta affidabilità con pochissimo sforzo.di rendere la nostra applicazione distribuita con pochissimo sforzo, o meglio, con uno sforzo congruo perché in altri ecosistemi parlare di distributed computing, parlare di transazionalità distribuita è qualcosa che è quasi un tabù, non sentirete mai parlare di queste cose a una conferenza di un qualsiasi linguaggio se non andando proprio a pocare, non so come dire, a spingere sulla spalla a qualcuno che fa veramente queste cose di mestiere.Sinceramente da quando io per esempio ho frequentato un po' la community Elixir e sinceramente questi sono stati i concetti che sono stati praticamente affrontati senza paura in qualsiasi frangente, in qualsiasi discussione, soprattutto con delle persone estremamente easygoing.Adesso sentite lo smash della tastiera perché mi è andato in slip il computer e devo riprendermi la scaletta.Praticamente le persone sono estremamente easygoing, che sono estremamente amichevoli e quindi viene innescato un processo di mentorship da cui è possibile trarre solamente valore.L'ultima cosa che voglio dire, spero che se sia capito tutto il resto, è che proprio proprio grazie a OTP, proprio grazie a questo tipo di librerie e a questo tipo di facility, mi viene da dire, questo tipo di infrastruttura dentro l'infrastruttura, quello a cui noi abbiamo accesso, soprattutto quando si tratta di scrivere applicazioni stateful e, diciamo, motori stateful per applicazioni, Quello a cui noi abbiamo accesso è praticamente un'infrastruttura built-in in cui possiamo deploiare cose in memoria, interi datastore che possono leggere e scrivere solo in RAM.Oppure altro, per esempio mi viene banalmente da pensare a come funziona il collegamento tra le macchine virtuali Erlang, che praticamente evita, nel momento in cui poi facciamo partire questi processi, li chiamiamo attori e gli facciamo fare un compito quasi da microservizi, A quel punto abbiamo qualcosa gratis che ci tira giù tutta la necessità di gestire questo dal lato infrastrutturale e invece ci restituisce diciamo l'ejoado code, nel senso cominciamo a programmare dicendo ok, la macchina virtuale gestirà la disponibilità dei processi per me sicuramente è qualcosa che per esempio anche Kubernetes può fare però dobbiamo scrivere 6 KB di YAML per farglielo fare chiaramente anche la virtual machine di Erlang va configurata per fargli fare queste cose però una volta configurata effettivamente è molto potente e a quel punto, per esempio, se dobbiamo mandare un messaggio tra due o tre processi viene meno, per esempio, in quel caso molto banale, la necessità di utilizzare una soluzione come RabbitMQ che in quel caso magari sarebbe veramente come sparare a una mosca con un bazooka mentre in questo caso abbiamo per esempio la funzionalità di messaggistica inter-processo che funge proprio da meccanismo di default IPC della virtual machine di Erlang che tranquillamente ci dà quel tipo di funzionalità senza doverci tirare dentro casa 6 kg di infrastruttura solo per far comunicare due processi diciamo Siccome molto spesso in realtà le cose che vogliamo fare sono molto semplici, in realtà a me personalmente elixir ha permesso di ritornare un po' a quell'approccio semplice di non sparare alle mosche con il bazooka e invece adottare soluzioni semplici a problemi semplici Eccomi, camminando, sto andando a cena con Fabio Mora, tra l'altro.E il resto della gente lì be' in Apolux con la gente lì.Dunque, il mio linguaggio prefe'e, come probabilmente tutti sanno già, in questo momento specifico della mia storia è Kotlin.Per quale assurdo motivo e per quale serie di motivi? Partendo dal presupposto che c'è una puntata intera di Geekbar che lo spiega.Però, fondamentalmente perché io vengo da, boh, 15 anni e più di Java e Kotlin è come vorrei che fosse Java nel 2022.Java è un linguaggio non troppo aperto all'innovazione, nel senso che il runtime e il bytecode sono gli stessi di quando avevo ancora i capelli e tutto quello che c'è stato aggiunto on top è iCandy e Syntactic Sugar.Anche cose non banali, Ci sono cose molto belle nella sintesi di Java di adesso, però è perfettibile.Una cosa bella che è successa all'ecosistema della JVM negli anni è che sono usciti tanti linguaggi che compilavano nel bytecode della JVM.Groovy, Scala e quant'altro.Kotlin è l'ultimo e ha tanti pregi rispetto agli altri e rispetto al padre Java.Anzitutto ha un tooling molto ben fatto, nel senso che è un linguaggio sviluppato da gente che di mestiere principalmente fa gli IDE perché il team core di Kotlin lavora per JetBrains e sono gli stessi che fanno IntelliJ, per cui l'integrazione con l'IDE è molto forte e scrivere Kotlin dentro IntelliJ è davvero molto ergonomico.uno potrebbe dire che ti vincola a usare IntelliJ, però nel 2022 se scrivi della roba sulla JVM e non usi IntelliJ il problema è tuo.Detto questo, a livello puramente di linguaggio, puramente stilistico, Kotlin ha molti costrutti evoluti.E' molto bello perché tanta della standard library di Kotlin è scritta usando i costrutti evoluti che Kotlin stesso ha aggiunto al linguaggio, per cui, per esempio, Kotlin ha l'extension function, per cui puoi fare quello che di fatto è monkey patching di una classe, aggiungi delle funzioni a una classe, e la standard library ha una serie di funzioni di utility per le collection, che sono di fatto extension function.Per cui anche il codice della Standard Library di Kotlin è estremamente bello e pulito e istruttivo.E tra le altre cose, quello che permette la Standard Library di Kotlin è di scrivere funzionale in Java, o comunque in un linguaggio Java-like.Java ha più o meno dei costrutti funzionaleggianti, c'è un talk molto bello di Mario Fusco che spiega come scrivere funzionale in Java ed è molto prolisso.Scrivere funzionale in Kotlin invece è estremamente pulito, idiomatico, esplicativo e funziona bene, per cui diciamo che è un linguaggio che si presta a diversi stili di programmazione non ti forza, intanto sta passando il tram, non ti forza a usare, a scrivere nell'unico modo possibile, come altri linguaggi.Può essere una debolezza, nel senso che quando hai tanti modi diversi di fare le cose fai fatica a essere chiaro e rischi di diventare PHP in cui la stessa cosa la puoi fare in cento modi diversi, nessuno dei quali è standard.Probabilmente sì, però è vero che non sono nemmeno così tanti, sono un paio, sono il modo imperativo, dichiarativo, classico, quello oggettoso con i for e gli if, e quello funzionale con i map, i fold e i reduce.Per cui diciamo che è un linguaggio che permette un po' di creatività e di sentirti fico perché stai scrivendo le cose nel modo che piace a te, ma non è che è un linguaggio che ti permette di fare quello che vuoi.come, che ne so, JavaScript in cui puoi scriverla qualunque e l'interpreter te la interpreta.È un linguaggio col type system forte, con un type system molto bello, perché come avevo raccontato estensivamente nella puntata di GitBar in cui ne parlo, risolve il Billion Dollar Mistake di Java, che è quello per cui una variabile, quando la inizializzi è null, ha i tipi non nullabili, e quindi poi quando dichiari una variabile puoi dichiarare che quella variabile non sarà mai null e questa cosa è estremamente utile perché se avete scritto del Java nella vita sapete che il codice è spesso costellato di if variabile diverso da null, fai le cose, è una cosa che devi controllare e uno dei motivi poi per cui tutti ti dicono "eh, Java è prolisso, devi scrivere un botto di roba" perché devi sempre fare questo tipo di check.Quindi il fatto che Kotlin questa cosa la risolva alla base e by design è un bel vantaggione.I passanti che parlano, il type system statico, appunto ricordo che ne parlavo con Mauro durante quella famosa puntata là, a me piace molto, nel senso che il fatto che tu quando dichiari una variabile dica di che tipo è, anche se in Kotlin non è così stretto come in Java, e il compilatore ti aiuti un po' a fare in modo che che le cose siano del tipo giusto a me piace, nel senso che ti sposta un po' di bug fixing in fase di compilazione, anziché averlo in fase di esecuzione.Che altri motivi ci sono per cui mi piace Kotlin? Beh, perché è un linguaggio con cui puoi fare un sacco di cose ci puoi fare tutto quello che puoi fare in Java ed è first class citizen anche per lo sviluppo Android Ci puoi fare le applicazioni web con Jetpack, ci puoi fare Android ovviamente, ci puoi fare il machine learning, di recente ci sono un sacco di cose per fare machine learning in Kotlin.È un linguaggio molto ben supportato, nel senso che esce una versione nuova credo ogni sei mesi ed è un linguaggio vivo, non è un linguaggio che è sempre uguale e non cambierà mai, ma anzi che introducono nuove feature a un ritmo abbastanza forte che anche quello, ci dicevamo l'ultima volta con Mauro, potrebbe essere un po' un rischio nel senso che rischi che ti cambi il linguaggio sotto il culo però, tutto sommato, finora breaking changes non ne ho viste in tre anni abbondanti che ci lavoro ma miglioramenti invece molti e direi che questo è un po' tutto quello che ho da dire in breve sul motivo per cui mi piace Kotlin e ovviamente poi rimando tutti alla puntata precedente in cui raccontò la Rava e la Fava di tutto ciò per un'ora al povero Mauro che soffre ascoltandomi.Allora allora io mi riangaggio a quello che ha appena detto Alessio.Per tanti versi Elixir è un better ruby e nasce anche con quello scopo io parto comunque, voglio partire dal presupposto che uso Elixir, mi trovo bene con Elixir e tra un po' sarà anche il mio main language ma a questo punto se non avete davvero bisogno delle performance di Elixir perché non andare sull'originale? Quindi come avete potuto intuire, come magari qualcuno di voi già sa, il mio linguaggio preferito, diciamo il mio tool preferito è Ruby.Ruby e non voglio dire subioresto, voglio partire da Ruby.Che cos'è Ruby? Diciamo Ruby è un linguaggio di programmazione general purpose e sostanzialmente diciamo la filosofia che sta dietro Ruby è una filosofia complessa.Diciamo che possiamo a rassumerla in Ruby è stato progettato per essere uno strumento che porti gioia allo sviluppatore, al suo utilizzatore.È un linguaggio che è stato creato con una ben precisa ergonomia in mente e diciamo con dei principi che lo rendessero flessibile, fruibile e con una sintassi più espressiva possibile.Quando scrivo Ruby, se qualcuno di voi ha mai provato a scrivere Ruby, una cosa di cui ci si può subito rendere conto è che è facile scrivere dei pezzi di codice che sono dichiarativi e che sono altamente espressivi.Questa cosa che ovviamente la possiamo ritrovare anche nell'exil, che ha come ha già detto adesso una forte similità con Ruby per quanto riguarda la sua sintassi.Perché amo Ruby e perché vi consiglio Ruby? Vi consiglio Ruby perché secondo me è un linguaggio che potete apprezzarlo tanto scrivendolo e potete davvero divertirvi scrivendolo.Io personalmente non provo la stessa gioia e lo stesso divertimento quando magari uso altri tool e ne uso tanti.Io diciamo che faccio anche tanto frontend ovviamente con JavaScript, faccio anche tanto backend con Node e diciamo principalmente ora il mio main language è Go.Però diciamo con nessuno di questi strumenti riesco a ritrovare la soddisfazione e la produttività che ho con Ruby.Diciamo che il primo amore non si dimentica mai e probabilmente c'è anche tanto questo effetto nostalgia nel mio scegliere e lodare costantemente Ruby.Ovviamente non è il silver bullet, non è diciamo lo strumento con cui fare qualunque cosa, infatti ho esordito dicendo che utilizzate Ruby se non vi serve, se non vi serve quel tipo di performance.Ovviamente non si può non parlare di Ruby purtroppo senza parlare di Rails.Che cos'è Rails? Rails è un framework web, un framework web MVC che ha al suo interno tantissimi componenti per poter davvero diciamo avere un framework full stack completo e che sia veramente divertente ed ergonomico da utilizzare.Ovviamente anche Rails così come Ruby ha una sua doctrine, potete veramente leggere la Rails doctrine sul sito ufficiale di Rails e diciamo uno dei pilastri è che Rails è ottimizzato per la developer experience e soprattutto Rails ha scelto un approccio che è convention over configuration quindi se scrivete Rails in un certo modo ed imparate qual è la convention di Rails c'è molto meno overhead cognitivo nell'utilizzo e nell'integrazione con codice di terze parti perché se tutti aderiamo alle stesse convenzioni c'è molto meno spazio diciamo per la configurazione o comunque per la parte infrastrutturale, diciamo così, e ci si può concentrare sulla nostra business logic e sulle cose che possono portarci veramente valore.Quindi, diciamo, questa cosa qui va di pari passo con dei default che sono sicuramente o pignonati ma sono dei default che sono sensati, ecco, diciamo che il più delle volte integrarsi con una libreria fatta bene è veramente una questione di pochi minuti, ecco, poi ci si può concentrare sulla vera e propria business logic.Ovviamente tutto questo non viene gratis, Rails e Ruby per la loro flessibilità, specialmente Ruby come linguaggio è un linguaggio che un framework di metà programmazione potentissimo ed è proprio questa metà programmazione ad essere poi alla base diciamo della potenza di Rails come web framework ovviamente questa cosa si presta ad un abuso bestiale ho visto veramente le cose più brutte essere fatte diciamo in Ruby e Rails ho fatto delle cose bruttissime io stessi e Rails dove per bruttissime intendo che ho veramente utilizzato tutto questo framework di metà programmazione per fare delle cose che a prima chitto mi sono sembrate veramente fighe però poi si trasformano nell'immanutabilità più totale.Voi immaginate a vedere nella vostra stack trace il nome di un metodo, cercarlo in tutta la vostra codebase e non trovarlo ed è una cosa perfettamente lecita se fate le cose in determinato modo.Quindi sicuramente sono strumenti che non sono semplici, sono strumenti che vanno padroneggiati, però Ruby e Rails, quando parliamo di RAD, quando parliamo davvero di prototipazione rapida e quando parliamo anche proprio di tempo di passaggio dal prototipo, dal POC alla produzione vera, sono imbattibili come produttività e come ergonomia.Questo che vi sto dicendo ovviamente è uno dei punti di forza che utilizza la stessa community di Ruby e di Rails per spingere questi progetti.Quindi sicuramente non è una cosa che mi sto inventando io, ci sono persone molto più autorevoli di me che hanno detto questa cosa prima di me.Io vi invito a provarli, vi invito a dargli una possibilità a Ruby e a Rails.Se non amate i framework monolitici MVC e volete comunque rimanere in ambito web, in Ruby potete trovare il Sinatra, potete trovare amami che è un bellissimo progetto amami rb e un'ultima cosa insomma che voglio citare è la community.La community di ruby è una community vastissima, è una community veramente molto molto accogliente ed è una community che è veramente friendly verso le persone e non posso dire di aver trovato questa stessa cosa in altri community di altri linguaggi comunque un po' più...anche loro molto blasonati, ecco, diciamo così.La community di Ruby è una community accogliente, una community disponibile ed è veramente, diciamo, ha un parco di librerie di risorse che credo sia secondo solo ad NPM e credo in realtà che npm come vastità abbia superato ruby gem non diciamo non proprio di...credo sia una cosa abbastanza recente ora su entrambi gli ecosistemi ho avuto questa sensazione qui quindi vi invito a provare ruby vi invito a provare rails e se volete provare ruby non lasciatevi davvero scappare l'occasione di approfondire tutta la parte di metà programmazione perché è interessantissimo, si possono approfondire veramente dei concetti super complessi e si può apprezzare veramente spesso l'eleganza, la semplicità e l'espressività delle soluzioni che sono state trovate anche a dei programmi molto molto complessi.Ovviamente non vi sto dicendo che dovete aprire il core di Rails e cominciare a leggere così dal giorno alla mattina ma anche semplicemente implementare un DDSL da zero, comunque fare qualche cosa di più creativo ecco.Vi invito a provare Ruby in questo modo qui.Credo che tanti di voi potranno apprezzarne l'espressività e la gioia nello scrivere Ruby.Ovviamente nello strumento per tutto ma anche Ruby nei suoi flavor diciamo più recenti tra cui c'è Traf o Ruby ha dato comunque anche un grande boost in fatto di performance con dei trade off, si ma nel senso si stanno facendo dei passi in avanti anche in quella direzione lì e ne sono stati fatti tanti negli ultimi anni.Quindi provate Ruby, provate anche Elixir e diteci che cosa ne pensate.Vi aspettiamo nel nostro gruppo Telegram.Ciao! Ciao a tutti, buongiorno, buon pomeriggio, buonasera, dipende dal momento in cui della giornata ci state ascoltando.In questo piccolo spazio al mecca andrei a Gian Antonio e KJ belli e oggi volevo cogliere l'occasione di questo invito di Mauro che ha fatto tutti noi riguardo a parlare del nostro linguaggio preferito.Non potevo non cogliere quest'occasione per parlarvi di uno di quei linguaggi più distrattati dalla maggior parte dei programmatori.Ma scopriamo insieme perché viene distrattato, qual è la sua storia.Sì, forse avete capito di cosa stiamo parlando, stiamo parlando di PHP.Facendo un tuffo nel passato di questo acronimo ricorsivo, era PHP Hypertext Processor, appunto un processore di ipertesti, dove originariamente il suo creatore che era appunto, diciamo, Rasmus Lerdoff, era pensato per essere un personal homepage, quindi ideato per essere un linguaggio di scripting interpretato per realizzare una piccola pagina web dinamica.Era questo il goal, era questo l'obiettivo del suo creatore.È un linguaggio che si appoggia sopra al linguaggio C, completamente open source, che ha una storia super longeva, basti pensare che la sua data di origine risale al 95, se sbaglio.Quindi parliamo della versione, diciamo, proprio delle origini.Poi ovviamente, quindi PHP 1, poi è evoluto pian piano, evolvendosi in diverse forme, con l'aiuto anche di altri sviluppatori, eccetera eccetera, fino a poi, diciamo, arrivare a una prima release davvero stabile che fu PHP 3, che poi da lì non si è fermata, continua ad evolversi, è cominciato anche la forma di adozione di questo linguaggio per chi volesse sviluppare sul web, basti pensare che siano entrati a utilizzarlo anche, diciamo, grandi corporate come Microsoft, Facebook, eccetera eccetera, ma è sempre rimasto un qualcosa di totalmente open source.Perché in molti ne parlano male, perché diciamo a coloro che oggi hanno super giù 40 anni e probabilmente ci hanno lavorato 10 anni fa, 15 anni fa o diciamo 8 anni fa, è stato un po' il periodo più buio di questo linguaggio.Perché? Perché c'erano poche evolutive, mancava un buon sistema di package manager, c'è stato un buio di, non ricordo quanti anni, super giù, sette o sei, dove non ci sono stati grandi evolutivi del linguaggio.Poi, perché io continuo a innamorarmi di questo linguaggio giorno dopo giorno, quando l'ho scoperto diciamo nel 2003? Perché non ha mai smesso di evolversi, Quindi, tralasciando quel momento di buio, diciamo nel 2015 c'è stato il punto di svolta.Entra nel core del linguaggio i nuovi committee del suo core, cominciano davvero a rimetterci le mani e a renderlo più performante e viene rilasciata la versione 7 nel 2015.Con questa versione 7 è è proprio lo spartiacqua e cambia completamente l'approccio.Si rompono un sacco di concetti che c'erano nel passato e un occhio anche alle performance di questa nuova versione e da lì non ci hanno mai abbandonato.Il core team di PHP ogni anno ha rilasciato una nuova release, aggiungendo nuove funzionalità, nuovi costrutti, nuove cose che migliorassero l'esperienza dello sviluppatore eccetera eccetera e di pari passo anche la community che gli stava attorno ha rilasciato sempre più librerie, nuovi framework, nuove cose più performanti, tool eccetera eccetera.Ad oggi è uno di quei linguaggi dove diciamo nasce per il web e rimane ancora per il web.Fino a poco, diciamo anni fa, diciamo, si poteva fare tutto con PHP, dal front-end al back-end alle Klee.Oggi, preferibilmente, ci si è spostati più sulla parte di Klee e di server-side per lasciare, diciamo, spazio all'onda arrivata dagli ultimi anni di, diciamo, JavaScript che con cui, con librerie forti come Vue, React, Angular, prendono il dominio della parte più client-side, ma come giusto che sia, per lasciare spazio a quello che davvero fa bene di HP, che è appunto la parte server-side o di clean.Parlavamo di ecosistema, parlamo di ecosistema e di community open source, quello che davvero amo, è qualcosa che davvero non ha mai smesso di crescere.a partire da grandi framework che sono nati nel tempo, alcuni si sono accasciati sul fianco e hanno ceduto il passo, altri sono andati dritti a bomba, come ad esempio, ne so, Sinfony o Laravel.E l'approccio più vincente, a mio avviso, probabilmente è stato quello di Sinfony, dove non solo ha realizzato un framework, ma il suo focus è stato di realizzare dei componenti che poi venissero utilizzati su un framework.Quindi non bisogna per forza utilizzare il framework Symfony per poter usufruire di questi componenti.Difatti altri framework come Laravel o Drupal utilizzano i componenti di Symfony per spiegarci.Il sistema di package manager composer è arrivato a una stabilità e anche un concetto di performance davvero molto elevato, quindi anche qui la developer experience è davvero migliorata negli ultimi anni e a sua volta fino ad oggi siamo arrivati a una versione 8 che permette ancora una volta migliori performance, nuovi costrutti, approcci alla programmazione che davvero semplificano lo sviluppo a noi tuttora.Senza non dimenticare, tralasciare che tutto questo è sempre circondato da altri tool di cui possiamo utilizzare, anche pensati per il linguaggio PHP e scritti in PHP.La cosa bella che mi piace sempre dire è che ad esempio composer è scritto in PHP perché è il package manager di quel linguaggio, oppure, che ne so, strumenti per fare il linting del nostro codice come PHP JSFX, o strumenti per testare il nostro codice come PHP unit o p-test, sono grandissimi strumenti che sono nati molti anni indietro e anche loro non hanno mai smesso di evolversi.Quindi perché amo questo linguaggio, perché per me è un linguaggio sempre verde.Non smette mai di stupirci, di farci stare al passo con le tecnologie, permettendoci di parlare con qualsiasi tipo di layer storage di qualsivoglia nascita.Quindi nulla viene lasciato al caso, nulla venino lasciati indietro.Non ho mai avuto l'esigenza di spostarmi o andare a cercare altre linguaggi per poter fare la stessa cosa che potevo fare con questa cosa.Sicuramente ci sono dei casi d'uso, lato server-side molto specifici, che ovviamente non è linguaggio fatto apposta, però ovviamente se noi rimaniamo nell'area del web, che è l'area diciamo che mi interessa e è quello che faccio tutto oggi, sicuramente è uno di quei linguaggi da non escludere, da non barrare mai, ma da tenere sempre in considerazione anche per via della sua base, la sua curva di apprendimento è davvero molto lieve, utilizza dei, diciamo, sposa i concetti della formazione ad oggetti che, diciamo, è alla base ad oggi di molti linguaggi che si studia anche nelle università, quindi cos'altro dire.Forse l'ultima cosa importante che mi piace sottolineare è che, se non sbaglio, sei mesi fa è stata aperta la PHP Foundation su Open Collective, dove è possibile anche sponsorizzare il core team dello sviluppo per continuare a mantenere, diciamo sponsorizzare le attività degli sviluppatori del core team, quindi diciamo un'azienda o noi anche singolarmente possiamo andare a contribuire con il nostro piccolo pensiero per aiutare gli sviluppatori che lavorano al core team a sovvenzionare le loro attività.Bene, mi sono davvero voluto ritagliare questi cinque minuti, avrei potuto dire tantissimo altro, ma non vi voglio tediare ulteriormente.Ringrazio Mauro per questo spazio, buona programmazione a tutti e viva PECP.Bye.Ciao a tutti.In questo spazio volevo parlare di due linguaggi, in realtà, non solo uno.Che sono i miei linguaggi preferiti? Linguaggi che utilizzo durante le mie attività di sviluppo, durante il mio tempo libero, mentre dormo, mentre mangio, mentre mangio il pane, che questi linguaggi mi mettono a tavola.E quali sono questi linguaggi? Il primo è PHP.PHP è stato il mio primo linguaggio che ho utilizzato per lo sviluppo web.Ed è stato abbastanza un amore a prima vista, perché la curva di apprendimento non è ripida per niente, quindi si riesce a essere operativi.È abbastanza esplicativo, anche la sintassi si capisce bene, almeno dal mio punto di vista.E negli anni ho cominciato a utilizzare diversi framework, a partire da CakePHP, Drupal, ultimamente negli ultimi anni Laravel con cui ho lavorato molto, per cui sono abituato a utilizzare PHP.L'ecosistema intorno a PHP, sia di tooling, sia di librerie, è veramente devastante, si trova di tutto.È un linguaggio maturo, è un linguaggio abbastanza performante, Big Tech utilizzano il PHP tutt'oggi, Quindi, come dice Andrea, che spero abbia parlato prima di me, questo linguaggio è bistrattato, non si sa per quale motivo.Probabilmente nessun linguaggio deve essere bistrattato, perché finché lo utilizza il creatore del linguaggio e anche un'altra persona, vuol dire che a qualcuno serve.E quindi ha un caso d'uso specifico.Per PHP stiamo parlando di una fretta abbastanza grossa del web.Quindi, grossa menzione per PHP, grossa menzione per le ultime versioni di PHP che hanno introdotto diversi improvement delle performance.Non abbiate paura, il fatto che ci sia il dollaro davanti alle variabili non vuol dire un cazzo, non cambia niente, non va bistrattato per questa cosa, non facciamo la guerra dei linguaggi.L'altro linguaggio di cui volevo parlare è ovviamente JavaScript.E su JavaScript di cose se ne possono dire tante.Il mio primo approccio con JavaScript, come penso per tutti quelli che sono sulla quarantina, hanno iniziato da un po' a sviluppare, è fare animazioni o qualche cosa sulle pagine web direttamente da browser.Salutiamo JQiri che ci sta sicuramente ascoltando.Il mio approccio a JavaScript è stato quello di dire "ok, devo fare questa cosa velocissima, apro il Tag Script, scrivo queste dieci righe e ciao, la cosa funziona benissimo".Questo JavaScript aiuta molto perché non ha tipi, non devi per forza mettere i punti a virgola.Ha una sintesi, praticamente puoi scrivere quello che ti pare e lui in qualche modo te lo interpreta.Quindi è molto libero.Questo chiaramente porta ad avere un'enorme quantità di codice di merda sul GitHub, perché abbassando il livello di ingresso di una certa tecnologia, ovviamente più persone di livello più basso possono entrare e scrivere con quel linguaggio.Ovviamente in JavaScript si vede qualsiasi cosa.Tant'è che dici "ma questo è codice minificato o no?" Scherzi a parte, nel corso degli anni ho iniziato a lavorare con JS, che è JavaScript Server Side.E anche lì quando l'ho scoperto ho detto "ah, wow!" Non ho mai pensato a quella cosa che scrivi sul browser e sul server con lo stesso linguaggio, come se questo fosse un qualsivoglia vantaggio.Io non ho mai preso un codice dal browser e l'ho messo nel server, anche perché si occupano di fare due cose diverse.Però c'è da dire che molti di quelli che sviluppavano semplicemente dentro il Tag Script, a quel punto, sono trovati a poter avere un server web, un runtime con l'accesso alle risorse del sistema, senza dover imparare una nuova tecnologia, sostanzialmente, senza dover imparare il concetto di callback, avendo già a che fare con la programmazione funzionale.Quindi sicuramente questo è stato un aiuto per la diffusione di una tecnologia come Node.js.Sul discorso dell'ecosistema, qui dovremmo sia parlarne per ore e stendere un vero pietoso, perché abbiamo librerie e framework per fare qualsiasi cosa, Il problema è che mentre parlo sono state create nuove librerie, nuovi framework per fare la stessa cosa e questo crea un sacco di frammentazione, un sacco di guerre tra clan, tra React vs Vue.Ragazzi usate quello che vi serve, quello che vi piace di più perché tanto poi le pagine web le vediamo tutte con Safari e non funziona un cazzo.Quindi il linguaggio si è sviluppato molto ed è diffusissimo, è stato introdotto TypeScript che per me appunto è come mettere una bella camicia sul manico da scopa abbiamo NPM che con la sua vastità di librerie contiene librerie per dirti che se un numero è 10.000 e poi è stata creata quella per capire se un numero è 100.000 e così via, abbiamo la cartella NodeModules che occupa giga e giga mentre il nostro server web ha una a una singola rotta hello world.Ok, è vero, il problema è che la diffusione, la semplicità con cui si può utilizzare questa tecnologia e la sua diffusione porta chiaramente a questi...è un vantaggio sicuramente per tutta la comunità di sviluppatori, ma porta a questi problemi.Se non mi credete andate a farvi un giro su Facebook, quando apri la tecnologia a tutti, purtroppo tutti possono entrare e fare quello che vogliono.vogliono.Comunque, fondamentalmente perché questi sono i miei linguaggi preferiti? Perché coprono la stragrande maggioranza di tutti i casi d'uso di cui ho bisogno.Ad esempio, devo scrivere uno script per fare lo scraping di una pagina web e tirare fuori i dati.lo scrivo in Node.js.Devo fare un'applicazione web full stack.Utilizzo l'Aravel.Per semplicità, perché ha già molte cose integrate, ha già un sistema di autenticazione, ha già tante cose che mi velocizzano.Per essere operativi subito voglio qualcosa di già fatto che conosco.Non ho intenzione, cioè bisogno di conoscere altri linguaggi, se non per cultura mia.mi piacerebbe molto conoscere Python, però di solito quando mi metto a fare lo scraping non voglio anche imparare il linguaggio, sarebbe un bel esercizio, ma ho bisogno della cosa subito, ho bisogno dei dati subito e quindi lo faccio in Node.js.Ancora non ho trovato quella situazione dove ho bisogno di uno specifico linguaggio.Comunque, come ripeto sempre, la guerra dei linguaggi è un...Non lo so, va bene, sono semplicemente chiacchiere da bar.Ognuno lavora con quello che gli serve.Tutto ha un suo caso d'uso.Tutti i linguaggi hanno i loro pro e i loro contro.Non bisogna per forza dire qual è meglio e qual è no.È come il vino.Il vino buono è il vino che piace.Poi se a me piace quello da 5 euro e a uno da 50, io forse probabilmente non sento nemmeno la differenza."Problemo mio, lasciami bere quello da 5, non mi devi convincere di bere quell'altro".Quindi, detto questo, continuate a scrivere codice, scrivete codice bene, testate il codice che scrivete e potete utilizzare qualsiasi linguaggio vi pare.Non vi preoccupate, non state a ascoltare le chiacchiere di quegli altri, tipo me.Ciao a tutti! *musica* è arrivato il momento di ringraziare chi ci supporta perché come ben sapete Gitbar è un podcast gratuito noi ci mettiamo tutto il nostro impegno per far uscire ogni settimana più o meno puntuali gli episodi ma questo non vuol dire che fare questo podcast non abbia costi abbiamo diversi ammonamenti da pagare abbiamo delle licenze da sostenere, insomma il più delle volte ci autofinanziamo un grosso grosso grosso apporto viene da chi decide di dimostrarci affetto sostenendo con noi una parte delle spese del nostro podcast e questa settimana abbiamo due amici che hanno deciso di sostenerci offrendoci virtualmente una birra sono Matteo Candura che ci offre una birra e Bruno Pelaia che ce ne offre tre devo dire che ci dovrebbero essere anche dei messaggi io sto camminando spero di non inciampare di non spaccarmi i denti vediamo un po' vediamo un pochino eeeh...papapà vedi storia non riesco a a vedere se ci sono messaggi mi dispiace ok paypal non mi fa vedere i messaggi ma a questo punto direi che possiamo alzare i calici al cielo e brindare alla salute di Matteo e Bruno Perché grazie a loro anche grazie a loro ghetto bar è potuto arrivare alle vostre orecchie anche questa settimana Grazie davvero se poi volete sostenerci vi ricordo che trovate il pulsante supportaci nel nostro sito nell'aria in alto a destra e lo trovate anche sulle note di ogni episodio quindi se vi fa piacere fare in modo che GITBAR possa continuare a essere prodotto, noi siamo qua Spero che questo episodio vi sia piaciuto, è un episodio un po' atipico, vi prometto che riprenderemo a fare gli episodi ordinari e anche con dei super interessantissimi guest dalla prossima settimana.Allora facciamo così siccome vi confido che le prossime due settimane una volta tornato dal viaggio io dovrò fare un trasloco vi prometto che comunque troverò il modo nonostante il trasloco di appunto riprendere una programmazione regolare e di arrivare alle vostre orecchie in tempo per il famoso giovedì mattina perché so che molti di voi il giovedì mattina aspettano l'uscita dei nostri episodi.Detto questo io vi do appuntamento alla prossima settimana, a questo punto, al prossimo giovedì con un altro episodio di Geekbar.Ringrazio nuovamente tutti gli ascoltatori ma anche i miei compagni di viaggio Alessio, Mattia, Luca, Andrea, Leonardo e Carmine che fanno sì che in realtà questo podcast esista.Quindi grazie ragazzi! Alla prossima! Gitbar, il circolo dei full stack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.[Musica] Ciao.[Musica] [Musica]
