{"id":121950,"date":"2025-02-15T14:22:29","date_gmt":"2025-02-15T12:22:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/go-1-24"},"modified":"2025-02-15T14:22:29","modified_gmt":"2025-02-15T12:22:29","slug":"go-1-24","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/go-1-24","title":{"rendered":"Go 1.24","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Go <\/a> <\/p>\n

Nuova edizione del linguaggio Go, versione 1.24, dopo sei mesi da Go 1.23<\/a>. La maggior parte delle modifiche riguardano l'implementazione della toolchain, del runtime e delle librerie. Come sempre, il rilascio garantisce la promessa di compatibilit\u00e0<\/a> per Go 1. Gli sviluppatori del linguaggio si aspettano che quasi tutti i programmi Go continuino a compilarsi e funzionare come prima.<\/p>\n

<\/noindex><\/noindex> <\/p>\n

Modifiche al linguaggio<\/h2>\n

<\/p>\n

Go 1.24 ora supporta completamente gli alias generici di tipo<\/a>: un alias di tipo pu\u00f2 essere parametrizzato come un tipo dichiarato. Maggiori dettagli nella specifica del linguaggio<\/a>. Tuttavia, questa possibilit\u00e0 pu\u00f2 essere disabilitata impostando GOEXPERIMENT=noaliastypeparams; tuttavia, l'opzione aliastypeparams sar\u00e0 rimossa in Go 1.25.<\/p>\n

<\/noindex> <\/p>\n

Strumenti<\/h2>\n

Il comando go<\/h3>\n

<\/p>\n

I moduli go ora possono monitorare le dipendenze eseguibili utilizzando la direttiva tool in go.mod. Questo elimina la necessit\u00e0 della precedente soluzione di lavoro che prevedeva di aggiungere strumenti come importazioni vuote nel file, solitamente chiamato \u201ctools.go\u201d. Il comando go tool ora pu\u00f2 eseguire questi strumenti oltre agli strumenti forniti con Go. Maggiori informazioni possono essere trovate in documentazione<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Il nuovo flag -tool per go get porta all'aggiunta della direttiva dello strumento nel modulo attuale per i pacchetti specificati, oltre ad aggiungere direttive di dipendenza.<\/p>\n

<\/p>\n

Nuovo meta-pattern tool<\/a> fa riferimento a tutti gli strumenti nel modulo attuale. Questo pu\u00f2 essere utilizzato per aggiornarli tutti tramite go get tool o per installarli nella directory GOBIN tramite go install tool.<\/p>\n

<\/noindex> <\/p>\n

I file eseguibili creati tramite go run e il nuovo comportamento di go tool ora vengono memorizzati nella cache della build di Go. Questo rende le esecuzioni ripetute pi\u00f9 veloci grazie a un cache maggiore. #69290<\/a>.<\/p>\n

<\/noindex> <\/p>\n

I comandi go build e go install ora accettano il flag -json, che restituisce output e errori di compilazione come output strutturato JSON in standard output. I dettagli del formato possono essere trovati in go help buildjson.<\/p>\n

<\/p>\n

Inoltre, go test -json ora riporta output e errori di compilazione in JSON, mescolati con il JSON del risultato del test. Possono essere distinti per i nuovi tipi di action, ma se causano problemi nel sistema di integrazione dei test, \u00e8 possibile tornare all'output testuale della build tramite la configurazione GODEBUG<\/a> gotestjsonbuildtext=1.<\/p>\n

<\/noindex> <\/p>\n

La nuova variabile d'ambiente GOAUTH fornisce un modo flessibile per autorizzare il download privato dei moduli. Maggiori dettagli possono essere trovati in go help goauth.<\/p>\n

<\/p>\n

Il comando go build ora imposta la versione del modulo principale<\/a> nel binario compilato, basandosi sul tag e\/o sul commit del sistema di controllo versione. Il suffisso +dirty verr\u00e0 aggiunto in caso di modifiche non committate. Si pu\u00f2 utilizzare il flag -buildvcs=false per escludere le informazioni di controllo versione dal binario.<\/p>\n

<\/noindex> <\/p>\n

Nuova configurazione GODEBUG<\/a> toolchaintrace=1<\/a> ora pu\u00f2 essere utilizzata per monitorare il processo di selezione della toolchain nel comando go.<\/p>\n

<\/noindex> <\/p>\n

Cgo<\/h3>\n

<\/p>\n

Cgo supporta nuove annotazioni per le funzioni C per migliorare le prestazioni in fase di esecuzione. #cgo noescape cFunctionName dice al compilatore che la memoria passata alla funzione C cFunctionName non va persa. #cgo nocallback cFunctionName dice al compilatore che la funzione C cFunctionName non richiama alcuna funzione Go. Maggiori informazioni possono essere trovate nella documentazione cgo<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Cgo al momento rifiuta chiamate compilate a funzioni C che hanno dichiarazioni incompatibili. Ad esempio, se f \u00e8 dichiarata come sia void f(int) che void f(double), cgo riporter\u00e0 un errore invece di generare una sequenza di chiamate errata per f(0). Una novit\u00e0 in questa versione \u00e8 il miglioramento della rilevazione di questa condizione di errore quando dichiarazioni incompatibili appaiono in file diversi. #67699<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Objdump<\/h3>\n

Lo strumento objdump ora supporta la disassemblazione su LoongArch a 64 bit (GOARCH=loong64), RISC-V (GOARCH=riscv64) e S390X (GOARCH=s390x).<\/p>\n

Vet<\/h3>\n

Il nuovo analizzatore tests segnala errori comuni nelle dichiarazioni di test, fuzzers, benchmark e esempi nei pacchetti di test, come nomi malformati, firme errate o esempi che documentano identificatori inesistenti. Alcuni di questi errori possono causare il fallimento dei test.<\/p>\n

<\/p>\n

L'attuale analizzatore printf ora segnala diagnosi di chiamate nella forma fmt.Printf(s), dove s \u00e8 una stringa di formato non costante, senza altri argomenti. Queste chiamate sono quasi sempre un errore, poich\u00e9 il valore di s pu\u00f2 contenere il simbolo %; usa invece fmt.Print. 60529<\/a>. Questo controllo tende a fare rilevamenti nel codice esistente, e quindi viene applicato solo quando la versione del linguaggio (come specificato dalla direttiva go del file go.mod o dai commenti `\/\/go:build) \u00e8 almeno Go 1.24, per evitare di causare guasti all'integrazione continua durante l'aggiornamento alla toolchain Go 1.24.<\/p>\n

<\/noindex> <\/p>\n

L'analizzatore buildtag esistente ora riporta diagnostiche quando c'\u00e8 un errore di restrizione della versione di build precedente<\/a> Go nella direttiva \/\/go:build. Ad esempio, \/\/go:build go1.23.1 si riferisce a un release patch; invece usa \/\/go:build go1.23. #64127<\/a>.<\/p>\n

<\/noindex> <\/p>\n

L'analizzatore copylock esistente ora riporta diagnostiche quando una variabile, dichiarata in un ciclo 'for' triplo, come for i := iter(); done(i); i = next(i) { ... }, contiene un sync.Locker, come sync.Mutex. Go 1.22<\/a> ha cambiato il comportamento di tali cicli per creare una nuova variabile per ogni iterazione, copiando i valori dalla iterazione precedente; questa copia non \u00e8 sicura per i lock. #66387<\/a>.<\/p>\n

<\/noindex> <\/p>\n

GOCACHEPROG<\/h3>\n

<\/p>\n

Il binario interno cmd\/go e il meccanismo di caching dei test possono ora essere implementati in processi secondari, implementando un protocollo JSON tra lo strumento cmd\/go e il processo secondario nominato dalla variabile d'ambiente GOCACHEPROG. In precedenza era per GOEXPERIMENT. I dettagli del protocollo possono essere visti in documentazione<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Tempo di esecuzione<\/h2>\n

<\/p>\n

Diverse migliorie nelle prestazioni a runtime hanno ridotto le spese per la CPU del 2-3% in media su un set di benchmark rappresentativi. I risultati possono variare a seconda dell'applicazione. Queste miglior\u00ece includono una nuova implementazione incorporata di map basata su Tabelle Svedesi<\/a>, allocazione di memoria pi\u00f9 efficiente per piccoli oggetti e una nuova implementazione interna del mutex a runtime.<\/p>\n

<\/noindex> <\/p>\n

La nuova implementazione di map incorporata e il nuovo mutex interno a runtime possono essere disabilitati con le impostazioni GOEXPERIMENT=noswissmap e GOEXPERIMENT=nospinbitmutex durante la build, rispettivamente.<\/p>\n

Compilatore<\/h2>\n

Il compilatore ha gi\u00e0 vietato la definizione di nuovi metodi con tipi di ricevitori generati da cgo, ma era possibile aggirare questa restrizione attraverso un alias di tipo. Go 1.24 ora genera sempre un errore se il ricevitore denota un tipo cgo generato, direttamente o indirettamente (attraverso un alias di tipo).<\/p>\n

Linker<\/h2>\n

Il linker ora genera un identificativo di build GNU (record ELF NT_GNU_BUILD_ID) sulle piattaforme ELF e UUID (comando di caricamento Mach-O LC_UUID) su macOS per impostazione predefinita. L'identificativo di build o UUID viene derivato dall'identificativo di build di Go. Questo pu\u00f2 essere disattivato con il flag del linker -B none, oppure sovrascritto con il flag del linker -B 0xNNNN con un valore esadecimale fornito dall'utente.<\/p>\n

Rollout<\/h2>\n

<\/p>\n

Come indicato in note di rilascio di Go 1.22<\/a>, Go 1.24 ora richiede Go 1.22.6 o versione successiva per l'avvio. Gli sviluppatori si aspettano che Go 1.26 richieder\u00e0 un rilascio patch di Go 1.24 o superiore per l'avvio.<\/p>\n

<\/noindex> <\/p>\n

Libreria standard<\/h2>\n

Accesso al file system limitato dalla directory<\/h3>\n

<\/p>\n

Nuovo tipo os.Root<\/a> consente di eseguire operazioni sul file system all'interno di una directory specifica.<\/p>\n

<\/noindex> <\/p>\n

La funzione os.OpenRoot<\/a> apre una directory e restituisce os.Root<\/a>. I metodi su os.Root<\/a> operano in questa directory e non consentono ai percorsi di fare riferimento a posizioni al di fuori della directory, comprese quelle che seguono collegamenti simbolici al di fuori della directory. I metodi su os.Root riflettono la maggior parte delle operazioni del file system disponibili nel pacchetto os, inclusi, ad esempio, os.Root.Open<\/a>, os.Root.Create<\/a>, os.Root.Mkdir<\/a> e os.Root.Stat<\/a>.<\/p>\n

<\/noindex> <\/p>\n

Nuova funzione di benchmark<\/h3>\n

<\/p>\n

I benchmark possono ora utilizzare un metodo pi\u00f9 veloce e meno soggetto a errori testing.B.Loop<\/a> per eseguire iterazioni del benchmark come for b.Loop() { \u2026 } invece delle tipiche strutture cicliche che coinvolgono b.N come for range b.N. Questo offre due vantaggi significativi:<\/p>\n

<\/noindex> <\/p>\n