tedu

Based on the Go 1.22 release notes from the Go team (3-Clause BSD License), with many interactive examples added. This blog post is synchronized with the source document as it gets updated.

In this write-up, we’ll delve into how, through differential fuzzing, we uncovered a bug in Go’s exp/net HTML’s tokenizer. We’ll show potential XSS implications of this flaw. Additionally, we’ll outline how Google assessed this finding within their VRP program and guide how to engage and employ fuzzing to evaluate your software.

Go 1.21 adds a new port targeting the WASI preview 1 syscall API through the new GOOS value wasip1. This port builds on the existing WebAssembly port introduced in Go 1.11.

WebAssembly (Wasm) is a binary instruction format originally designed for the web. It represents a standard that allows developers to run high-performance, low-level code directly in web browsers at near-native speeds.

Go first added support for compiling to Wasm in the 1.11 release, through the js/wasm port. This allowed Go code compiled using the Go compiler to be executed in web browsers, but it required a JavaScript execution environment.

As the use of Wasm has grown, so have use cases outside of the browser. Many cloud providers are now offering services that allow the user to execute Wasm executables directly, leveraging the new WebAssembly System Interface (WASI) syscall API.

Cgo calls take about 40ns, about the same time encoding/json takes to parse a single digit integer. On my 20 core machine Cgo call performance scales with core count up to about 16 cores, after which some known contention issues slow things down.

The new log/slog package in Go 1.21 brings structured logging to the standard library. Structured logs use key-value pairs so they can be parsed, filtered, searched, and analyzed quickly and reliably. For servers, logging is an important way for developers to observe the detailed behavior of the system, and often the first place they go to debug it. Logs therefore tend to be voluminous, and the ability to search and filter them quickly is essential.

Boring is good. Boring is stable. Boring means being able to focus on your work, not on what’s different about Go. This post is about the important work we shipped in Go 1.21 to keep Go boring.

There will not be a Go 2 that breaks Go 1 programs. Instead, we are going to double down on compatibility, which is far more valuable than any possible break with the past. In fact, we believe that prioritizing compatibility was the most important design decision we made for Go 1.

The Go programming language has released its first Release Candidate (RC) for version 1.21, which is packed with new features, improvements, and performance enhancements. This article provides an overview of the notable changes and features in Go 1.21, along with some exciting additions to the standard library.

• PGO
• min, max functions
• preview of loop capture change
• new slog, slices, and map packages
• WASI port

A few years ago I wrote pygit, a small Python program that’s just enough of a Git client to create a repository, add some commits, and push itself to GitHub.

I wanted to compare what it would look like in Go, to see if it was reasonable to write small scripts in Go – quick ’n’ dirty code where performance isn’t a big deal, and stack traces are all you need for error handling.

The result is gogit, a 400-line Go program that can initialise a repository, commit, and push to GitHub. It’s written in ordinary Go … except for error handling, which is just too verbose in idiomatic Go to work well for scripting (more on that below).

Our current inlining policy remains built on a foundation that is becoming increasingly strained as we add things like PGO, is increasingly anchored in past backend limitations, and it continues to use an overly simplistic cost model driven by an overly simplistic scheduler. Between unified IR and the untapped possibilities of PGO, I believe there’s now a significant opportunity to improve the inlining policy, resulting in significant performance improvements for Go applications, and reducing the effort and expertise needed to write highly efficient Go code.

Go programmers have the good fortune of excellent testing and benchmarking tooling built into the standard library - in the testing package. However, benchmarking is hard. This isn't Go specific; it's just one of those things experienced developers learn over time.

This post lists some common benchmarking pitfalls Go programmers run into. It assumes basic familiarity with writing Go benchmarks; consult the testing package documentation if needed. While these pitfalls are presented in Go, they exist in any programming language or environment, so the lessons learned here are widely applicable.