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 35 · Aug 25 – 31, 2025from 2 items

The Go team accepted a proposal that changes how temporary files are created during testing, and the community blog highlighted new testing patterns for asynchronous code.

Worth knowingstdlib

testing: use $GOTMPDIR for temporary files when set

What changed
The testing package will now use the $GOTMPDIR environment variable for temporary files when it is set.
Production impact
The source does not say.
Try it
Run a test with export GOTMPDIR=/tmp/go-test and observe that t.TempDir() creates files in that directory.
Source
github.com/golang/go/issues/61585
Explain it

Understand it, then run it

The testing package creates temporary files when a test needs them. Before the change, it always used the system’s temporary directory, the one returned by os.TempDir(). Now, if the environment variable GOTMPDIR is set, the testing package will use that directory instead. This lets developers run tests on machines where the normal temp directory is locked or otherwise unsuitable, without changing the rest of the system.

Nice to knowtooling

Testing Time (and other asynchronicities)

What changed
The blog discusses testing asynchronous code and introduces the testing/synctest package.
Production impact
The source does not say.
Try it
Read the blog and experiment with testing/synctest in a small Go program.
Source
go.dev/blog/testing-time
Explain it and run it

Understand it, then run it

Testing code that runs in the background can feel like a guessing game. You call a function, it returns immediately, and then somewhere else in the program it does something. If you want to make sure that thing happened, you have to wait for it, but you don’t know exactly how long to wait. The new testing/synctest package in Go 1.24 was created to make that waiting easier. It lets a test “observe” when the background work is finished without having to guess or sleep for a fixed time.

Run it now

Todaygo
// This program demonstrates the current way to test asynchronous code
// without the new testing/synctest package.  It starts a goroutine that
// sleeps for 100 milliseconds and then signals completion on a channel.
// The test waits on that channel instead of sleeping for a fixed time.
package main

import (
	"fmt"
	"time"
)

func main() {
	done := make(chan struct{})

	// Start a background task that will finish after 100ms.
	go func() {
		time.Sleep(100 * time.Millisecond)
		close(done)
	}()

	// Wait for the background task to finish.
	<-done
	fmt.Println("Background work completed")
}

What it printed when we ran it on Go 1.27.1

Background work completed

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.

Exercise

Create a small Go test that uses t.TempDir() to write a file, then run the test twice: once with GOTMPDIR unset and once with GOTMPDIR set to a custom directory. Observe where the temporary files are created.

The 60-second version

Hello, this week the Go team made a change to the testing package that now lets you control where temporary files are written by setting the GOTMPDIR environment variable. This can help when you need to keep test files in a specific location, for example under a security profile that restricts where applications can write. The change is a small tweak to the standard library, so it won’t break your code, but it gives you a new way to influence test behavior. In addition, the community blog highlighted new patterns for testing asynchronous code and introduced the testing/synctest package. If you’re writing tests that involve goroutines or other concurrent operations, this is a good resource to learn how to structure those tests more reliably. Both items are worth keeping in mind as you develop and run Go tests in production.

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