"Basta, mollo tutto e passo a Go." Se scrivi codice per il web da qualche anno, questa frase l'hai detta o sentita almeno una volta. Di solito arriva dopo un composer update che rompe un plugin. Oppure dopo l'ennesimo avviso di sicurezza su un pacchetto npm che non sapevi nemmeno di avere.
Io lavoro ogni giorno con PHP e Node.js: questo sito gira su Next.js e il suo server MCP è scritto in TypeScript. Go lo uso anch'io in produzione, quindi quella frase la capisco da tutte e due le parti.
La mia risposta è no: non mollo tutto. Aggiungo Go dove risolve un problema preciso e lascio PHP e Node.js dove fanno risparmiare tempo. Decido con due criteri che con la sintassi c'entrano poco: chi manterrà quel codice negli anni successivi e come l'AI ha cambiato il mio modo di scriverlo.
Perché PHP e Node.js stancano
La stanchezza raramente dipende dalla sintassi. Dipende da tutto quello che sta intorno al linguaggio: versioni da rincorrere, dipendenze da controllare, strumenti da configurare.
PHP: aggiornamenti continui e plugin fragili
Ogni versione di PHP riceve due anni di supporto attivo e altri due di sole patch di sicurezza. Tradotto: PHP 8.2 smette di ricevere correzioni di sicurezza il 31 dicembre 2026, tra meno di due mesi. Chi ha siti su hosting condiviso deve aggiornare, verificare che temi e plugin reggano e sperare che nulla si rompa.
Quando poi esce una falla critica la corsa diventa urgente, come è successo con PHP2Shell. Ho raccolto i passi pratici nella guida su cosa fare dopo PHP2Shell.
Node.js: node_modules, supply chain e toolchain
Con Node.js il problema è diverso. Anche un progetto piccolo può scaricare centinaia di pacchetti tra dipendenze dirette e indirette, e ognuno è una possibile porta d'ingresso. Il worm Shai-Hulud ha mostrato quanto può costare: ne ho parlato nell'analisi del malware npm che passa dagli agenti AI.
Poi c'è la toolchain: bundler, transpiler, ESM contro CommonJS, file di configurazione che cambiano a ogni major. Anche il calendario si muove. La v26 è entrata in Active LTS il 28 ottobre 2026, la v22 arriva a fine vita il 30 aprile 2027 e dalla v27 Node.js passa a una sola release line all'anno, a ottobre.
La fatica è l'ecosistema, non il linguaggio
Molto di quello che pesa dipende da come usiamo questi strumenti: troppe dipendenze, nessun aggiornamento programmato, hosting scelto solo sul prezzo. Cambiare linguaggio senza cambiare queste abitudini sposta il problema, non lo risolve. Per questo, prima di guardare cosa offre Go, parto da come scelgo io.
Come scelgo un linguaggio: prima chi lo mantiene
Un progetto non finisce il giorno della consegna. Io seguo il cliente dall'analisi al server in produzione e poi nell'assistenza degli anni successivi. Ogni linguaggio che aggiungo a un progetto è una cosa in più da aggiornare, monitorare e correggere quando si rompe, e quel lavoro resta a me o a chi verrà dopo di me.
Per questo la domanda che mi faccio non è "qual è il linguaggio migliore?" ma "chi metterà le mani su questo codice tra tre anni?". Un linguaggio che conosco solo io, in un'azienda dove tutto il resto è PHP o JavaScript, è un rischio per il cliente anche se è tecnicamente perfetto.
È il motivo per cui L'Artisan, l'ERP che ho costruito per Cesari Pasticceria, è in Laravel 12 e React. Un gestionale ha bisogno di autenticazione, permessi, code, pannelli e report, e in quell'ecosistema sono pezzi già pronti e collaudati. Riscriverli in Go avrebbe voluto dire far pagare al cliente ore che non gli portano nulla.
Lo stesso criterio però gioca anche a favore di Go. Un servizio compilato in un solo file, con poche dipendenze esterne e un linguaggio che non rompe il codice vecchio, è un servizio che tra tre anni chiede poca manutenzione. Dove il pezzo è piccolo e isolato, questa è una ragione concreta per sceglierlo.
Cosa è cambiato con l'AI nel modo in cui scelgo
Oggi una parte del codice non la scrivo più a mano: la scrive un agente come Claude Code, e io la leggo, la correggo e decido se va in produzione. Questo ha spostato il peso di alcuni argomenti storici del confronto tra linguaggi.
- La verbosità pesa meno. La critica classica a Go è il codice ripetitivo nella gestione degli errori. Se quelle righe le scrive l'agente, il costo di digitarle sparisce. Resta il vantaggio: ogni errore è gestito in modo esplicito, ed è più facile da controllare quando rileggo.
- Il compilatore pesa di più. Con i tipi statici un errore dell'agente si ferma in compilazione, prima di arrivare sul server. In PHP e in JavaScript senza TypeScript lo stesso errore può emergere solo a runtime.
- Un linguaggio piccolo si rilegge meglio. Go ha poche parole chiave e una sola formattazione ufficiale. Il codice generato assomiglia a quello che scriverei io, e la revisione è più veloce.
- Meno dipendenze, meno sorprese. Un agente tende ad aggiungere pacchetti per risolvere in fretta. Con una libreria standard ampia ne servono meno, e ogni pacchetto in meno è un rischio in meno nella supply chain.
C'è però il rovescio. L'AI rende facile produrre in un pomeriggio un servizio in un linguaggio che nessuno in azienda sa leggere. Funziona finché funziona, poi il primo problema in produzione diventa un'emergenza. Il codice che non sai leggere non lo stai mantenendo: lo stai solo ospitando. È una situazione che conosco bene, perché sistemare codice scritto con l'AI e portarlo in produzione è una parte del mio lavoro.
Quindi l'AI non ha eliminato la scelta del linguaggio. Ha tolto peso alla fatica di scrivere e ne ha aggiunto alla capacità di verificare e mantenere. E così si torna al primo criterio.
Cosa offre Go (golang) a chi arriva da PHP e Node.js
Go, che molti cercano come golang, è nato in Google. È un linguaggio compilato, a tipizzazione statica e volutamente piccolo: ha appena 25 parole chiave. Questi sono i punti che contano per chi sviluppa per il web.
Un solo binario da copiare sul server
Il risultato di go build è di solito un unico eseguibile. Il runtime di Go è già incluso e non c'è una cartella di dipendenze da caricare. Puoi anche compilare per un altro sistema operativo dal tuo portatile. Con GOOS=linux GOARCH=amd64 go build ottieni il binario per un server Linux, anche se lavori su Mac o Windows.
Concorrenza semplice con le goroutine
In Node.js gestisci la concorrenza con l'event loop e async/await. In PHP, con PHP-FPM, ogni worker serve una richiesta alla volta. In Go lanci una funzione in parallelo scrivendo go davanti alla chiamata, e il runtime distribuisce le goroutine su tutti i core della CPU. Per code di lavoro, chiamate a più API in parallelo o websocket è un vantaggio concreto.
Libreria standard e strumenti già inclusi
- net/http: da Go 1.22 il router integrato supporta metodi e parametri nel percorso, per esempio
GET /ordini/{id}. Per molte API non serve un framework. - encoding/json, database/sql e html/template: le basi di un backend sono già nella libreria standard.
- go fmt, go vet e go test: formattazione, analisi statica e test arrivano con il compilatore. Non devi scegliere e configurare formatter e linter a parte.
- go mod: gestione delle dipendenze con checksum verificati, versione per versione.
Rilasci prevedibili e codice che resta valido
Go esce due volte l'anno: la 1.26 a febbraio 2026 e la 1.27 il 19 agosto 2026. Ogni versione è supportata finché non escono le due successive, quindi per circa un anno: non è un ciclo lungo.
Lo compensa la promessa di compatibilità di Go 1. Il codice scritto per la specifica Go 1 deve continuare a compilare e funzionare senza modifiche. Le eccezioni previste riguardano soprattutto falle di sicurezza e bug. In pratica, aggiornare Go richiede di solito poco lavoro.
Un esempio: un'API in golang in meno di 20 righe
Questo è un endpoint completo che risponde in JSON, scritto solo con la libreria standard:
package main
import (
"encoding/json"
"log"
"net/http"
)
func main() {
mux := http.NewServeMux()
mux.HandleFunc("GET /api/ordini/{id}", func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
json.NewEncoder(w).Encode(map[string]string{"ordine": r.PathValue("id"), "stato": "spedito"})
})
log.Fatal(http.ListenAndServe(":8080", mux))
}
Con go build ottieni un file da copiare sul server e avviare, per esempio come servizio systemd o in un container minimale. Nessun npm install in produzione e nessuna estensione PHP da abilitare.
Chi usa già golang nel 2026 (e perché conta)
Alla domanda "Go è ancora rilevante?" rispondo guardando chi lo usa per l'infrastruttura.
- TypeScript 7: il compilatore di TypeScript è stato portato in Go. La versione 7.0 è uscita l'8 luglio 2026 e le build complete sono diventate da 8 a 12 volte più veloci. Lo strumento principale dell'ecosistema JavaScript oggi gira in Go.
- Docker e Kubernetes: i due pilastri dei container sono scritti in Go.
- Agenti AI e MCP: esiste un SDK ufficiale del Model Context Protocol per Go, già alla serie 1.x. Se vuoi capire cosa sono i server MCP, parti dalla guida a MCP e a come creare un server.
Dove golang non conviene
Siti vetrina, CMS ed e-commerce
Per un sito aziendale, un blog o un negozio online, PHP e JavaScript non hanno rivali. WordPress, WooCommerce, Laravel, Next.js e i loro plugin coprono pagamenti, SEO, multilingua e pannelli di gestione pronti. In Go dovrei costruire da zero gran parte di queste cose, e il cliente pagherebbe ore che non gli portano valore. Per scegliere lo stack di un sito aziendale ho scritto un confronto dedicato tra WordPress e Next.js.
Il frontend resta JavaScript
Golang è un linguaggio backend. Può generare HTML lato server con html/template e può essere compilato in WebAssembly, ma l'interfaccia interattiva di un'applicazione moderna resta React, Vue o simili. Passare a Go non ti libera da JavaScript: te lo toglie dal server.
Hosting e gestione del processo
Un sito PHP gira su qualsiasi hosting condiviso da pochi euro. Un servizio Go è un processo che resta acceso: serve una VPS o un container, con monitoraggio e riavvio automatico. Per me non è un ostacolo, perché i server dei clienti li gestisco in prima persona. Per chi ha solo un hosting condiviso è un costo da mettere in conto. Se cerchi dove provarlo senza spendere, ho raccolto le opzioni nella guida all'hosting gratuito per sviluppatori.
Un'isola in mezzo a PHP e JavaScript
Se il resto del team o il cliente lavorano solo in PHP o JavaScript, un servizio in Go diventa un'isola che una sola persona sa toccare. Ha senso solo se il vantaggio tecnico lo giustifica e se qualcuno, oltre a chi l'ha scritto, è in grado di leggerlo.
Golang vs Node.js vs PHP: il confronto rapido
| Aspetto | PHP | Node.js | Go |
|---|---|---|---|
| Deploy | File su hosting condiviso o container | Runtime più node_modules | Un solo binario |
| Concorrenza | Un worker PHP-FPM per richiesta | Event loop con async/await | Goroutine su tutti i core |
| Tipi | Dinamici, con type hint | Dinamici, statici con TypeScript | Statici, controllati in compilazione |
| Ecosistema web pronto | Molto ampio: WordPress, Laravel, WooCommerce | Molto ampio: npm, Next.js | Più piccolo, libreria standard forte |
| Supporto di una versione | 4 anni | Circa 30 mesi per le LTS | Circa 1 anno, con compatibilità Go 1 |
| Codice scritto con un agente AI | Errori di tipo spesso visibili solo a runtime | Controllo in compilazione solo con TypeScript | Errori fermati dal compilatore, formattazione unica |
| Ideale per | Siti, CMS, e-commerce | Frontend, full stack JavaScript, real-time | API, worker, CLI, infrastruttura |
Dove metto Go e dove no
Riscrivere tutto non è quasi mai la scelta giusta. Tengo PHP e Node.js dove il loro ecosistema fa risparmiare tempo e prendo in considerazione Go quando il pezzo da costruire è uno di questi:
- API ad alto traffico o con molte chiamate in parallelo verso servizi esterni.
- Worker e code: elaborazione degli ordini, import di cataloghi, invio di notifiche.
- Strumenti da riga di comando da distribuire come singolo file.
- Server MCP e integrazioni per agenti AI, dove un binario leggero e senza dipendenze si installa ovunque. È il tipo di integrazione che preparo nei progetti di automazione AI per PMI.
- Microservizi che oggi rallentano un monolite PHP o un backend Node.
Il metodo che preferisco è graduale. Scelgo un solo pezzo e lo riscrivo in Go dietro un'API. Poi misuro, e solo dopo decido se andare avanti. Se quel pezzo fa parte di un gestionale o di un'applicazione su misura, è il lavoro che seguo nello sviluppo di web app e gestionali.
Le domande che mi faccio prima di usare Go
- Il problema è il linguaggio o sono le dipendenze e la manutenzione?
- C'è un collo di bottiglia misurato o solo una sensazione?
- Servono CMS, pannello admin e plugin pronti? Allora resto su PHP o JavaScript.
- Chi gestirà un processo sempre attivo su VPS o container?
- Chi leggerà e manterrà il servizio tra tre anni, soprattutto se una parte l'ha scritta un agente AI?
Leggi anche
- PHP2Shell: patch PHP uscita, cosa fare su Aruba e server
- Shai-Hulud malware: il worm npm che passa dagli agenti AI
- MCP: cos'è, come funziona e come creare un server (2026)
- Manutenzione sito web: quanto costa e cosa comprende
Conclusione
Go è un ottimo linguaggio per backend, API, worker e strumenti: un binario unico, concorrenza semplice, una libreria standard solida e codice che resta valido negli anni. Non è la cura per tutto. Per siti, CMS ed e-commerce PHP e JavaScript restano la scelta più economica, e il frontend resta comunque JavaScript.
Per me un linguaggio è uno strumento, e lo scelgo guardando avanti: chi lo manterrà e quanto è facile verificare quello che ci viene scritto dentro, da me o da un agente AI. Quindi no, non mollo tutto. Aggiungo Go dove risolve un problema misurabile e lascio il resto dove funziona. Se stai valutando lo stack del tuo prossimo progetto, o vuoi capire se migrare una parte di un'applicazione esistente, scrivimi e ne parliamo.



