Maintenance: the chat on this site is being replaced by the Ask Io widget, so it may drop out for a short while. Where you see Io or the Ask widget, you are talking to an AI. Some pages are also out of date while we rebuild; write to reach@inorbit.hr for current details. This notice goes away when both are 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 and Rust in week 41, 2026.

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

Radar #003 · Week 41 · Oct 5 – 11, 2026from 7 items

Go 1.27.2 and Go 1.26.9 point releases were published, and several long‑standing packages and APIs were accepted for deprecation and removal.

Worth knowingecosystem

Deprecate and delete x/sys/execabs

What changed
The proposal to add //go:fix directives, mark the package deprecated, wait a month after tagging, then isolate, tag, and delete x/sys/execabs was accepted.
Production impact
The source does not say.
Try it
Run go vet -fix on a module that imports x/sys/execabs to see the suggested migration to os/exec.
Source
github.com/golang/go/issues/64047
Explain it and run it

Understand it, then run it

The x/sys/execabs package was a thin wrapper around os/exec that existed to work around a security issue before Go 1.19. Starting with Go 1.19 the behavior of os/exec was changed to include that fix, and the wrapper is no longer needed. The proposal accepted in October 2026 marks x/sys/execabs as deprecated, adds //go:fix directives to point users to os/exec, and plans to delete the package after a month of tagging.

For a new Go programmer, this means you should import and use os/exec directly for running external commands. The extra import of x/sys/execabs is now discouraged and will eventually disappear.

The change does not affect the language itself; it only removes an unnecessary compatibility layer.

If you see a deprecation warning about x/sys/execabs, replace the import with os/exec and the code will continue to work.

Run it now

Todaygo
package main

import (
	"fmt"
	"os/exec"
)

func main() {
	// Demonstrate the current way to run an external command.
	// The execabs wrapper has been deprecated, so we use os/exec directly.
	cmd := exec.Command("echo", "execabs deprecated")
	output, err := cmd.CombinedOutput()
	if err != nil {
		fmt.Printf("command failed: %v\n", err)
		return
	}
	fmt.Printf("output: %s", output)
}

What it printed when we ran it on Go 1.27.1

output: execabs deprecated

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 knowingecosystem

Isolate, tag, delete x/crypto/openpgp

What changed
The proposal to isolate, tag, and delete x/crypto/openpgp was accepted.
Production impact
The source does not say.
Try it
Search your dependencies for golang.org/x/crypto/openpgp and plan to replace it.
Source
github.com/golang/go/issues/81227
Explain it and run it

Understand it, then run it

Run it now

Todaygo
package main

import (
	"fmt"
)

// The golang.org/x/crypto/openpgp package has been removed from the x/crypto
// repository. Attempting to import it now results in a compilation error.
// Existing code must either pin to an older x/crypto version that still
// contains the package or switch to a maintained alternative.

func main() {
	fmt.Println("openpgp package is no longer available in golang.org/x/crypto")
}

What it printed when we ran it on Go 1.27.1

openpgp package is no longer available in golang.org/x/crypto

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 knowingstdlib

Deprecate DNSConfigError in net

What changed
The proposal to deprecate the unused type DNSConfigError was accepted.
Production impact
The source does not say.
Try it
Run go vet to ensure no code references net.DNSConfigError.
Source
github.com/golang/go/issues/63118
Explain it and run it

Understand it, then run it

The Go standard library once defined a type named DNSConfigError in the net package. It was meant to represent a failure while reading the system’s DNS configuration, but the code that could produce it was removed long ago. Because the type is no longer used, the Go team has marked it as deprecated. Deprecation means the type will stay in the source for now so existing programs don’t break, but new code should avoid referring to it and it may disappear in a future release.

If you have never looked at the net package source, you can think of a type as a custom error that a function might return. In this case, no function returns DNSConfigError any more, so you will never see it in practice.

When you read Go documentation, you’ll now see a deprecation note next to DNSConfigError. Treat that as a signal to stop using the name in any new code you write.

Run it now

Todaygo
package main

import (
	"fmt"
	"net"
)

// This program demonstrates that DNSConfigError still exists but is unused.
// In Go 1.27.1 the type is present for compatibility; no function returns it.
func main() {
	// Create a value of the deprecated type manually.
	// This compiles, but real net code will never produce such an error.
	var err net.DNSConfigError
	fmt.Printf("Deprecated type value: %#v\n", err)

	// Show that typical net functions do not return DNSConfigError.
	_, lookupErr := net.LookupHost("example.com")
	if lookupErr != nil {
		// The error is of type *net.DNSError, not DNSConfigError.
		fmt.Printf("Lookup error type: %T\n", lookupErr)
	}
}

What it printed when we ran it on Go 1.27.1

Deprecated type value: net.DNSConfigError{Err:error(nil)}
Lookup error type: *net.DNSError

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 knowingstdlib

Deprecate go/build.ArchChar(..)

What changed
The proposal to mark go/build.ArchChar as deprecated was accepted.
Production impact
The source does not say.
Try it
Compile a program that calls build.ArchChar and observe the deprecation warning.
Source
github.com/golang/go/issues/75129
Explain it and run it

Understand it, then run it

go/build.ArchChar used to return a character that identified the CPU architecture. Since Go 1.5 the function always returns an error, and the proposal accepted in October 2026 marks it as deprecated. New code should not call it because it never gives useful information.

When you write Go programs you normally import go/build to inspect build constraints. The deprecated function is still present in the package, but the compiler will emit a deprecation warning and the function will still return an error.

The change means you can stop worrying about handling a special return value from ArchChar. Just avoid the call entirely and use other ways to detect the architecture, such as runtime.GOARCH.

Run it now

