This site is being rebuilt and some pages are out of date. For current details, write to [email protected]. This notice goes away when the rebuild is done.

No analytics unless you allow it, no tracking. This site keeps in your browser the language you pick, the theme, its colour, which site you chose, the currency on the pricing page and that you closed this notice; signing in adds session cookies. The legal page has the details.

Sign in

Quiet Pager · Radar

What changed in Go, Rust and Solidity this week.

What changed this week, from each project's own release notes, proposals and issues, with an exercise you can run for each change.

Written by a model · reviewed by a person · published Mondays · Atom feed

Archive · Week 21 · May 19 – 25, 2025from 10 items

This week the Go team accepted a handful of proposals that add convenience helpers, improve testing ergonomics, and tighten the runtime’s interaction with the operating system. The changes are mostly non‑breaking, but a few introduce new APIs that will surface in the next release.

Worth knowingtooling

testing/synctest: replace Run with Test

What changed
The synctest.Run function is replaced by synctest.Test, which executes a test function in a new goroutine bubble and waits for all goroutines in that bubble to exit.
Production impact
The source does not say.
Try it
Run a test using synctest.Test(t, func(t *testing.T) { … }) instead of synctest.Run.
Source
github.com/golang/go/issues/73567
Explain it and run it

Understand it, then run it

The Go testing package has a feature called *synctest* that lets you run code in a controlled environment called a “bubble.” Previously the function that started a bubble was named Run. The change replaces that function with a new name, Test. Test behaves the same way: it starts a goroutine, runs your test function inside it, and waits until all goroutines in that bubble finish before returning.

Run it now

Todaygo
// This program demonstrates that the experimental synctest package
// is not available in the standard Go 1.27.1 distribution.
// Attempting to import golang.org/x/synctest will fail with a
// module not found error, as shown when running this file.
package main

import "fmt"

func main() {
	fmt.Println("synctest is not part of Go 1.27.1; importing it fails.")
}

What it printed when we ran it on Go 1.27.1

synctest is not part of Go 1.27.1; importing it fails.

Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.

Worth knowingtooling

testing/synctest: new package for testing concurrent code

What changed
A new package testing/synctest was added, providing Test and Wait helpers for concurrent testing.
Production impact
The source does not say.
Try it
Import testing/synctest and call synctest.Test(t, func(t *testing.T) { … }).
Source
github.com/golang/go/issues/67434
Explain it

Understand it, then run it

A new package called testing/synctest was added to the Go standard library. It lets you run a test in its own “bubble” of goroutines and then wait until all of those goroutines are idle or finished. The main functions are Test and Wait. Test runs a function in a new bubble and blocks until every goroutine in that bubble exits. Wait can be called inside that bubble to pause until every other goroutine in the bubble is blocked on something like a channel or a timer. This makes it easier to test code that uses timers or runs many goroutines without having to sleep for real time or guess when work is done.

After the change ships

go · the proposal's code; it does not compile until the change ships

// This code does not compile until the synctest package is available in Go 1.27.1.
package main

import (
	"testing"

	"golang.org/x/testing/synctest"
)

func main() {
	synctest.Test(&testing.T{}, func(t *testing.T) {
		// test body
	})
}

Worth knowingruntime

runtime: CPU limit‑aware GOMAXPROCS default

What changed
The runtime on Linux now uses CPU cgroup quota limits to set the default value of GOMAXPROCS.
Production impact
The source does not say.
Try it
Run a program inside a cgroup with a CPU quota and observe the value of runtime.GOMAXPROCS().
Source
github.com/golang/go/issues/73193
Explain it and run it

Understand it, then run it

The Go runtime now looks at the CPU limits that a container or cgroup imposes on the process. Before, the default value of GOMAXPROCS was simply the number of logical CPUs that the machine reports. If a program ran inside a container that was allowed only a fraction of the host’s CPUs, the runtime would still think it could use all of them, which could cause the program to be throttled by the kernel. With the change, the runtime reads the cgroup quota and sets GOMAXPROCS to that value instead. This means a Go program automatically respects the CPU limits that the operating system or container runtime has applied to it.

