{"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\/hu\/blog\/news\/go-1-24","title":{"rendered":"Go 1.24","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

A Go program, version 1.24, is being released six months after Go 1.23<\/a>. Most changes focus on the implementation of toolchain, runtime, and libraries. As always, the release provides the promise of compatibility<\/a> Go 1. Developers of the language expect that almost all Go programs will continue to compile and run as before.<\/p>\n

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

Changes in the language<\/h2>\n

<\/p>\n

Go 1.24 now fully supports generic type aliases<\/a>: a type alias can be parameterized as a declared type. Details can be found in the language specification<\/a>. Currently, this feature can be disabled by setting GOEXPERIMENT=noaliastypeparams; however, the aliastypeparams option will be removed in Go 1.25.<\/p>\n

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

Eszk\u00f6z\u00f6k<\/h2>\n

The go team<\/h3>\n

<\/p>\n

Go modules can now track executable dependencies using the tool directive in go.mod. This eliminates the need for the previous workaround of adding tools as empty imports in a file commonly called 'tools.go'. The go tool command can now run these tools in addition to those supplied with Go. More information can be found in dokument\u00e1ci\u00f3<\/a>.<\/p>\n

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

The new -tool flag for go get adds the tool directive to the current module for specified packages in addition to adding requirement directives.<\/p>\n

<\/p>\n

\u00daj the meta-pattern tool<\/a> refers to all tools in the current module. This can be used to update them all via go get tool or to install them in your GOBIN directory via go install tool.<\/p>\n

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

Executable files created via go run and the new go tool behavior are now cached in the Go build cache. This makes repeated runs faster due to an increased cache. #69290<\/a>.<\/p>\n

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

The go build and go install commands now accept the -json flag, which reports output and build errors as structured JSON output to standard output. Details of the format can be found in go help buildjson.<\/p>\n

<\/p>\n

Moreover, go test -json now reports output and build errors in JSON, intermixed with JSON test result output. They can be distinguished by new Action types, but if they cause issues in the testing integration system, you can revert to textual build output via the GODEBUG setting<\/a> gotestjsonbuildtext=1.<\/p>\n

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

The new environment variable GOAUTH provides a flexible way to authenticate private module pulls. See details in go help goauth.<\/p>\n

<\/p>\n

The go build command now sets the version of the primary module<\/a> a leford\u00edtott bin\u00e1ris f\u00e1jlban, a c\u00edmke \u00e9s\/vagy a verzi\u00f3kezel\u0151 rendszer commitja alapj\u00e1n. A +dirty suffix hozz\u00e1ad\u00f3dik, ha nem ellen\u0151rz\u00f6tt v\u00e1ltoz\u00e1sok vannak. Haszn\u00e1lhatja a -buildvcs=false flaget, hogy kihagyja a verzi\u00f3kezel\u00e9si inform\u00e1ci\u00f3t a bin\u00e1risb\u00f3l.<\/p>\n

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

\u00daj GODEBUG be\u00e1ll\u00edt\u00e1sa<\/a> toolchaintrace=1<\/a> most m\u00e1r haszn\u00e1lhat\u00f3 a go csapat k\u00f6r\u00fcli toolchain kiv\u00e1laszt\u00e1si folyamat k\u00f6vet\u00e9s\u00e9re.<\/p>\n

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

Cgo<\/h3>\n

<\/p>\n

A Cgo \u00faj annot\u00e1ci\u00f3kat t\u00e1mogat a C f\u00fcggv\u00e9nyek teljes\u00edtm\u00e9ny\u00e9nek jav\u00edt\u00e1sa \u00e9rdek\u00e9ben. #cgo noescape cFunctionName azt mondja a ford\u00edt\u00f3nak, hogy a C f\u00fcggv\u00e9nynek, cFunctionName eljuttatott mem\u00f3ria nem sz\u00f6kik el. #cgo nocallback cFunctionName azt mondja a ford\u00edt\u00f3nak, hogy a C cFunctionName nem h\u00edv vissza Go f\u00fcggv\u00e9nyeket. T\u00f6bb inform\u00e1ci\u00f3 tal\u00e1lhat\u00f3 itt: cgo dokument\u00e1ci\u00f3<\/a>.<\/p>\n

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

A Cgo most m\u00e1r elutas\u00edtja a C f\u00fcggv\u00e9nyek ford\u00edt\u00e1s\u00e1t, amelyeknek t\u00f6bb inkompatibilis deklar\u00e1ci\u00f3ja van. P\u00e9ld\u00e1ul, ha f-t egyszerre void f(int) \u00e9s void f(double) n\u00e9ven deklar\u00e1lt\u00e1k, a cgo hib\u00e1t fog jelezni az esetleges hib\u00e1s h\u00edv\u00e1si sorrend gener\u00e1l\u00e1sa helyett. \u00dajdons\u00e1g ebben a kiad\u00e1sban a hiba\u00e1llapot jobb \u00e9szlel\u00e9se, amikor az inkompatibilis deklar\u00e1ci\u00f3k k\u00fcl\u00f6nb\u00f6z\u0151 f\u00e1jlokban jelennek meg. #67699<\/a>.<\/p>\n

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

Objdump<\/h3>\n

Az objdump eszk\u00f6z most m\u00e1r t\u00e1mogatja a 64 bites LoongArch (GOARCH=loong64), RISC-V (GOARCH=riscv64) \u00e9s S390X (GOARCH=s390x) disassembly-t.<\/p>\n

Vet<\/h3>\n

Az \u00faj tests elemz\u0151 gyakori hib\u00e1kat jelez a tesztel\u00e9sek, fuzzerek, benchmarkok \u00e9s p\u00e9ld\u00e1k bejelent\u00e9s\u00e9ben, p\u00e9ld\u00e1ul helytelen\u00fcl form\u00e1zott neveket, \u00e9rv\u00e9nytelen al\u00e1\u00edr\u00e1sokat vagy olyan p\u00e9ld\u00e1kat, amelyek nem l\u00e9tez\u0151 azonos\u00edt\u00f3kat dokument\u00e1lnak. Ezek k\u00f6z\u00fcl n\u00e9h\u00e1ny hiba a tesztek nem teljes\u00edt\u00e9s\u00e9hez vezethet.<\/p>\n

<\/p>\n

A megl\u00e9v\u0151 printf elemz\u0151 most diagnosztiz\u00e1lja a fmt.Printf(s) h\u00edv\u00e1sokat, ahol s - nem \u00e1lland\u00f3 form\u00e1tum\u00fa string, m\u00e1s argumentumok n\u00e9lk\u00fcl. Az ilyen h\u00edv\u00e1sok szinte mindig hib\u00e1sak, mivel az s \u00e9rt\u00e9ke tartalmazhatja a % karaktert; helyette haszn\u00e1lja a fmt.Print-ot. 60529<\/a>. Ez az ellen\u0151rz\u00e9s hajlamos felfedezni a megl\u00e9v\u0151 k\u00f3dban, ez\u00e9rt csak akkor alkalmazand\u00f3, amikor a nyelv verzi\u00f3ja (amint azt a go.mod f\u00e1jl vagy a `\/\/go:build` megjegyz\u00e9sek hat\u00e1rozz\u00e1k meg) legal\u00e1bb Go 1.24, hogy elker\u00fclj\u00fck a hossz\u00fa t\u00e1v\u00fa integr\u00e1ci\u00f3s hib\u00e1kat, amikor a Go 1.24-es toolchain-re friss\u00edt\u00fcnk.<\/p>\n

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

A megl\u00e9v\u0151 buildtag elemz\u0151 most diagnosztik\u00e1t jelent, amikor hib\u00e1s a r\u00e9gi verzi\u00f3k buildkorl\u00e1toz\u00e1sa<\/a> Go a \/\/go:build direkt\u00edv\u00e1ban. P\u00e9ld\u00e1ul, \/\/go:build go1.23.1 a pontszer\u0171 kiad\u00e1sra utal; ehelyett haszn\u00e1lja a \/\/go:build go1.23. #64127<\/a>.<\/p>\n

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

A megl\u00e9v\u0151 copylock elemz\u0151 most diagnosztik\u00e1t jelent, amikor egy v\u00e1ltoz\u00f3, amelyet egy h\u00e1romsoros \u201cfor\u201d ciklusban hirdettek meg, mint p\u00e9ld\u00e1ul for i := iter(); done(i); i = next(i) { \u2026 }, sync.Locker-t, p\u00e9ld\u00e1ul sync.Mutexot tartalmaz. Go 1.22<\/a> megv\u00e1ltoztatta az ilyen ciklusok viselked\u00e9s\u00e9t, \u00faj v\u00e1ltoz\u00f3 l\u00e9trehoz\u00e1s\u00e1val minden iter\u00e1ci\u00f3hoz, az el\u0151z\u0151 iter\u00e1ci\u00f3b\u00f3l sz\u00e1rmaz\u00f3 \u00e9rt\u00e9kek m\u00e1sol\u00e1s\u00e1val; ez a m\u00e1sol\u00e1s nem biztons\u00e1gos a z\u00e1rol\u00e1sok sz\u00e1m\u00e1ra. #66387<\/a>.<\/p>\n

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

GOCACHEPROG<\/h3>\n

<\/p>\n

A cmd\/go bels\u0151 bin\u00e1ris \u00e9s a tesztel\u00e9si cache mechanizmus most megval\u00f3s\u00edthat\u00f3 gyermeks folyamatok \u00e1ltal, amelyek JSON protokollt val\u00f3s\u00edtanak meg a cmd\/go eszk\u00f6z \u00e9s a gyermek folyamat k\u00f6z\u00f6tt, amelyet a GOCACHEPROG k\u00f6rnyezeti v\u00e1ltoz\u00f3 nevezett el. Kor\u00e1bban ez a GOEXPERIMENT volt. A protokoll r\u00e9szletei megtekinthet\u0151k itt dokument\u00e1ci\u00f3<\/a>.<\/p>\n

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

Kib\u0151v\u00edtett fut\u00e1si id\u0151<\/h2>\n

<\/p>\n

T\u00f6bb teljes\u00edtm\u00e9nyjav\u00edt\u00e1s a runtime-ban 2-3% -kal cs\u00f6kkentette a CPU k\u00f6lts\u00e9geket \u00e1tlagosan a reprezentat\u00edv benchmark k\u00e9szlet k\u00f6z\u00f6tt. Az eredm\u00e9nyek alkalmaz\u00e1sonk\u00e9nt v\u00e1ltozhatnak. Ezek a jav\u00edt\u00e1sok egy \u00faj be\u00e9p\u00edtett map megval\u00f3s\u00edt\u00e1st tartalmaznak Sv\u00e9d T\u00e1bl\u00e1k<\/a>, hat\u00e9konyabb kis objektumok mem\u00f3riakezel\u00e9s\u00e9t \u00e9s egy \u00faj bels\u0151 runtime mutex megval\u00f3s\u00edt\u00e1st.<\/p>\n

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

Az \u00faj be\u00e9p\u00edtett map megval\u00f3s\u00edt\u00e1s \u00e9s az \u00faj bels\u0151 runtime mutex deaktiv\u00e1lhat\u00f3 a GOEXPERIMENT=noswissmap \u00e9s a GOEXPERIMENT=nospinbitmutex be\u00e1ll\u00edt\u00e1sokkal a ford\u00edt\u00e1s sor\u00e1n.<\/p>\n

Ford\u00edt\u00f3<\/h2>\n

A ford\u00edt\u00f3 m\u00e1r megtiltotta \u00faj met\u00f3dusok defini\u00e1l\u00e1s\u00e1t olyan fogyaszt\u00f3i t\u00edpusokkal, amelyeket cgo gener\u00e1l; de ezt a t\u00edpusali\u00e1s \u00e1thidalhatta. A Go 1.24 most mindig hib\u00e1t jelez, ha a fogyaszt\u00f3 egy gener\u00e1lt cgo t\u00edpust jel\u00f6l, k\u00f6zvetlen\u00fcl vagy k\u00f6zvetve (t\u00edpus ali\u00e1son kereszt\u00fcl).<\/p>\n

Linker<\/h2>\n

A linker most alap\u00e9rtelmez\u00e9s szerint gener\u00e1l GNU build azonos\u00edt\u00f3t (ELF NT_GNU_BUILD_ID bejegyz\u00e9s) ELF platformokon, \u00e9s UUID-t (Mach-O LC_UUID t\u00f6lt\u00e9si parancs) macOS-en. Az azonos\u00edt\u00f3 vagy UUID a Go build azonos\u00edt\u00f3b\u00f3l sz\u00e1rmazik. Ez letilthat\u00f3 a linker -B none kapcsol\u00f3j\u00e1val, vagy fel\u00fcl\u00edrhat\u00f3 a linker -B 0xNNNN kapcsol\u00f3j\u00e1val az adott felhaszn\u00e1l\u00f3i hexadecim\u00e1lis \u00e9rt\u00e9kkel.<\/p>\n

Feldolgoz\u00e1s<\/h2>\n

<\/p>\n

Ahogy azt a Go 1.22 kiad\u00e1si megjegyz\u00e9seiben jelezt\u00e9k<\/a>, Go 1.24 most now requires Go 1.22.6 or later for development. Developers expect that Go 1.26 will require a patch release of Go 1.24 or later for development.<\/p>\n

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

Szabv\u00e1nyos k\u00f6nyvt\u00e1r<\/h2>\n

Korl\u00e1tozott mapp\u00e1hoz val\u00f3 hozz\u00e1f\u00e9r\u00e9s a f\u00e1jlrendszerhez<\/h3>\n

<\/p>\n

\u00daj t\u00edpus os.Root<\/a> lehet\u0151v\u00e9 teszi a f\u00e1jlrendszer m\u0171veletek v\u00e9grehajt\u00e1s\u00e1t egy adott mapp\u00e1n bel\u00fcl.<\/p>\n

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

Funkci\u00f3 os.OpenRoot<\/a> megnyitja a mapp\u00e1t \u00e9s visszaadja os.Root<\/a>. Az os.Root-on v\u00e9gzett m\u00f3dszerek ebben a mapp\u00e1ban m\u0171k\u00f6dnek, \u00e9s nem engedik meg az \u00fatvonalak sz\u00e1m\u00e1ra, hogy hivatkozzanak a mapp\u00e1n k\u00edv\u00fcli helyekre, bele\u00e9rtve a szimbolikus linkeken k\u00edv\u00fcli helyeket is. Az os.Root-on l\u00e9v\u0151 m\u00f3dszerek a f\u00e1jlrendszer sz\u00e1mos m\u0171velet\u00e9t t\u00fckr\u00f6zik, amelyek el\u00e9rhet\u0151k az os csomagban, bele\u00e9rtve p\u00e9ld\u00e1ul a os.Root<\/a> os.Root.Open os.Root.Create<\/a>, os.Root.Mkdir<\/a>, os.Root.Stat<\/a> \u00e9s \u00daj benchmark funkci\u00f3<\/a>.<\/p>\n

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

A benchmarkok most gyorsabb \u00e9s megb\u00edzhat\u00f3bb m\u00f3dszert haszn\u00e1lhatnak<\/h3>\n

<\/p>\n

testing.B.Loop a benchmark iter\u00e1ci\u00f3k v\u00e9grehajt\u00e1s\u00e1hoz, mint p\u00e9ld\u00e1ul for b.Loop() { \u2026 } a tipikus ciklus strukt\u00far\u00e1k helyett, amelyekben b.N szerepel, mint p\u00e9ld\u00e1ul for range b.N. Ez k\u00e9t jelent\u0151s el\u0151nyt k\u00edn\u00e1l:<\/a> A benchmark funkci\u00f3 pontosan egyszer hajt\u00f3dik v\u00e9gre minden -count sor\u00e1n, \u00edgy a k\u00f6lts\u00e9ges be\u00e1ll\u00edt\u00e1si \u00e9s tiszt\u00edt\u00e1si l\u00e9p\u00e9sek csak egyszer t\u00f6rt\u00e9nnek meg.<\/p>\n

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