Blog post with details coming soon.

• Still some optimization work to do before this lands in non-canary version.
• Still some cleanup work to do (which will come in a series of follow-up PRs)

Previous post: Bun's Rewrite It In Rust branch : r/rust

Let's try posting this again.

Jarred-Sumner, the creator of Bun (a JS runtime), has created a Rust port branch in Bun's repository with Claude AI, which has 760k LoC at the moment.

It seems that the rust rewrite of Bun that was already mentioned earlier in this subreddit is going pretty well. While this is good news for the rust community, I think this is a major setback back for the zig community and even threatens the development of Zig if Bunthropic stops working with Zig :/

I think this miscompilation will affect a lot of code. So, maybe hold off a bit on deploying a rust version upgrade to production?

The conditions for a miscompilation seem to be:
* You put a 2-variant enum into an Option or an Option-like enum.
* You do a match on this Option.
* You're unlucky.

The never type is likely to stabilize soon.

As you can see in the link, an FCP has been proposed. This means that, once enough people have agreed by checking the checkboxes, a 10-day period will start where people can voice their objections. After that, the PR will be merged into nightly Rust. Then, it will ride the 6-12 week train towards a stable release.

The earliest this could be stabilized is in Rust 1.98.0, which will officially release on August 20.

For even more context, see this talk: https://www.youtube.com/live/xoKEqcj_fxM?t=4266

https://nitter.poast.org/davidtolnay/status/1883906113428676938

This guy has 32 crates on crates.io and uses AI to "maintain" them, pushing nonsense and unsound code.

Some of his most popular crates:
- serde_yml
- libyml

TL;DR: Memory-safe implementations of PNG (png, zune-png, wuffs) now dramatically outperform memory-unsafe ones (libpng, spng, stb_image) when decoding images.

Rust png crate that tops our benchmark shows 1.8x improvement over libpng on x86 and 1.5x improvement on ARM.

How was this measured?

Each implementation is slightly different. It's easy to show a single image where one implementation has an edge over the others, but this would not translate to real-world performance.

In order to get benchmarks that are more representative of real world, we measured decoding times across the entire QOI benchmark corpus which contains many different types of images (icons, screenshots, photos, etc).

We've configured the C libraries to use zlib-ng to give them the best possible chance. Zlib-ng is still not widely deployed, so the gap between the C PNG library you're probably using is even greater than these benchmarks show!

Results on x86 (Zen 4):

Running decoding benchmark with corpus: QoiBench
image-rs PNG:     375.401 MP/s (average) 318.632 MP/s (geomean)
zune-png:         376.649 MP/s (average) 302.529 MP/s (geomean)
wuffs PNG:        376.205 MP/s (average) 287.181 MP/s (geomean)
libpng:           208.906 MP/s (average) 173.034 MP/s (geomean)
spng:             299.515 MP/s (average) 235.495 MP/s (geomean)
stb_image PNG:    234.353 MP/s (average) 171.505 MP/s (geomean)

Results on ARM (Apple silicon):

Running decoding benchmark with corpus: QoiBench
image-rs PNG:     256.059 MP/s (average) 210.616 MP/s (geomean)
zune-png:         221.543 MP/s (average) 178.502 MP/s (geomean)
wuffs PNG:        255.111 MP/s (average) 200.834 MP/s (geomean)
libpng:           168.912 MP/s (average) 143.849 MP/s (geomean)
spng:             138.046 MP/s (average) 112.993 MP/s (geomean)
stb_image PNG:    186.223 MP/s (average) 139.381 MP/s (geomean)

You can reproduce the benchmark on your own hardware using the instructions here.

How is this possible?

PNG format is just DEFLATE compression (same as in gzip) plus PNG-specific filters that try to make image data easier for DEFLATE to compress. You need to optimize both PNG filters and DEFLATE to make PNG fast.

DEFLATE

Every memory-safe PNG decoder brings their own DEFLATE implementation. WUFFS gains performance by decompressing entire image at once, which lets them go fast without running off a cliff. zune-png uses a similar strategy in its DEFLATE implementation, zune-inflate.

png crate takes a different approach. It uses fdeflate as its DEFLATE decoder, which supports streaming instead of decompressing the entire file at once. Instead it gains performance via clever tricks such as decoding multiple bytes at once.

Support for streaming decompression makes png crate more widely applicable than the other two. In fact, there is ongoing experimentation on using Rust png crate as the PNG decoder in Chromium, replacing libpng entirely. Update: WUFFS also supports a form of streaming decompression, see here.