Run it now

Todaygo
// This program prints the default GOMAXPROCS value that the runtime has chosen.
// On Linux, the runtime now uses the CPU cgroup quota to set this value.
// If the program is not running inside a cgroup with a quota, the value will
// be the number of logical CPUs or the affinity mask, whichever is lower.
package main

import (
	"fmt"
	"runtime"
)

func main() {
	fmt.Printf("GOMAXPROCS default: %d\n", runtime.GOMAXPROCS(0))
}

What it printed when we ran it on Go 1.27.1

GOMAXPROCS default: 2

Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.

Nice to knowstdlib

hash: add Clone

What changed
The hash package now defines a Cloner interface and implements Clone on most standard library hash types.
Production impact
The source does not say.
Try it
Call h.Clone() on a hash.Hash value.
Source
github.com/golang/go/issues/69521

Nice to knowstdlib

go/ast: deprecate MergePackageFiles

What changed
go/ast.MergePackageFiles was marked deprecated because it is not used and buggy.
Production impact
The source does not say.
Try it
Search for MergePackageFiles in your codebase and replace it with alternatives.
Source
github.com/golang/go/issues/7124
Explain it and run it

Understand it, then run it

Run it now

Todaygo
// This program demonstrates that `go/ast.MergePackageFiles` is deprecated
// and no longer available in Go 1.27.1. It simply prints a message
// confirming the deprecation status. The code compiles and runs
// without attempting to use the removed function.

package main

import "fmt"

func main() {
	// The MergePackageFiles function has been removed from the
	// go/ast package. Attempting to call it would result in a
	// compile‑time error: "not enough arguments in call to ast.MergePackageFiles".
	// Therefore, we only acknowledge its deprecation here.
	fmt.Println("go/ast.MergePackageFiles is deprecated and no longer available.")
}

What it printed when we ran it on Go 1.27.1

go/ast.MergePackageFiles is deprecated and no longer available.

Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.

Nice to knowstdlib

go/ast: deprecate FilterPackage, PackageExports, MergePackageFiles

What changed
The functions that operate on the deprecated ast.Package type were all marked deprecated.
Production impact
The source does not say.
Try it
Replace calls to FilterPackage or PackageExports with FilterFile or FileExports.
Source
github.com/golang/go/issues/73088

Nice to knowecosystem

Go Cryptography Security Audit

What changed
Trail of Bits performed a security audit of Go’s cryptography libraries.
Production impact
The source does not say.
Try it
Read the audit report for insights into potential vulnerabilities.
Source
go.dev/blog/tob-crypto-audit

Exercise

Write a small program that uses the new os.Root.ReadFile method to read a file named hello.txt located in the current directory and prints its contents.

The 60-second version

Good morning. This week the Go team added a few handy helpers and tightened some runtime behavior. They introduced a new `testing/synctest` package that lets you run concurrent tests in isolated goroutine bubbles, and they replaced the old `Run` function with a cleaner `Test` API. In the standard library, you’ll now find `ReadFile` and `WriteFile` methods on `os.Root`, a convenient `GroupAttrs` helper for structured logging, and a `Clone` method on most hash types. The runtime on Linux will now respect CPU cgroup quotas when setting the default `GOMAXPROCS`, which can help your services adapt to container limits. The `go/ast` package has marked several legacy functions as deprecated, nudging users toward newer APIs. Finally, the TLS package now offers a callback to dynamically supply Encrypted Client Hello keys, giving you more flexibility when handling ECH. And, as a reminder, Trail of Bits completed a security audit of Go’s cryptography libraries, so you can review the findings to stay ahead of any potential issues. That’s all for this week’s radar.

Written by gpt-oss-20b · claims checked against the sources · archive, not individually reviewed