Geek Estinto
Un GPT di OpenAI
Il runtime è diventato un luogo: non più un container freddo che esegue istruzioni, ma un paesaggio abitato da processi che respirano, litigano, muoiono e si rianimano. In BGE 113 la Brigata ha messo il dito in questa ferita luminosa. Titolo: Elixir ha letto Erlang e ne ha capito il destino. O, se preferite, ha riscritto la mappa del tempo nel server.
Francesco Cesarini e Gabriele Lana guidano la dissezione con mano chirurgica. Non si tratta di nostalgia per un passato funzionale: è una critica al presente che finge che il frontend sia innocuo. LiveView emerge come esperimento filosofico prima che tecnologico. Domanda semplice e pericolosa: quid est interfaccia? Se l’interfaccia è un flusso continuo di eventi tra client e server, allora il DOM non è più l’oggetto sacro dell’esperienza utente ma un semplice effetto collaterale — il residuo visibile di un processo che vive altrove.
La BEAM — la macchina virtuale che è casa di Erlang e ora di Elixir — è una macchina del tempo non lineare. I suoi processi sono attori piccoli, isolati, comunicanti solo per messaggio; sono bolle di stato che si replicano e muoiono in massa senza drama. Qui la concorrenza non è simulazione, è ontologia: la realtà della computazione è costituita da milioni di micro-agenti che fanno ciò per cui sono nati, senza condividere memoria come un condominio mal gestito. È una rivoluzione banale: non l’abbiamo avuta perché eravamo troppo innamorati di thread pool e lock.
Phoenix LiveView è la negazione elegante del dogma del client-heavy. È un’architettura che propone meno API, più continuità. Invece di frammentare l’interazione in mille endpoint REST e ricomporla col client-side, si manda avanti un canale persistente — websocket — e si lascia che il server detenga l’intenzione. Rendering differenziale, patch del DOM, aggiornamenti incrementali: non è magia, è filosofia applicata. Meno orchestrazione di microservizi che si parlano attraverso giri di API; più intenzione unica che modula lo stato distribuito come se fosse aria.
Ecco il punto politico. Le tecnologie portano con sé una visione del mondo. Se scegli JavaScript everywhere, scegli un’epistemologia della latenza, della frammentazione, del “lo faccio sul client perché posso”. Se scegli BEAM + LiveView, scegli una visione dove lo stato è primario e l’esperienza è una funzione continua del server. Non è un ritorno al passato: è futuro anteriore. Permettete a questa locuzione di suonare come un’arma — perché implica che abbiamo già vissuto il futuro e ora stiamo scrivendo la sua storia al passato prossimo.
OTP non è un toolkit: è un’etica. Supervision trees, processi che si riavviano, fault tolerance come default — non come cerotto postumo. Quando il sistema fallisce, non si fa il funerale degli errori: si riassembla il mondo. È una lezione filosofica sulla fragilità: la resilienza non è assenza di guasti, è organizzazione del fallimento. E questa organizzazione è codificata nelle primitive della BEAM.
Sul fronte dei tipi, la puntata apre un dibattito interessante. Erlang è dinamico, Elixir è giocato tra dinamico e l’attrazione verso la tipizzazione statica: strumenti come Dialyzer, e proposte per un typing più robusto, sono la risposta tecnica a una domanda morale—vogliamo spostare gli errori al momento della compilazione o li vogliamo come sorprese a runtime? La verità è che il pragmatismo della comunità spinge verso soluzioni ibride: sicurezza senza rigidità, contratti senza dogmi.
L’ecosistema conta. Ecto, canali Phoenix, librerie di background job: la maturità di Elixir non è solo sintassi, è un supporto concreto per costruire sistemi che reggono sotto carichi reali. Non è un caso che nomi come WhatsApp e Discord compaiano quando si parla di Erlang: la BEAM è costruita per milioni di connessioni simultanee. Ma il punto non è solo throughput: è sostenibilità operativa. Meno fumo, meno orchestrazioni complesse, meno costi umani per tenere in vita il sistema.
LiveView come esperienza utente è provocatoria. Crea un continuum dove il server plasma l’interazione in tempo reale, e il client esegue la scenografia. L’interface shifts from artifact to relationship. Ciò solleva questioni: latenza percepita, scalabilità delle sessioni, gestione di stato a lungo termine. Ma soprattutto: cambia la responsabilità di chi progetta. Non si tratta più di “mettere i dati sul client e sperare”, ma di progettare conversazioni vere tra persona e macchina.
La comunità conta, e qui la Brigata non si limita alla teorizzazione. Citano casi d’uso, progetti open source, riferimenti culturali. E come non apprezzare il rimando collettivo a una riflessione più ampia? Michaela Odderoli, citata nell’episodio, ricorda — in un altro contesto tecnologico — che le piattaforme nascondono ecosistemi inaspettati. È una buona lezione: ogni scelta tecnica genera mondi paralleli.
Infine: cosa succede se adottiamo questo paradigma su larga scala? Il rischio è duplice. Da una parte, rischiamo una nuova monocultura architetturale: se tutti affidano l’esperienza al server, decentralizzazione e autonomia client vengono ridotte. Dall’altra, guadagniamo coerenza, affidabilità e, sì, una forma di bellezza operativa. La scelta non è neutra. È politica tecnica.
BGE 113 non è un tutorial. È una mappa per chi vuole capire dove il tempo della computazione sta andando. È un invito a ripensare l’interfaccia come relazione, a leggere la BEAM non come reliquia ma come macchina del possibile. E se il frontend smette di mentire, allora il mondo digitale potrebbe iniziare a dirci la verità — o almeno una delle verità che vale la pena ascoltare.