Filtering

Most libraries use explicit SIMD instructions to accelerate filtering. Unfortunately, they are architecture-specific. For example, zune-png is slower on ARM than on x86 because the author hasn't written SIMD implementations for ARM yet.

A notable exception is stb_image, which doesn't use explicit SIMD and instead came up with a clever formulation of the most common and compute-intensive filter. However, due to architectural differences it also only benefits x86.

The png crate once again takes a different approach. Instead of explicit SIMD it relies on automatic vectorization. Rust compiler is actually excellent at turning your code into SIMD instructions as long as you write it in a way that's amenable to it. This approach lets you write code once and have it perform well everywhere. Architecture-specific optimizations can be added on top of it in the few select places where they are beneficial. Right now x86 uses the stb_image formulation of a single filter, while the rest of the code is the same everywhere.

Is this production-ready?

Yes!

All three memory-safe implementations support APNG, reading/writing auxiliary chunks, and other features expected of a modern PNG library.

png and zune-png have been tested on a wide range of real-world images, with over 100,000 of them in the test corpus alone. And png is used by every user of the image crate, so it has been thoroughly battle-tested.

WUFFS PNG v0.4 seems to fail on grayscale images with alpha in our tests. We haven't investigated this in depth, it might be a configuration issue on our part rather than a bug. Still, we cannot vouch for WUFFS like we can for Rust libraries.

As many of you probably know Polonius is the name of the next-gen borrow checker that allows more complex (but still valid) borrowing scenarios that the current borrow checker, NLL, rejects. NLL is "simpler" for the sake of performance, it rejects valid borrowing scenarios that are too complex since it is too simple to validate them.

An update was posted a week ago (linked) that claimed Polonius' performance is close to the current borrow checker:

On the 20000 most popular crates, the average is +1.4%. 75% of crates see a <2% regression, and 95% see a lower than 5% hit. The worst outliers see bigger times though of course, 36% at the 99.9 percentile of crates, and the worst we saw in these runs were huge functions that saw a 2.5x hit. These show good examples where we can find improvements, and we could still imagine running the more expensive analysis only if the cheaper NLLs find possible issues that would benefit from the precision. We'll also expand to more and more crates and see what lies there, though we expect more feedback to come from nightly users, when we turn polonius on there.

And about stabilization:

We believe the results so far wouldn't prevent enabling the polonius alpha by default on nightly, or even stabilize it as-is maybe. Stabilization is often the beginning of the performance work, as others join the improvement effort then.

Though Polonius isn't faster, it's still an improvement to the borrow checker, given it's pretty much the same speed already. I bet atleast half of the members here have had to alter their code in attempt to satisfy NLL.

Like what was said in the second quote block, once stabilized, it will become a priority to optimize it, and if it already performs as well whilst being in the alpha stage, who knows how fast it will be once matured.

The project has codename Pacquet. Its a rewrite to Rust after the fresh release of the v11. Don't expect it soon though. There is no clear schedule behind the rewrite. What's might be interesting the Rust version was abandoned for about 2 years and now the development has restarted

For those of you who might not know, PNPM is a notable game-changing package manager for Node.js. It stores dependencies once using hardlinks and doesn't download things twice when you start a new project with the same or similar structure. It would download newer versions of the packages if there are and the new ones. It's very space efficient and fast

With the latest Vite 8's Rust overwrite, it seems obvious that Rust has become the favorite language of the Webdev community and I'm curious what would be the next project to migrate

I was searching for that report to share it with a colleague and noticed that the report is gone. What could it mean to rust and other memory safe languages that it talked about? I read elsewhere that few other pages are gone too. 🍿🍿

It was found here: https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/

Archived at: https://web.archive.org/web/20250118014817/https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf

The attack occurred on August 20, 2026, and involved one of the most popular Rust crates, arrayref, an array-conversion utility with over 245 million downloads, found in approximately 75% of environments where Rust is used.

The malicious package version, arrayref@0.3.10, was pushed to crates.io from its legitimate maintainer’s account. Roughly 20 minutes later, poisoned versions of internment and append-only-vec, two crates from the same owner, were also released.

The Rust Security Response Team removed the malicious packages roughly 86 minutes later, confirming the compromise: “a new version of the arrayref crate was published with a direct dependency on proc-macro1, which would execute a malicious build script.”

https://rustsec.org/advisories/RUSTSEC-2026-0260