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

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

The new release of the Go language, version 1.24, comes six months after Go 1.23<\/a>. Most changes pertain to the implementation of the toolchain, runtime, and libraries. As always, the release ensures the promise of compatibility<\/a> Go 1. Developers expect nearly all Go programs to continue compiling and running as before.<\/p>\n

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

Changes to the language<\/h2>\n

<\/p>\n

Go 1.24 now fully supports type parameterized type aliases<\/a>: a type alias can be parameterized like a declared type. Details can be found in the language specification<\/a>. While 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

Tools<\/h2>\n

The go command<\/h3>\n

<\/p>\n

Go modules can now track executable dependencies using the tool directive in go.mod. This removes 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 the tools provided with Go. More information can be found in the documentation<\/a>.<\/p>\n

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

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

<\/p>\n

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

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

Executable files created via go run and the new behavior of go tool are now cached in the Go build cache. This enhances repeat launches due to increased caching. #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 seen in go help buildjson.<\/p>\n

<\/p>\n

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

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

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

<\/p>\n

The go build command now installs the version of the main module<\/a> in the compiled binary, based on the tag and\/or commit of the version control system. The suffix +dirty will be added if there are uncommitted changes. You can use the flag -buildvcs=false to omit version control information from the binary.<\/p>\n

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

New GODEBUG configuration<\/a> toolchaintrace=1<\/a> can now be used to track the process of toolchain selection in the go team.<\/p>\n

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

Cgo<\/h3>\n

<\/p>\n

Cgo supports new annotations for C functions to improve runtime performance. #cgo noescape cFunctionName tells the compiler that the memory passed to the C function cFunctionName does not escape. #cgo nocallback cFunctionName tells the compiler that the C function cFunctionName does not callback any Go functions. More information can be found in the cgo documentation<\/a>.<\/p>\n

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

Cgo currently refuses to compile calls to C functions that have multiple incompatible declarations. For example, if f is declared as both void f(int) and void f(double), cgo will report an error instead of potentially generating an incorrect call sequence f(0). New in this release is improved detection of this error condition when incompatible declarations appear in different files. #67699<\/a>.<\/p>\n

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

Objdump<\/h3>\n

The objdump tool now supports disassembly on 64-bit LoongArch (GOARCH=loong64), RISC-V (GOARCH=riscv64), and S390X (GOARCH=s390x).<\/p>\n

Vet<\/h3>\n

The new tests analyzer reports common errors in test declarations, fuzzers, benchmarks, and examples in test packages, such as improperly formed names, incorrect signatures, or examples documenting non-existent identifiers. Some of these errors can result in tests not running.<\/p>\n

<\/p>\n

The existing printf analyzer now reports diagnostics on calls of the form fmt.Printf(s), where s is a non-constant format string with no other arguments. Such calls are almost always an error, as the value of s may contain a %; instead, use fmt.Print. 60529<\/a>This check tends to make findings in existing code and is therefore only applied when the language version (as specified by the directive in the go.mod file or comments `\/\/go:build) is at least Go 1.24, to avoid causing build breaks in CI when upgrading to the Go 1.24 toolchain.<\/p>\n

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

The existing buildtag analyzer now reports diagnostics when there is an incorrect build constraint of an older version<\/a> Go in the directive \/\/go:build. For example, \/\/go:build go1.23.1 refers to a point release; instead use \/\/go:build go1.23. #64127<\/a>.<\/p>\n

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

The existing copylock analyzer now reports diagnostics when a variable declared in a triple 'for' loop, such as for i := iter(); done(i); i = next(i) { \u2026 }, contains sync.Locker, such as sync.Mutex. Go 1.22<\/a> changed the behavior of such loops to create a new variable for each iteration, copying values from the previous iteration; this copying is unsafe for locks. #66387<\/a>.<\/p>\n

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

GOCACHEPROG<\/h3>\n

<\/p>\n

The internal cmd\/go binary and test caching mechanism can now be implemented by child processes that implement the JSON protocol between the cmd\/go tool and a child process named by the environment variable GOCACHEPROG. Previously this was under GOEXPERIMENT. Protocol details can be found in the documentation<\/a>.<\/p>\n

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

Runtime<\/h2>\n

<\/p>\n

Several performance improvements in the runtime have reduced CPU overhead by 2-3% on average across a set of representative benchmarks. Results may vary based on the application. These improvements include a new built-in map implementation based on Swedish Tables<\/a>, more efficient memory allocation for small objects, and a new internal mutex implementation in the runtime.<\/p>\n

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

The new built-in map implementation and the new internal runtime mutex can be disabled with the settings GOEXPERIMENT=noswissmap and GOEXPERIMENT=nospinbitmutex during the build respectively.<\/p>\n

Compiler<\/h2>\n

The compiler has already forbidden the definition of new methods with receiver types that were generated by cgo, but it was possible to bypass this restriction via type aliasing. Go 1.24 now always reports an error if the receiver designates a generated cgo type, either directly or indirectly (via type alias).<\/p>\n

Linker<\/h2>\n

The linker now generates a GNU build ID (ELF NT_GNU_BUILD_ID record) on ELF platforms and a UUID (Mach-O LC_UUID load command) on macOS by default. The build ID or UUID is derived from the Go build ID. This can be disabled with the linker flag -B none, or overridden with the linker flag -B 0xNNNN with the user-specified hexadecimal value.<\/p>\n

Rollout<\/h2>\n

<\/p>\n

As stated in the Go 1.22 release notes<\/a>Go 1.24 now requires Go 1.22.6 or later for promotion. Developers expect that Go 1.26 will require a patch release of Go 1.24 or later for promotion.<\/p>\n

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

Standard library<\/h2>\n

Directory-restricted access to the filesystem<\/h3>\n

<\/p>\n

New type os.Root<\/a> provides the ability to perform filesystem operations within a specific directory.<\/p>\n

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

Function os.OpenRoot<\/a> opens a directory and returns os.Root<\/a>. Methods on os.Root<\/a> operate within this directory and do not allow paths to reference locations outside the directory, including those that follow symbolic links beyond the directory. Methods on os.Root mirror most filesystem operations available in the os package, including, for example, os.Root.Open<\/a>, os.Root.Create<\/a>, os.Root.Mkdir<\/a> and os.Root.Stat<\/a>.<\/p>\n

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

New benchmarking function<\/h3>\n

<\/p>\n

Benchmarks can now use a faster and less error-prone method testing.B.Loop<\/a> for iterating the benchmark like for b.Loop() { \u2026 } instead of the typical loop structures involving b.N like for range b.N. This offers two significant advantages:<\/p>\n

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