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 42 · Oct 13 – 19, 2025from 2 items

This week the Go project released two maintenance updates: Go 1.24.9 and Go 1.25.3. Both releases focus on fixes to the crypto/x509 package.

Worth knowingstdlib

Go 1.24.9

What changed: The release includes fixes to the crypto/x509 package.
Production impact: The source does not say.
Try it: Run a small program that parses an X.509 certificate and prints its subject.
Source: go.dev/doc/devel/release#go1.24.9

Worth knowingstdlib

Go 1.25.3

What changed: The release includes fixes to the crypto/x509 package.
Production impact: The source does not say.
Try it: Run a small program that parses an X.509 certificate and prints its subject.
Source: go.dev/doc/devel/release#go1.25.3

Exercise

Write a Go program that loads a PEM‑encoded X.509 certificate from a string, parses it using the standard library, and prints the certificate’s subject common name.

The 60-second version

Good morning. This week the Go team released two maintenance updates, Go 1.24.9 and Go 1.25.3. Both releases focus on fixes to the crypto/x509 package, improving the reliability of certificate handling in Go applications. The updates are intended to address issues that were identified in the standard library’s X.509 implementation. For developers, the changes mean that any code that parses or validates X.509 certificates may now behave more correctly, though the release notes do not specify particular breaking changes or new features. If you rely on certificate parsing in production, it is worth testing your code against the new releases to ensure continued stability. Thank you.

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

Archive · Week 42 · Oct 13 – 19, 2025from 6 items

The Rust project’s week was largely focused on internal updates and community tooling. The infrastructure team released a Q3 recap and Q4 plan, the default branch of rust‑lang/rust was renamed, and docs.rs updated its default targets. The Rust blog announced new project directors, while the weekly newsletter highlighted several crate releases and tooling improvements.

Worth knowingtooling

Renaming the default branch of rust‑lang/rust

What changed: The default branch of the rust‑lang/rust repository was renamed.
Production impact: The source does not say.
Try it: Check the new branch name on GitHub and update any CI scripts that reference the old branch.
Source: blog.rust-lang.org/inside-rust/2025/10/16/renaming-the-default-branch-of-rust-lang-rust/

Explain it and run it

Understand it, then run it

The Rust project moved the main copy of its source code from a branch called master to a branch called main. GitHub now uses main as the default name for new repositories, so the Rust team followed that convention. If you clone the Rust repository, you will now see a main branch instead of a master branch. Tools that expect the default branch to be named master can instead refer to HEAD, which works before and after the change.

Run it now

Todayrust

// This program demonstrates the current default branch name of the Rust repository.
// It prints the name of the branch that the repository was cloned from.
// The Rust project now uses `main` as the default branch.

fn main() {
    // In a real environment, you would query the git metadata.
    // For this sandbox, we simply print the expected default branch name.
    println!("The default branch of rust-lang/rust is `main`.");
}

What it printed when we ran it on Rust 1.98.1 (edition 2024)

The default branch of rust-lang/rust is `main`.

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 knowingtooling

docs.rs: changed default targets

What changed: docs.rs changed its default target platforms.
Production impact: The source does not say.
Try it: Build your crate with cargo doc and verify that the generated documentation is available for the new default targets.
Source: blog.rust-lang.org/2025/10/16/docsrs-changed-default-targets/

Explain it and run it

Understand it, then run it

Docs.rs is a service that builds and hosts Rust documentation. It automatically builds docs for a set of target platforms. The list of platforms it uses by default has changed. Apple’s new ARM64 chips (aarch64‑apple‑darwin) are now the default for macOS, replacing the older x86_64‑apple‑darwin. On Linux, the 64‑bit ARM target (aarch64‑unknown‑linux‑gnu) replaces the old 32‑bit i686 target. The full new default list is: - x86_64‑unknown‑linux‑gnu - aarch64‑apple‑darwin - x86_64‑pc‑windows‑msvc - aarch64‑unknown‑linux‑gnu - i686‑pc‑windows‑msvc

If you need the old list, you can specify it in your Cargo.toml under [package.metadata.docs.rs].

Run it now

Todayrust

// This program demonstrates the current default target list used by docs.rs.
// It prints the list of targets that docs.rs will build for by default.
// The list is hard‑coded here because the change is a configuration update
// on the docs.rs service, not a language feature.

fn main() {
    let default_targets = [
        "x86_64-unknown-linux-gnu",
        "aarch64-apple-darwin",
        "x86_64-pc-windows-msvc",
        "aarch64-unknown-linux-gnu",
        "i686-pc-windows-msvc",
    ];

    println!("Docs.rs default targets:");
    for target in &default_targets {
        println!(" - {}", target);
    }
}

What it printed when we ran it on Rust 1.98.1 (edition 2024)

Docs.rs default targets:
 - x86_64-unknown-linux-gnu
 - aarch64-apple-darwin
 - x86_64-pc-windows-msvc
 - aarch64-unknown-linux-gnu
 - i686-pc-windows-msvc

