Summary of Go 1.24 Release Notes

Go 1.24 is a significant version iteration in the development of the Go language. While maintaining compatibility with previous versions, it comprehensively introduces numerous new features, optimizations, and improvements, effectively ensuring the smooth compilation and operation of the vast majority of Go programs. This update not only provides developers with more powerful programming tools but also significantly enhances the performance, security, and usability of the Go language.

I. Language Changes

Go 1.24 fully supports generic type aliases, allowing developers to parameterize type aliases in the same way as defining regular types. This feature greatly expands the flexibility of code writing, significantly improving code reusability and readability.

// Define a generic type alias
type MyAlias[T int | string] = T
func main() {
    var num MyAlias[int] = 10
    var str MyAlias[string] = "Hello, Go 1.24!"
}

Currently, developers can disable this feature by setting GOEXPERIMENT=noaliastypeparams. However, it should be noted that in the Go 1.25 version, the aliastypeparams setting will be officially removed.

II. Tools

The Go Command

In Go modules, the introduction of the tool directive makes it more convenient to track executable dependencies in the go.mod file. This approach replaces the previous practice of adding tools as blank imports to the "tools.go" file. Through the go tool command, not only can these custom tools be run, but also various tools included in the Go distribution. In addition, the go get command has a new -tool flag, which is specifically used to add the tool directive for a specified package. The tool meta - pattern provides convenience for batch - upgrading or installing all tools in a module, such as go get tool, go install tool.

Enhancements to Build and Test Commands

The executable files created by go run and go tool are now automatically cached in the Go build cache. This optimization greatly speeds up repeated executions, although it will correspondingly increase the cache space occupied. The go build, go install, and go test commands all have a new -json flag, which is used to output build results and error messages in structured JSON format. In the output of go test -json, the build and test result JSON data is distinguished by the new Action type. If there are problems in the test integration system, developers can set GODEBUG=gotestjsonbuildtext=1 to restore text - format output.

Authentication and Version Setting

To meet the authentication requirements for obtaining private modules in different scenarios, Go 1.24 has added the GOAUTH environment variable, providing a more flexible authentication method. The go build command sets the main module version of the compiled binary file based on the tags and/or commit information of the version control system. When there are uncommitted changes, the version number will automatically add the +dirty suffix. If developers want to ignore version control information, they can use the -buildvcs=false flag. At the same time, the new GODEBUG setting toolchaintrace=1 can help developers track the toolchain selection process of the go command.

Cgo

Cgo has gained new capabilities in Go 1.24, supporting new C function annotations to improve runtime performance. Among them, #cgo noescape cFunctionName is used to inform the compiler that the memory passed to cFunctionname will not escape; #cgo nocallback cFunctionName indicates that this C function will not call back any Go functions. In addition, Cgo's inspection of multiple incompatible declarations of C functions has become more stringent. When there are incompatible declarations in different files, errors can be detected and reported more timely and accurately.

Objdump

The Objdump tool has further expanded its support range in Go 1.24. It can now perform disassembly operations on 64 - bit LoongArch (GOARCH=loong64), RISC - V (GOARCH=riscv64), and S390X (GOARCH=s390x) architectures.

Vet

The Vet tool has added the tests analyzer, which is mainly used to check for common errors that may occur in the declarations of tests, fuzz tests, benchmarks, and examples in test packages, such as incorrect name formats, incorrect signatures, or non - existent identifiers in example records. This analyzer will run automatically when go test is executed. At the same time, the printf analyzer will diagnose calls to fmt.Printf(s) (where s is a non - constant format string with no other parameters) and suggest using fmt.Print instead. The buildtag analyzer checks for invalid Go major version build constraints in the //go:build directive; the copylock analyzer focuses on detecting variables containing sync.Locker (such as sync.Mutex) in 3 - clause "for" loops, effectively preventing unsafe lock copying operations.

GOCACHEPROG

The binary and test caching mechanism inside cmd/go can now be implemented by a child process through the GOCACHEPROG environment variable. The child process interacts with the cmd/go tool through the JSON protocol, which provides developers with more flexibility and customizability when dealing with cache - related operations.

III. Runtime

Go 1.24 has carried out a series of effective performance optimizations at runtime. Verified by a series of representative benchmark tests, it has an average 2 - 3% reduction in CPU overhead. These optimizations are mainly reflected in the new built - in map implementation based on the Swiss table, more efficient small - object memory allocation, and a new runtime internal mutex. If developers have special needs and want to disable the new built - in map implementation and the runtime internal mutex, they can achieve this during the build process by setting GOEXPERIMENT=noswissmap and GOEXPERIMENT=nospinbitmutex respectively.

IV. Compiler

In Go 1.24, the compiler has strengthened the inspection of cgo - generated types. Once the receiver represents a cgo - generated type (either directly or indirectly through an alias type), the compiler will always report an error message. This helps developers discover and solve potential problems earlier in the development process.

V. Linker

