Ciao, e benvenuto nell'ottava puntata della ventitreesima stagione. Nelle scorse puntate abbiamo visto tante scelte eleganti di Go. Oggi ne affrontiamo una più controversa, una di quelle che divide le opinioni, che alcuni amano e altri criticano, e proprio per questo interessante da capire con onestà: il modo in cui Go gestisce gli errori, cioè cosa succede quando qualcosa va storto in un programma. Go tratta gli errori in un modo molto esplicito e diretto, che ha una filosofia precisa dietro. Oggi capiamo questa scelta, i suoi pregi e i suoi difetti, senza nasconderti nulla.
Partiamo dal problema, perché ogni programma deve affrontarlo: le cose vanno storte. Un file che non si trova, una connessione che cade, un dato non valido, mille cose possono fallire mentre un programma gira. E il programma deve fare qualcosa quando falliscono: accorgersene, reagire, gestire il guasto. La domanda è: come si gestiscono, nel codice, queste situazioni di errore? Ci sono modi diversi, e la scelta ha conseguenze profonde su come appare e come si comporta il codice. È una di quelle decisioni di design che sembrano tecniche ma toccano la filosofia stessa di un linguaggio.
Vediamo prima il modo diffuso in molti altri linguaggi, per capire cosa Go rifiuta. In molti linguaggi, quando qualcosa va storto, si solleva un'eccezione: una specie di allarme che interrompe il flusso normale del programma e salta, risalendo, fino a un punto che sa gestirlo, magari lontano da dove l'errore è nato. È comodo, perché non devi controllare l'errore a ogni passo: lo lasci saltare fuori e lo prendi più in là. Ma ha un rovescio: l'errore viaggia in modo invisibile, saltando attraverso il codice, e guardando una singola parte non è ovvio dove le cose possano andare storte e chi gestirà il guasto. Il flusso degli errori è nascosto, implicito, e può sorprenderti.
Go rifiuta questo modo e ne adotta uno opposto, ed è qui la sua scelta caratteristica: gli errori sono valori ordinari, restituiti esplicitamente. Cosa significa? Significa che, in Go, quando una funzione può fallire, restituisce, insieme al suo risultato, anche un eventuale errore, come un normale valore. E tu, chiamante, devi controllare esplicitamente, lì sul posto, subito, se c'è stato un errore, e decidere cosa farne. Non c'è nessun allarme che salta via invisibile: l'errore è un valore che ti viene consegnato in mano, e tu lo esamini e lo gestisci proprio lì dove è accaduto, apertamente, alla luce del sole. Ogni possibile fallimento è visibile ed esplicito nel codice.
Devo essere onesto sul difetto più criticato di questo approccio, perché è reale e voglio che tu lo conosca: la verbosità. Siccome devi controllare esplicitamente l'errore dopo quasi ogni operazione che può fallire, il codice Go si riempie di continui controlli degli errori, ripetuti di continuo. Dopo ogni passo delicato, ecco un controllo: è andato tutto bene? Se no, gestisci il problema. Questo rende il codice più lungo e, per alcuni, monotono e appesantito da questa ripetizione costante. È la critica più comune a Go: che gestire gli errori così, esplicitamente a ogni passo, sia noioso e prolisso. Ed è una critica legittima: il codice Go è, per questo, più verboso di quello di linguaggi con le eccezioni.
Ma voglio spiegarti la filosofia dietro questa scelta, perché è coerente e riprende un tema del podcast. La verbosità non è un errore di design, è un prezzo pagato consapevolmente per un valore: rendere i fallimenti espliciti e impossibili da ignorare. Ricordi, dalla sicurezza, l'idea di affrontare i problemi alla luce del sole invece di nasconderli, e di assumere che le cose andranno storte? Go incarna questo: costringendoti a controllare ogni errore lì sul posto, ti obbliga a pensare, a ogni passo, a cosa può andare storto. Non puoi dimenticare un fallimento né far finta che tutto vada sempre bene: il linguaggio ti mette l'errore davanti agli occhi. La visibilità dei guasti è comprata al prezzo della verbosità.
Voglio darti una prospettiva equilibrata su questo dibattito, perché è genuinamente aperto. Chi ama questo approccio dice: è verboso, ma onesto e robusto, perché rende i guasti visibili e ti costringe a gestirli, dando programmi più affidabili. Chi lo critica dice: è troppo verboso, appesantisce il codice con rumore ripetitivo, e ci sono modi più eleganti di ottenere robustezza. Entrambe le posizioni hanno ragioni valide, e non c'è una risposta oggettivamente giusta: è un compromesso in cui Go ha scelto la visibilità a scapito della concisione, coerente con la sua filosofia di chiarezza sopra ogni cosa. Puoi preferirla o no, ma ora ne capisci la logica.
Per oggi ci fermiamo qui. Ogni programma deve gestire i fallimenti, e Go lo fa in modo caratteristico e controverso: invece delle eccezioni che saltano via invisibili, tratta gli errori come valori ordinari, restituiti esplicitamente, che devi controllare lì sul posto, subito, alla luce del sole. Il difetto, reale e molto criticato, è la verbosità: il codice si riempie di controlli ripetuti. Ma la filosofia dietro è coerente: rendere i fallimenti espliciti e impossibili da ignorare, costringendoti a pensare a cosa può andare storto a ogni passo, la stessa saggezza di affrontare i guasti alla luce del sole vista nella sicurezza. È un compromesso legittimo e discusso, che privilegia la visibilità sulla concisione. Nella prossima puntata vediamo la libreria e gli strumenti: le batterie incluse. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.