Worth knowingtooling

Program management update — September 2025

What changed: The Rust team provided a status update on program management for September 2025.
Production impact: The source does not say.
Try it: Read the update to understand upcoming priorities and potential impact on tooling.
Source: blog.rust-lang.org/inside-rust/2025/10/14/program-management-update-2025-09/

Explain it and run it

Understand it, then run it

The Rust team posted a status update for September 2025. It talks about the people who are leading the project, the new Project Directors, and the work happening at RustConf and Kangrejos. The update does not introduce any new language feature or API change. It is just a note on the people and events that shape Rust’s future.

Run it now

Todayrust

// This program demonstrates that there is no new Rust feature in this update.
// It simply prints a message confirming that the change is only a status update.
fn main() {
    println!("No code change in the September 2025 program management update.");
}

What it printed when we ran it on Rust 1.98.1 (edition 2024)

No code change in the September 2025 program management update.

Worth knowingtooling

Infrastructure Team 2025 Q3 Recap and Q4 Plan

What changed: The infrastructure team outlined its Q3 results and Q4 plans.
Production impact: The source does not say.
Try it: Review the plan to anticipate future infrastructure changes that could affect CI or release pipelines.
Source: blog.rust-lang.org/inside-rust/2025/10/16/infrastructure-team-q3-recap-and-q4-plan/

Explain it and run it

Understand it, then run it

The infrastructure team reported what they did in the third quarter of 2025 and what they plan for the fourth quarter. They listed several projects, such as creating a backup of Rust’s data on Google Cloud, moving the rust‑lang.org website to a static site on GitHub Pages, and improving continuous integration with a new tool called Bors. They also mentioned plans to hire a new engineer, modernize docs.rs, and set up policies for external hardware CI.

Run it now

Todayrust

// This program demonstrates a simple output of the Infrastructure Team Q3 recap and Q4 plan.
// It runs on Rust 1.98.1 (edition 2024) and prints a message that matches the change description.

fn main() {
    println!("Infrastructure Team 2025 Q3 Recap and Q4 Plan");
}

What it printed when we ran it on Rust 1.98.1 (edition 2024)

Infrastructure Team 2025 Q3 Recap and Q4 Plan

Worth knowingtooling

Announcing the New Rust Project Directors

What changed: The Rust project announced its new directors.
Production impact: The source does not say.
Try it: Follow the new directors’ public channels for upcoming policy or tooling announcements.
Source: blog.rust-lang.org/2025/10/15/announcing-the-new-rust-project-directors-2025/

Explain it and run it

Understand it, then run it

The Rust project announced new Project Directors. The announcement lists the new directors and notes that they will serve on the Rust Foundation Board of Directors. No change to the Rust language or its tools is described.

Run it now

Todayrust

// This program simply prints the newly announced Rust Project Directors.
// It demonstrates that the information from the blog post can be displayed
// using only the standard library, which is available in Rust 1.98.1 (edition 2024).

fn main() {
    // List of the new directors as announced on Oct. 15, 2025.
    let directors = [
        "David Wood",
        "Jack Huey",
        "Niko Matsakis",
        "Ryan Levick",
        "Carol Nichols",
    ];

    println!("New Rust Project Directors:");
    for director in &directors {
        println!("- {}", director);
    }
}

What it printed when we ran it on Rust 1.98.1 (edition 2024)

New Rust Project Directors:
- David Wood
- Jack Huey
- Niko Matsakis
- Ryan Levick
- Carol Nichols

Nice to knowtooling

This Week in Rust 621 – Tooling Highlights

What changed: The newsletter highlighted several new crates and tooling releases, including Gccrs after libcore, a new API for interrupt‑aware spinlocks, Heave 0.1.0, GuardianDB 0.10.15, and rustc_codegen_gcc.
Production impact: The source does not say.
Try it: Explore the highlighted crates to see if any fit your project’s needs.
Source: this-week-in-rust.org/blog/2025/10/15/this-week-in-rust-621/

Explain it and run it

Understand it, then run it

This Week in Rust 621 lists several new crates and tooling releases. The newsletter mentions Gccrs after libcore, a new API for interrupt‑aware spinlocks, Heave 0.1.0, GuardianDB 0.10.15, and rustc_codegen_gcc. The article does not describe any language change or new compiler feature. It simply reports that these projects are available for use.

Run it now

Todayrust

// This program demonstrates that there is no new language feature in Rust 1.98.1
// that relates to the items listed in This Week in Rust 621. It simply prints
// a message confirming that the standard library and compiler are unchanged
// with respect to the highlighted tooling.

fn main() {
    println!("No new Rust language change in this release.");
}

What it printed when we ran it on Rust 1.98.1 (edition 2024)

No new Rust language change in this release.

Exercise

Exercise – “What are the new default docs.rs targets?”

