This was a fortnight of the Rust project looking both confident and exposed at once. Rust 1.98 shipped, and the next-generation trait solver reached nightly after nearly four years, the two clearest signs yet of a maturing compiler. Then a popular crate was briefly hijacked in a North Korea-linked supply-chain attack, a reminder that the price of an ecosystem this widely used is a much larger attack surface.

Rust 1.98 Lands: Algebraic Floats and Buffered Integer Formatting

Rust 1.98.0 is out, and two performance-minded stabilizations lead the release.

The first is algebraic floating-point methods. f32 and f64 gain algebraic_add, algebraic_sub, algebraic_mul, algebraic_div, and algebraic_rem, which let the compiler reorder and vectorize float math using the algebraic properties of real numbers. You trade strict IEEE evaluation order for speed, but only where you opt in, so the default numerics stay predictable. The second is buffered integer formatting: every primitive integer type gets format_into(&mut NumBuffer<Self>), which bypasses most of the dynamic dispatch in the usual formatting path and reaches roughly the speed of the itoa crate for hot loops.

Around those sit a steady round of API polish: UTF-16 string constructors (from_utf16le, from_utf16be, and lossy variants), substr_range, subslice_range and strip_circumfix, more Atomic<T> mutable-slice helpers, and NonZero::from_str_radix. The release also formalizes that moving a ManuallyDrop<Box<_>> after dropping it is not undefined behavior.

Takeaways:

• Algebraic float methods are an opt-in path to vectorization when you can accept relaxed evaluation order
• format_into with NumBuffer gives allocation-free, near-itoa integer formatting in the standard library
• No headline language feature this cycle, just solid performance and API groundwork

An 86-Minute Supply-Chain Attack Hits arrayref

The most important story of the fortnight is a security one. On 2026-08-20 the popular arrayref crate was republished as 0.3.10 and quietly made to depend on proc-macro1, a typosquat of the real proc-macros, whose build script downloaded a malicious payload. The compromised version was live from 07:15 to 08:41 UTC, about 86 minutes. Two more crates, internment 0.8.7 and append-only-vec 0.1.9, were hit the same way, live for 90 and 107 minutes.

The Rust Security Response Team deleted the malicious versions, unyanked the legitimate ones, removed five further typosquats, and locked the affected account. They judged the maintainer was likely not malicious, but that their machine or credentials had been compromised. SecurityWeek reports the campaign is linked to North Korean threat actors, part of a broader pattern of state-backed groups targeting open-source registries.

The uncomfortable lesson is familiar: build scripts and transitive dependencies remain the soft underbelly, and a typosquatted dependency one level down is easy to miss in a review.

Takeaways:

• The vector was a malicious build script pulled in through a typosquatted transitive dependency, not the crate's own code
• A fast takedown, 86 minutes, sharply limited the blast radius, which is the argument for a well-staffed security response team
• Pin with a lockfile and run cargo audit or cargo vet; the incident is a strong case for vendoring tiny dependencies rather than pulling them

The Next-Generation Trait Solver Reaches Nightly

After nearly four years of work, the next-generation trait solver is opt-in on nightly, described by the team as the largest single change to the compiler since its first release. It is a full rewrite of how rustc proves where-clauses, normalizes associated types, and resolves traits.

The payoff is concrete. The new solver closes more than 200 known issues, improves impl Trait handling for both return-position and type-alias forms, and fixes higher-ranked for<'a> associated types. It also removes unsound inference behaviors that had quietly affected widely used crates like Bevy and MiniJinja. On performance, testing across the top 20,000 crates shows most compiling at comparable speed, with trait-heavy projects seeing real gains: DataFusion compiles roughly 8 times faster.

Strategically it matters because it unblocks long-stalled features, Type Alias Impl Trait and Return Type Notation among them. From 2026-08-22 you can try it with -Znext-solver=globally, and fall back to -Znext-solver=coherence if something breaks.

Takeaways:

• The biggest compiler change in Rust's history is now testable on nightly, and the team wants real-world bug reports
• It fixes soundness holes and 200-plus issues, and unblocks TAIT and Return Type Notation
• Performance is mixed but trending well, with standout wins for trait-heavy crates

Rust Glancer: A Language Server Built for Small Memory

rust-analyzer is powerful and famously hungry with RAM. Rust Glancer, from developer @popzxc (seven years of professional Rust, past contributions to rustc, clippy, and rust-analyzer), is an alternative LSP built around a different tradeoff.

Instead of always-incremental analysis, Glancer uses a "frozen analysis" model: it indexes the workspace once, persists the results to the filesystem, then loads only what a given query needs. That pushes state to disk, survives editor restarts, and sidesteps the memory fragmentation that comes with keeping everything live in RAM. The project targets under 100 MB for typical workspaces and reports indexing times comparable to rust-analyzer on modern hardware, while doing noticeably better on constrained machines like an 8 GB M1 MacBook.

It already supports full indexing, type inference, and trait solving, plus goto-definition, hover, inlay hints, and completions, and ships a VS Code extension. The author is candid that it is incomplete and still has bugs, but "already pretty capable" looks fair.

Takeaways:

• Frozen, disk-backed analysis is a genuinely different point in the design space from rust-analyzer's incremental model
• The sub-100 MB target makes it interesting for low-RAM laptops and remote dev boxes
• Early and buggy, but a serious effort from someone who has worked on the incumbent

Snippets

• TIL: print!(…) is not the same as write!(stdout(), …).unwrap() A sharp reminder that print! locks stdout and handles line buffering and errors differently from writing to io::stdout() directly, and the two diverge once you start redirecting IO.

• It's okay to copy-paste code from crates instead of depending on them An argument for the decades-old practice of vendoring a small function by copying it, with attribution, rather than taking on a dependency. This fortnight's arrayref incident makes the case louder.

• Arc<Mutex<T>> vs channels A well-worn but genuinely useful r/rust thread on when shared-state Arc<Mutex<T>> is the right tool and when message-passing channels are, with good answers for people past the basics.

• Rust Function Overloading: Call for Experimentation As part of the Rust Foundation's Rust-C++ Interop Initiative, the project opens an experiment on function overloading, a step toward smoother interop with C++ codebases.

• Reducing target directory size on nightly The Cargo team is rolling out an opt-in nightly experiment to shrink the notoriously large target/ directory and measure the real-world impact before proposing a default change.

• A Rust compiler that runs entirely through GitHub A gloriously cursed side project called Thermite that compiles Rust using GitHub's own infrastructure, built mostly because the author wanted to see if it could be done.

We are thrilled to have you as part of our growing community of Rust enthusiasts! If you found value in this newsletter, don't keep it to yourself — share it with your network and let's grow the Rust community together.

👉 Take Action Now:

• Share: Forward this email to share this newsletter with your colleagues and friends.

• Engage: Have thoughts or questions? Reply to this email.

• Subscribe: Not a subscriber yet? Click here to never miss an update from Rust Trends.
  
  

Cheers,
Bob Peters

Want to sponsor Rust Trends? We reach thousands of Rust developers biweekly. Get in touch!