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.

High pressure, high forces, long lever arms...all of that meant heavy and strong (read: expensive) parts which I was not looking forward to having to fabricate. Instead, I settled on the simpler idea of harnessing the power of compressed gas. Instead of using a high mechanical advantage lever to push a piston, compressed CO2 would be dispensed from a small and inexpensive 12g or 16g cartridge which would then generate the requisite pressure to properly extract espresso. This concept is not actually novel; both an unsuccessful kickstarter and a now-defunct handheld espresso maker (with a fanatical user base) employed this mechanism.

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.

Espresso coffee is among the most consumed beverages in the world. Recent studies report a protective activity of the coffee beverage against neurodegenerative disorders such as Alzheimer′s disease. Alzheimer′s disease belongs to a group of disorders, called tauopathies, which are characterized by the intraneuronal accumulation of the microtubule-associated protein tau in fibrillar aggregates. In this work, we characterized by NMR the molecular composition of the espresso coffee extract and identified its main components. We then demonstrated with in vitro and in cell experiments that the whole coffee extract, caffeine, and genistein have biological properties in preventing aggregation, condensation, and seeding activity of the repeat region of tau. We also identified a set of coffee compounds capable of binding to preformed tau fibrils. These results add insights into the neuroprotective potential of espresso coffee and suggest candidate molecular scaffolds for designing therapies targeting monomeric or fibrillized forms of tau.

In vitro results, take with a grain of salt or shot of espresso.

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).

Yael Tauman Kalai’s breakthroughs secure the digital world, from cloud computing to our quantum future.

My master’s thesis was titled “How to Leak a Secret.” Here’s the problem: We know how to digitally sign — to say, “This is me that wrote this message.” But say I want to sign something as an MIT professor, but I don’t want people to know it’s me? That way the secret does hold some water because you know an MIT professor signed it, but you don’t know who.

We solved this with something we called ring signatures, which were inspired by a notion in computer science called witness-indistinguishable proofs. Let’s say there’s a statement and two different ways to prove it. We say there’s two “witnesses” to the statement being correct — each of the proofs. A witness-indistinguishable proof looks the same no matter which you use: It hides which witness you started with.

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.