What changed in Go, Rust and Solidity this week.

The regexp package in Go can match Unicode characters using the \p{…} syntax. Before this change, it only understood the short two‑letter codes like \p{L} for letters. It did not recognize longer names such as \p{Letter} or the special groups \p{Any}, \p{Assigned}, and \p{ASCII}. The new change adds support for those longer names and for the pseudo‑categories. It also makes the names case‑insensitive, so \p{ascii} works the same as \p{ASCII}. With this update, patterns that use the full Unicode names will work correctly, making the package more aligned with the Unicode standard and easier to use in real‑world text processing.

The Unicode package in Go keeps tables that describe what each character is. A long time ago the tables did not include a small map that tells the package which short names mean which long names. For example, the short name L means “Letter”, but the long name Letter was not linked. The change adds a map called CategoryAliases that maps names like Letter to the short form L. It also adds two new tables, LC for “Cased Letter” and Cn for “Unassigned”, so that the package can refer to them directly.

The runtime.AddCleanup function lets a program register a function that will run when the program exits. Until recently the documentation said that all cleanup functions run in a single goroutine, one after another. The change removes that wording and says that cleanups now run concurrently with each other and with user goroutines. This means a long‑running cleanup will no longer block other cleanups or the rest of the program.

The go command can take *package patterns* to tell it which packages to build, test, or install. Existing patterns include all, std, cmd, and tool. A new pattern called work was added to match every package that belongs to the current work (or workspace) modules. This lets you run a single command to build or test all of those packages, instead of having to list each one or use a long relative path pattern.

Rust 1.85.0 was released on February 20, 2025. The announcement also mentions the upcoming Rust 2024 release. No new language features or library changes were introduced in this release, so the core language and standard library remain the same as in Rust 1.84.0.

Rustup 1.28.0 stops automatically installing the active toolchain when it is missing. Before, running any rustup command would silently pull the current toolchain. Now you must explicitly run rustup toolchain install to get it. The change is a small command‑line tweak that affects how you set up a new machine.

The blog post is an update from the Rust Foundation Project Directors. It reports on the results of the January 2025 Board meeting, including the election of a new Chair and the start of discussions about a Long‑Term Support version of Rust. It also mentions work to make continuous integration cheaper by moving to free GitHub Actions runners.

Solidity lets you write custom error types to make revert messages cheaper and clearer. When you call require with a custom error and use named parameters, the compiler used to put the arguments on the stack in the order you wrote them. In 0.8.37 the compiler now puts them on the stack in the order the error type declares them, regardless of the order you write them. This means the runtime data that represents the error is always in declaration order, which is what the ABI expects.

Mutual recursion is when two or more functions call each other. When a function is compiled, the compiler puts temporary values in memory slots. If two recursive functions are active at the same time, the compiler had to give them different slots. Before Solidity 0.8.37 the slot‑allocation logic could give the same slot to two active functions, so one function would overwrite the other’s data. The new release fixes that logic so each active function gets its own slot and the data stays intact.

Solidity 0.8.37 fixes a bug that affected the delete keyword when used on a single byte inside a bytes array that lives in memory. Before the fix, deleting a byte would clear the whole 32‑byte word that contains that byte, wiping out the other 31 bytes in the same word. Now the compiler generates code that only zeroes the targeted byte, leaving the rest of the word untouched. This change is invisible to most contracts that never delete individual bytes, but it matters for low‑level code that manipulates memory arrays byte‑by‑byte.