Todaygo
package main

import (
	"fmt"
	"go/build"
)

func main() {
	// ArchChar requires an architecture name argument.
	// Since Go 1.5 it always returns an error, demonstrating the deprecation.
	ch, err := build.ArchChar("amd64")
	if err != nil {
		fmt.Println("ArchChar error:", err)
		return
	}
	fmt.Printf("ArchChar returned: %c\n", ch)
}

What it printed when we ran it on Go 1.27.1

ArchChar error: architecture letter no longer used

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 knowingecosystem

Decouple export data formats used by compiler and x/tools

What changed
The proposal to separate the compiler’s export format from the tools’ export format was accepted; a new cmd/export tool will produce tools‑readable export data, and go list -export will follow the tools format.
Production impact
The source does not say.
Try it
Run go list -export on a package and inspect the generated file; compare it with the output of the new cmd/export tool (available in the development version).
Source
github.com/golang/go/issues/79427
Explain it and run it

Understand it, then run it

Export data is a compact binary file that the Go compiler writes so that tools can understand the types defined in a package. Today the compiler and the x/tools library both read the same export format. The proposal accepted on 2026‑10‑08 separates those formats. A new command, cmd/export, will create export files in the format that tools expect, and go list -export will point to those files instead of the compiler’s object file. The compiler’s own export format will become internal‑only.

Run it now

Todaygo
package main

import (
	"encoding/json"
	"fmt"
	"os/exec"
)

type ListInfo struct {
	Export string `json:"Export"`
}

func main() {
	// Run `go list -json -export` on the standard library package fmt.
	// This demonstrates the current Export field, which points to a compiler‑produced .a file.
	cmd := exec.Command("go", "list", "-json", "-export", "fmt")
	out, err := cmd.Output()
	if err != nil {
		panic(err)
	}
	var info ListInfo
	if err := json.Unmarshal(out, &info); err != nil {
		panic(err)
	}
	fmt.Println("Export file path (current behavior):")
	fmt.Println(info.Export)
}

What it printed when we ran it on Go 1.27.1

Export file path (current behavior):
/opt/gocache/88/88b5e23569a6a57669612c078d181f9d823b92f8c2e63ef69ecc277114529d41-d

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 knowecosystem

Go 1.27.2 point release

What changed
The Go team released go1.27.2 on 2026‑10‑08.
Production impact
The source does not say.
Try it
Run go version on a production host to verify the new version is installed.
Source
github.com/golang/go/releases/tag/go1.27.2
Explain it

Understand it, then run it

Go 1.27.2 was released on 8 Oct 2026 as a point‑release for the Go 1.27 series. A point‑release contains only bug fixes and small adjustments; the language and standard library stay the same as in Go 1.27.1. Because the change list does not describe any new feature, the way you write Go code does not need to change. If you are using Go 1.27.1, you can upgrade to 1.27.2 to get the same language experience with the latest fixes.

Nice to knowecosystem

Go 1.26.9 point release

What changed
The Go team released go1.26.9 on 2026‑10‑08.
Production impact
The source does not say.
Try it
Update your CI pipelines to use go1.26.9 and confirm builds succeed.
Source
github.com/golang/go/releases/tag/go1.26.9
Explain it

Understand it, then run it

Go 1.26.9 is a point release that was published on 8 October 2026. Point releases fix bugs and make small improvements without adding new language features.

If you are using Go 1.26.8 or an earlier 1.26 version, updating to 1.26.9 will give you the latest patches that the Go team has prepared for that series.

The change is simply the availability of the new version; there is no new syntax or library function to learn.

Exercise

Exercise The golang.org/x/sys/execabs package has been deprecated and its functionality is now provided by the standard library’s os/exec. Write a short program that runs the external command go version and prints its output, using only the standard library. (The starter code shows the old import; replace it with the modern approach.)

Startergo
package main

import (
	// Deprecated: use os/exec instead.
	// "golang.org/x/sys/execabs"
	"fmt"
	"os/exec"
)

func main() {
	// TODO: Use os/exec to run the command "go version" and print its output.
	// The starter imports the old package as a comment to remind you what used
	// to be required before the deprecation.
}
Show a solution
Solutiongo
package main

import (
	"fmt"
	"os/exec"
)

func main() {
	// Create the command. os/exec now has the same safety guarantees that
	// execabs provided, so we can use it directly.
	cmd := exec.Command("go", "version")

	// Run the command and capture its combined standard output and error.
	output, err := cmd.CombinedOutput()
	if err != nil {
		// If the command fails, report the error together with any output.
		fmt.Printf("command failed: %v\noutput: %s\n", err, output)
		return
	}

	// Print the successful output.
	fmt.Printf("go version output: %s", output)
}

What it printed when we ran it on Go 1.27.1

go version output: go version go1.27.1 linux/amd64

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.

The 60-second version

In the latest weekly update the Go team published two point releases, go1.27.2 and go1.26.9, on October 8th. At the same time several long‑standing packages were accepted for deprecation and removal. The x/sys/execabs package will receive //go:fix directives, be marked deprecated, and then be isolated, tagged, and deleted after a short grace period. The x/crypto/openpgp module, which has been frozen and flagged as unsafe, will be isolated, tagged, and removed. The net package’s DNSConfigError type, which has not been used for years, is now officially deprecated. The go/build.ArchChar function, a no‑op since Go 1.5, is also deprecated. Finally, a proposal to split the export data format used by the compiler from the one used by tools was accepted; a new cmd/export tool will generate tool‑readable export files, and go list -export will follow that format. These changes mainly affect maintenance and future migration work rather than immediate runtime behavior.

Written by gpt-oss-120b · claims checked against the sources · human-reviewed