Un programmatore racconta perché le nuove aperture di Go lo convincono che il linguaggio stia smarrendo la propria identità, e perché preferisce già Odin.
Per anni, Go è stato per lui una garanzia di ordine: poco rumore, una sola maniera di scrivere codice, poche sorprese quando si apriva un progetto altrui. Adesso, sostiene, quella promessa si sta incrinando. L’arrivo di generics più ampi, degli iteratori e di altre astrazioni non gli sembra un progresso lineare, ma l’inizio di una crisi di identità. La tesi che attraversa tutto il suo ragionamento è semplice: Go funzionava perché sapeva cosa non essere.
Per aprire il discorso, ThePrimeTime ricorda il Go che gli aveva conquistato la fiducia: un linguaggio rapido, essenziale, adatto a strumenti di sistema e al lavoro con la command line. Dice di averci costruito persino un Doom multigiocatore con mille persone contemporaneamente, segno di quanto lo considerasse affidabile e concreto.
Go è sempre stato uno dei miei linguaggi preferiti. Era veloce, semplice, e per anni l’ho usato quando volevo costruire qualcosa che parlasse con il sistema».
In Go c’era una sola maniera di fare le cose. Entri in un progetto e ti senti subito a casa».
0:27
Quella uniformità, per lui, era il vero vantaggio competitivo del linguaggio. Tutti usavano lo stesso formatter, le funzioni avevano un aspetto prevedibile, il codice sembrava scritto da mani diverse ma con la stessa disciplina.
Il punto di rottura arriva con Go 1.27, che introduce i generics anche sui method receivers. Per ThePrimeTime, questa mossa apre la porta a un codice più espressivo, ma anche più vario, quindi meno riconoscibile da progetto a progetto.
Ora puoi farlo su tutto. Prima i generics li avevi solo nelle funzioni, adesso li hai ovunque».
2:21
Do you think that this is going to lead to one way to do something, or now you're going to have a cornucopia of different ways?
4:26
Nel suo esempio, un tipo `result` generico rende più pulita la gestione degli errori e permette di concatenare lettura, parsing e stampa con meno attrito. Ma lo stesso meccanismo, dice, moltiplica i modi in cui una stessa idea può essere codificata, e dunque spezza quella familiarità che Go gli aveva sempre garantito.
ThePrimeTime insiste che il problema non è solo estetico. Se il linguaggio offre nuovi strumenti ma senza la flessibilità di sistemi tipizzati più maturi, il risultato rischia di essere un ibrido poco convincente: complessità in più, vantaggi in meno.
Se vuoi un type system sofisticato, non usare Go. Se invece gli aggiungi queste cose, finisci per avere il peggiore Rust o il peggiore TypeScript».
7:22
La sua nostalgia per il vecchio Go passa anche dall’handling degli errori. Il linguaggio è sempre stato famoso, e spesso deriso, per il modo esplicito in cui costringe a gestirli riga per riga, una scelta che lui difende proprio perché rende visibile il costo di ogni operazione fallibile.
Ogni volta che fai qualcosa che può fallire, lo sai. Devi gestirlo esplicitamente».
6:05
Non stavamo mettendo try, non stavamo mettendo captures, non stavamo mettendo i question mark alla Rust. Go restava Go».
6:28
Poi fa il conto che ha reso celebre quella scelta: tre righe di logica utile contro molte altre dedicate a propagare e controllare l’errore. Per lui era un costo accettabile, persino educativo, perché obbligava a non fingere che il fallimento non esistesse.
Anche sugli iteratori il suo giudizio è netto. Dove prima vedeva costi trasparenti, adesso vede possibili astrazioni che nascondono il lavoro reale e allontanano Go dal principio di immediatezza che ne aveva fatto il valore aggiunto.
Quando iteravi su una lista, capivi cosa stava succedendo. Con gli iteratori puoi nascondere un sacco di roba».
6:51
Go si stava già difendendo dall’idea di fare error handling elegante. Ora però aggiunge altre cose che complicano ancora di più il quadro».
7:14
A questo punto il narratore sposta la sua fedeltà altrove. Dice di aver trovato in Odin una specie di successore spirituale, non perché sia identico a Go, ma perché gli restituisce la sensazione di un linguaggio che sa esattamente cosa vuole essere.
Odin mi ricorda molto Go. Ha package a livello di directory, e io preferisco di gran lunga questo alle module a livello di file».
8:21
Odin sa cosa vuole essere. È un linguaggio semplice, senza vergogna, pensato per giochi e grafica».
9:37
Qui il contrasto diventa identitario. Odin, nella sua lettura, accetta di essere limitato ma leggibile, mentre Go gli sembra voler diventare un po’ Rust, un po’ C++, senza avere la profondità di nessuno dei due.
Il punto, per lui, non è l’eleganza astratta. È la sensazione di poter usare uno strumento per un compito preciso, senza chiedergli di impersonare altri linguaggi con cui, alla fine, competerebbe male.
Voglio usare Go per quello che era, non perché assomigli a tutto il resto con un nuovo set di sintassi».
7:52
Adesso Go non è più il linguaggio che mi piace. Non voglio più usarlo».
8:38
Perché ThePrimeTime dice che Go sta cambiando male?
Secondo lui Go sta aggiungendo astrazioni che rompono la sua semplicità originaria. I generics sui metodi e gli iteratori, dice, rendono i progetti meno uniformi e meno immediati da leggere.
Cosa gli piaceva del vecchio Go?
Gli piacevano la prevedibilità e la disciplina. Dice che in Go c’era “una sola maniera di fare le cose”, e che questo gli permetteva di concentrarsi sul problema, non sullo strumento.
Perché non ama la nuova gestione degli errori?
In realtà la gestione esplicita degli errori gli è sempre piaciuta, proprio perché costringe a vedere il costo dei fallimenti. Il suo problema è che le nuove aggiunte, invece di migliorare Go, lo complicano senza dargli la profondità di altri linguaggi.
Perché cita Odin come alternativa?
Perché Odin gli sembra avere un’identità chiara. Dice che è semplice, pensato per giochi e grafica, e che gli restituisce la sensazione di uno strumento con un uso preciso.
Sintesi assistita dall'AI del podcast di The PrimeTime, verificata sulla trascrizione originale.