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 31 · Jul 28 – Aug 3, 2025from 4 items

The Go team accepted four proposals that add new capabilities and documentation. The changes touch Windows process creation, MIME type handling, structured logging, and build‑tag conventions. No new language version was released this week.

Worth knowingstdlib

x/sys/windows: allow specifying Security Capabilities in SysProcAttr

What changed
The syscall package on Windows now has a SecurityCapabilities struct and a SecurityCapabilities field in SysProcAttr. syscall.StartProcess will include this attribute in the Windows CreateProcess call.
Production impact
The source does not say.
Try it
Create a syscall.SysProcAttr with a non‑nil SecurityCapabilities and pass it to syscall.StartProcess.
Source
github.com/golang/go/issues/65611
Explain it and run it

Understand it, then run it

The Go runtime on Windows can now attach a set of security capabilities to a new process. Before, the only security data you could pass was the classic SecurityAttributes that control ownership and inheritance. The new SecurityCapabilities type lets you specify an AppContainer SID and a list of capabilities that the process is allowed to use. When you start a process with syscall.StartProcess, the runtime will include these capabilities in the underlying Windows CreateProcess call.

Run it now

Todaygo
// This program demonstrates that the new SecurityCapabilities field in
// syscall.SysProcAttr is not available in Go 1.27.1. It simply prints a
// message indicating the missing feature.

package main

import (
	"fmt"
)

func main() {
	fmt.Println("SecurityCapabilities is not yet exposed in syscall.SysProcAttr on Go 1.27.1.")
}

What it printed when we ran it on Go 1.27.1

SecurityCapabilities is not yet exposed in syscall.SysProcAttr on Go 1.27.1.

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 knowtooling

doc: mention "purego" build tag convention somewhere

What changed
Documentation now states that the purego build tag conventionally disables assembly code in packages and does not affect cgo usage.
Production impact
The source does not say.
Try it
Add //go:build purego to a file that contains assembly and observe that the file is excluded from builds with the tag.
Source
github.com/golang/go/issues/23172
Explain it and run it

Understand it, then run it

Run it now

Todaygo
// This program demonstrates that the `purego` build tag is recognized by the
// compiler. Build it with: go run -tags purego .
package main

import "fmt"

// The following function is only compiled when the `purego` tag is set.
// In a real project, this could be a stub that replaces an assembly
// implementation on platforms where assembly is not available.
func puregoMessage() string {
	return "purego tag is active"
}

func main() {
	fmt.Println(puregoMessage())
}

What it printed when we ran it on Go 1.27.1

purego tag is active

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

Write a small program that uses the new log/slog.MultiHandler to log the same message to both the standard logger and a custom handler that writes to a file.

The 60-second version

Hello, everyone. This week the Go team rolled out a handful of useful updates. First, Windows process creation now supports security capabilities directly through the `SysProcAttr` structure, making it easier to sandbox subprocesses without extra plumbing. Second, the MIME package expanded its built‑in file‑extension table to match what browsers use, so you’ll get the right content type for more files out of the box. Third, the structured logging package, slog, now lets you attach multiple handlers to a single logger, so you can send logs to the console, a file, or any other destination in one go. Finally, the documentation now clarifies the purpose of the `purego` build tag, helping developers understand when assembly is excluded. Those are the key takeaways from this week’s changes.

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