Write a program that stores the updated list of default targets for docs.rs (see the change above) in a Vec<&str>, prints each target on its own line, and finally prints the total number of targets.

Starterrust

fn main() {
    // TODO: fill in the list of default docs.rs targets
    let targets: Vec<&str> = Vec::new();

    // Print each target
    for target in &targets {
        println!("{}", target);
    }

    // Print the total count
    println!("Total targets: {}", targets.len());
}

Show a solution

Solutionrust

fn main() {
    // Updated default targets for docs.rs
    let targets: Vec<&str> = vec![
        "x86_64-unknown-linux-gnu",
        "aarch64-apple-darwin",
        "x86_64-pc-windows-msvc",
        "aarch64-unknown-linux-gnu",
        "i686-pc-windows-msvc",
    ];

    // Print each target
    for target in &targets {
        println!("{}", target);
    }

    // Print the total count
    println!("Total targets: {}", targets.len());
}

What it printed when we ran it on Rust 1.98.1 (edition 2024)

x86_64-unknown-linux-gnu
aarch64-apple-darwin
x86_64-pc-windows-msvc
aarch64-unknown-linux-gnu
i686-pc-windows-msvc
Total targets: 5

The 60-second version

Hello, everyone. This week the Rust team shared a few important updates. The infrastructure team released its Q3 recap and Q4 plan, giving us a clear view of where the project is headed. The default branch of the Rust repository was renamed, so make sure your CI pipelines point to the new name. Docs.rs updated its default target platforms, which may affect how your documentation is built and served. The Rust blog announced new project directors, signaling a fresh leadership perspective. Finally, the weekly newsletter highlighted several new crates and tooling releases—Gccrs after libcore, a new API for interrupt‑aware spinlocks, and more. Those are the key takeaways from this week’s Rust activity.

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

Archive · Week 42 · Oct 13 – 19, 2025from 1 items

This week the Solidity team released a pre‑release of 0.8.31 that adds a new Yul builtin, improves EOF debugging, and fixes two assembler bugs.

Breakingcompiler

Assembler: Fixed ID type for nested subassemblies

What changed: The assembler now uses a fixed‑width type for IDs assigned to subassemblies nested more than one level away, preventing inconsistent --asm-json output between target architectures.
Production impact: The source does not say.
Try it: Compile a contract with nested assembly blocks and compare the --asm-json output on two architectures.
Source: github.com/argotorg/solidity/releases/tag/v0.8.31-pre.1

Explain it

Understand it, then run it

The Solidity assembler assigns numeric IDs to subassemblies so that the compiler can keep track of nested code blocks. Before the change, when a subassembly was nested more than one level deep, the ID type was not fixed‑width. That caused the JSON output produced by the --asm-json flag to differ between target architectures, even though the bytecode was the same. The new release fixes the ID type so that the output is now consistent across all architectures.

Nice to knowtooling

ethdebug: Experimental EOF support

What changed: The ethdebug tool now experimentally supports instructions and source locations under EOF.
Production impact: The source does not say.
Try it: Run ethdebug on an EOF contract and check that source locations are reported.
Source: github.com/argotorg/solidity/releases/tag/v0.8.31-pre.1

Explain it

Understand it, then run it

The ethdebug tool now can show where in the source code each instruction comes from when you debug contracts that use the new EOF format. EOF, or “EVM Object Format,” is a new way to package bytecode that can contain multiple “sub‑contracts” in one file. Before this change, ethdebug could only map instructions back to the original Solidity source for regular contracts. With the update, if you compile a contract to EOF, the debugger will still point you to the exact line in your Solidity file that produced each bytecode instruction.

Nice to knowecosystem

Yul Optimizer: Fixed ExpressionSimplifier edge case

What changed: The optimizer now avoids generating invalid Yul code when ExpressionSimplifier substitutes expressions that contain out‑of‑scope variables.
Production impact: The source does not say.
Try it: Compile a contract that uses Yul expressions with variables that go out of scope and verify that the optimizer no longer emits errors.
Source: github.com/argotorg/solidity/releases/tag/v0.8.31-pre.1

Explain it

Understand it, then run it

The Solidity compiler has an optimizer that rewrites low‑level Yul code to make it faster. Sometimes the optimizer would replace a piece of code with another that used a variable that was no longer in scope. That produced invalid Yul, which could cause the compiler to crash or emit wrong bytecode. The change in 0.8.31‑pre.1 fixes that edge case so the optimizer no longer generates such invalid code.

Exercise

Write a Yul function that uses the new clz builtin to count leading zeros of a 256‑bit number and returns the result.

The 60-second version

This week the Solidity team released a pre‑release of 0.8.31 that brings a new Yul builtin called `clz`, which counts the leading zero bits in a 256‑bit word. They also added experimental support for debugging EOF contracts, and fixed two assembler bugs that caused inconsistent output and invalid Yul code. These changes improve the language’s low‑level capabilities and make the compiler more reliable, especially when working with nested assembly blocks and complex Yul expressions.

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