On the ELF platform, the linker will generate a GNU build ID (i.e., ELF NT_GNU_BUILD_ID note) by default; on the macOS platform, it will generate a UUID (i.e., Mach - O LC_UUID load command) by default. The generation of these IDs is derived from the Go build ID. If developers have special needs and want to disable this function, they can use the -B none flag; if they want to specify a user - defined hexadecimal value to override the default setting, they can use the -B 0xNNNN flag.

VI. Bootstrapping

The construction of Go 1.24 needs to be bootstrapped by relying on Go 1.22.6 or a higher version. As planned, the Go 1.26 version is expected to require a point release version of Go 1.24 or higher for bootstrapping.

VII. Standard Library

Directory - Restricted File System Access

The emergence of the os.Root type and the os.OpenRoot function provides developers with the ability to perform file system operations within a specific directory. Through this mechanism, it can be ensured that all operations are strictly restricted within the specified directory range, effectively preventing access to external locations through symbolic links, thereby improving the security and controllability of file system operations.

package main

import (
    "fmt"
    "os"
)

func main() {
    root, err := os.OpenRoot("/tmp")
    if err!= nil {
        fmt.Println("Error opening root:", err)
        return
    }
    defer root.Close()

    file, err := root.Create("test.txt")
    if err!= nil {
        fmt.Println("Error creating file:", err)
        return
    }
    defer file.Close()
}

New Benchmarking Functions

The testing.B.Loop method is more efficient and less error - prone than the traditional b.N - based loop structure. It can ensure that each -count only executes the benchmark function once. This not only reduces the number of executions of expensive setup and cleanup steps but also effectively keeps the function call parameters and results alive, preventing the compiler from performing unnecessary optimizations on the loop body.

package main

import (
    "testing"
)

func BenchmarkExample(b *testing.B) {
    for b.Loop() {
        // Actual benchmark code
    }
}

Improved Finalizers

The runtime.AddCleanup function is more flexible, efficient, and less error - prone than runtime.SetFinalizer. It allows developers to attach cleanup functions to objects. When an object becomes unreachable, the cleanup function will run automatically. This function supports attaching multiple cleanup functions to the same object, and it can even be attached to internal pointers. In the case of objects forming circular references, runtime.AddCleanup generally does not cause memory leaks and does not delay the release of the object and the objects it points to. Therefore, when writing new code, it is recommended to use runtime.AddCleanup first.

The New weak Package

The introduction of the weak package provides developers with weak pointers, which is very useful when creating memory - efficient structures, such as weak maps, canonical maps, and various caches. Combining runtime.AddCleanup and maphash.Comparable can better meet the usage requirements in these scenarios, further improving the memory management efficiency of the program.

The New crypto Package

The crypto/mlkem package has successfully implemented two post - quantum key - exchange mechanisms, ML - KEM - 768 and ML - KEM - 1024; the crypto/hkdf, crypto/pbkdf2, and crypto/sha3 packages have implemented relevant key - derivation functions and hash functions respectively. The implementations of these packages are based on the golang.org/x/crypto/... package, providing more tools and support for the application of the Go language in the field of cryptography.

FIPS 140 - 3 Compliance

Go 1.24 has introduced a new mechanism to promote FIPS 140 - 3 compliance. The Go crypto module, as a set of internal standard library packages, can transparently implement FIPS 140 - 3 approved algorithms, which means that applications can directly use these compliant algorithms without any modification. The GOFIPS140 environment variable is used to select the version of the Go crypto module to be used during the build process, and the fips140 GODEBUG setting is used to enable FIPS 140 - 3 mode at runtime. Currently, the Go crypto module version v1.0.0 included in Go 1.24 is being rigorously tested by a CMVP - recognized laboratory.

The New Experimental testing/synctest Package

The testing/synctest package specifically provides strong support for testing concurrent code. Among them, the synctest.Run function can start a group of goroutines in an isolated "bubble", in which the functions of the time package run based on a fake clock; the synctest.Wait function is used to wait for all goroutines in the current "bubble" to enter a blocked state. It should be noted that this package is currently in the experimental stage. To enable it during the build process, GOEXPERIMENT=synctest needs to be set, and its API may change in future versions.

Minor Changes to the Library

Go 1.24 has updated the functions and improved the methods of multiple standard library packages. For example, the archive package will automatically add a directory header when writing an empty directory; the bytes and strings packages have added multiple iterator - related functions, facilitating developers to operate on strings and byte slices; multiple sub - packages in the crypto package have adjusted and enhanced their methods and functions, further improving the security and performance of cryptography - related functions; the encoding package has added the TextAppender and BinaryAppender interfaces, optimizing the object serialization process; the net/http package has expanded its support for HTTP/2, providing developers with more powerful HTTP server and client development capabilities.

VIII. Ports

Go 1.24 also has some changes in the port requirements of the running environment. On the Linux system, the kernel version is required to be 3.2 or higher; it is the last version to support macOS 11 Big Sur. Starting from Go 1.25, macOS 12 Monterey or higher will be required. In terms of WebAssembly, the go:wasmexport directive has been added, supporting more types and build modes, and the location of relevant support files has also changed. In addition, the 32 - bit windows/arm port is marked as broken and may not work properly.