While mindlessly browsing the github tabs of one of my library crates I looked at the dependency graph, and went to the Dependents tab. There I expected to just see a list of my other crates (they're all connected in one project), as it had been every time before, but my attention went instantly to 100% when I saw another GitHub profile picture. Someone else was actually using my code!

I quickly clicked the repo, got confused, thought they had added the dependency as a mistake, since I initially didn't see how my crate could possibly be useful to that app. So I went to browsing the implementation and no, it was a real use case I'd have never predicted.

I can't describe how unreasonably happy I was for the rest of that day.

Some time ago I shared mbrotli here. This is its sibling for Zstandard.

There are already two main ways to do zstd in Rust, so here's why I wrote a third.

The zstd crate is bindings to C libzstd. It's fast and battle-tested, but it brings a C toolchain into your build, unsafe FFI into your dependency tree, and some pain once you target wasm or embedded.

ruzstd is pure Rust and has a solid decoder, but its own README says the encoder doesn't reach C speed, ratio or configurability yet. You get a few presets that roughly map to levels 1, 3, 7 and 11.

I wanted something in between: pure Rust, but fast and complete enough that I'd actually ship it in production instead of the C library. And I wanted it to have the same API as mbrotli, so switching between Brotli and zstd in the same codebase is mostly a type rename.

What came out of it:

• Speed. The encoder is a port of the reference implementation, so you get the full level range from -131072 to 22, long distance matching, dictionaries and the same compression ratio as C. SIMD is picked at runtime (via fearless_simd), so one binary uses whatever the CPU supports without target-cpu=native. Against C zstd 1.5.7 the median is about 1.1x for compression and 1.02x for decompression on my benchmarks. It's not faster everywhere: fast levels on plain text are 6-11% behind, and decoding very compressible text can be up to ~20% behind. Full tables and raw CSVs are in the repo.
• API. Besides the usual one-shot compress / decompress, there are Read/Write adapters and incremental sessions. A session just takes input and an output buffer and tells you how far it got. It doesn't own any I/O, so you can drive it from blocking code, from async, from an embedded main loop or from wasm. It can be build on no_std + alloc.
• Parallel compression. One frame can be split into tasks that you run on your own executor: scoped threads, rayon, tokio's blocking pool, whatever you already have. The crate never spawns threads by itself. That was important for me because I use these crates inside nginx, where compression runs in nginx's own thread pool.
• Verification. No unsafe in the crate. Differential tests compare against C zstd across every level and thousands of random parameter combinations. AFL++ fuzz targets cover the encoder, the decoder and streaming sessions. mzstd already works on a few production services as nginx module with a great results for total throughput.

​

use mzstd::{Compressor, Decompressor, EncoderConfig, Level};

let mut encoder = Compressor::new(EncoderConfig::default().with_level(Level::try_from(19)?))?;
let compressed = encoder.compress(b"hello, hello, hello")?;
let restored = Decompressor::default().decompress(&compressed)?;

If you've used mbrotli, swap Quality for Level and that's it.

Not supported yet: legacy v0.x frames, magicless frames, a couple of niche advanced parameters.

I'd love feedback on the API, and benchmark runs on other machines (mine are on an i7-13700KF under WSL2, so bare-metal numbers are very welcome).

• crates.io: https://crates.io/crates/mzstd
• docs: https://docs.rs/mzstd
• repo: https://github.com/M-Compressors/mzstd

There's something really satisfying about finding out that someone is using a library you built, especially when you originally made it just to solve a problem in your own project.

Writing code that works on your machine is one thing, but having another developer find your crate useful enough to include in their project is a different kind of achievement.

It's also a good reminder that open source contributions don't have to be massive to matter. A small utility crate that saves someone time or makes a frustrating task easier can still be genuinely valuable to the community.

When doing a move, Rust just passes a memcpy to the LLVM IR. LLVM takes care of eliding the copy (in most cases - not always!)

I have a long history (27 years) of writing email software - who knows, maybe someone here even recognizes my name(?), but I'm pretty new to Rust.

I've written multiple desktop email clients, multiple widely used email libraries, and now I am working on an email server professionally.

I know there are crates like `mime-parser` and `mailparse` and `lettre` but I think I can do better.

I was actually just reading the announcement post for `mime-parser` from 5 years ago and it seems people were very against `unsafe` code, so the question I have is:

If I *were* to implement this library for Rust, should I or should I not optimize it using SIMD? It seems SIMD would mean unsafe code if I am not mistaken.

If most of the Rust community would avoid my library because it was used `unsafe` code, then I want to know that before I make the time investment. To be fair, I've already implemented an incremental base64 encoder, base64 decoder, uuencoder, and a uudecoder using SIMD in Rust and they are blazing fast and all have scaler fallbacks which are also as fast as humanly possible, but I've got plenty more tricks up my sleeve for the actual *parsing* of MIME messages.

Is there a standard way people have addressed this in other creates? E.g. shipping an accelerated vs non-accelerated version of the same crate somehow?

Not sure if Rustaceans in this sub saw this news earlier this month. But given AI agents are getting very good at escaping sandboxes now, it might be worth your attention to patch Wasmtime.

TL;DR: A typo in a validation check let a malicious WebAssembly guest pass an invalid callback signature, overflow the host’s native stack by up to 16KB, and potentially run arbitrary code on the host. Fixed in Wasmtime 48.0.4 and 49.0.2.

Wasmtime is a WebAssembly runtime written in Rust, built by the Bytecode Alliance (Fastly, Mozilla and others are members). It runs WebAssembly modules and components outside the browser, often as a sandbox for untrusted code.

Wasmtime published a critical security advisory on 2 October, GHSA-32h6-97mm-8q3c, CVSS 9.3. The bug sat in the component model’s handling of async callbacks.

Three checks were missing or wrong:

• The validator in wasmparser (crates/wasmparser/src/validator/component.rs) checked a callback’s signature with this line: if func_ty.params() != [ValType::I32; 3] && func_ty.params() != [ValType::I32] { It used && instead of ||, and it checked params() twice instead of checking results() at all. A callback only failed validation if it matched neither shape, so the result type was never checked.
• Wasmtime recorded the callback’s index without checking its arity or return type itself, trusting the validator to have done it. The host-to-guest trampoline had no bounds check on its parameter and result buffer either.
• The stack space reserved for the callback’s return value was sized for the expected arity, not the actual one.

A guest module can supply a callback with an invalid return type that still passes validation. Wasmtime then writes up to about 16KB of guest-controlled data onto the host’s native stack, which can overwrite a return address.

Vulnerable versions: wasmtime 39.0.0 up to 48.0.4, and 49.0.0 up to 49.0.2. Fixed in 48.0.4 and 49.0.2. A workaround is to disable component-model-async, or to validate components with wasmparser 1.260.0 or later before passing them to Wasmtime.

Link to the original source - https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-32h6-97mm-8q3c

I recently started building a hobby calculator app in egui, given its popularity. The app mimics a Graphing calculator that was abandoned several years ago.

I started with egui, given its popularity, but soon started facing hurdles because it challenges my web dev (aka retained mode) brain. I'm curious if these points are common among other devs also or how they handle it.

First, I started with egui ( only dependencies: eframe + peg )

• Being immediate mode, the components often don't know about the layout requirements of their next siblings or often their children/parent. This creates some challenges, like a flexibly growing widget either needs to be created last or manual size calculations need to be done to accommodate the next elements.
• We are free to create state anyway, like mutable members in a component struct or get_temp, get_persisted, etc. methods, which hand over the state management to egui. This threw me into a puzzle of finding what is best for my case. I ended up using the mutable members in a component struct.
• The event handling is also something that gets weird at times. While the trivial cases of handling clicks are as simple as `if btn_resp.clicked() {...}`, I searched unnecessarily long for other cases, like how to detect Enter presses on an Input element. Apparently, it is `input_resp.lost_focus() && ui.input(|s| s.key_pressed(Key::Enter))`, but it felt unconvincing that this is the way.
• Command-Action-Response (Message passing, command execution, etc) architecture is also something I spent significantly more time on, and even though I can make it work now, I don't think it is convincing. By Command-Action-Response, I mean a deeply nested component(keyboard button) triggering a command that should do calculations in a separate thread and get rendered in some other component. It requires passing channels deep down to your components, which works, but it will always be something that will trip me up into thinking of a better approach.
• Lastly, I was learning and implementing by going through their examples or other public code, and often it was taking too much time for simple things. I found a few resources also, but after seeing that many are using App::update (now removed) instead of App::logic + App::ui, it again felt unconvincing to go with them, and I took the route of reading examples & public code to learn.

Then I tried rewriting it in Freya

While there were also new things to learn, it felt like a breeze till the end and I achieved the same state as the egui variant in probably 80% less time.

• The documentation is really good. It gives an overview of not only modules, but also common patterns like for state management. Even beyond that, every other function would be documented with examples that show the usage patterns around it.
• Being in retained mode, the layout management was really easy. It did take time to know things like a growing widget requires the parent to also be `.content(Flex)`, but it was still very intuitive, particularly coming from web dev / retained mode.
• State management was even better. After just writing egui implementation, I tried creating similar state management types but eventually found that the use_state/use_memo hooks remove a lot of boilerplate. The state is reactive out of the box.
• I expected a retained-mode app to take more RAM, but it was actually less. Egui app, in release mode, took 320+ MB, while Freya takes <270MB. The release binary is slightly large: 29MB egui vs 36MB Freya, but the RAM & CPU usage for freya was lesser.
• Lastly, the freya app looked more polished and took way less time to reach a convincing state than egui.

Why am I writing this here?

See the above text as me dumping my naive observations after spending a day writing the egui+freya app. I am more interested in knowing from other developers who wrote egui/GUI apps on

• whether they also encountered these speed bumps
• if they found resources or developed patterns to ease out the things

P.S.: I don't think there is anything interesting or relevant in the implementation itself, that's why not putting the effort of creating a repo to share, but if someone is curious, I can push it.

Also, open to feedback - on the subject or the post, whatever.

EDIT: Changed image to have light mode (original) and dark mode variant of Freya

The first loop didn't generate any code:

// 1. `0..n` visits 0, 1, ..., n - 1.
pub fn excl(n: u64) -> u64 {
    let mut s = 0u64;
    for i in 0..n {
        s = s.wrapping_add(i.wrapping_mul(i));
    }
    s
}


// 2. `0..=n` visits 0, 1, ..., n: the same loop with one more pass.
pub fn incl(n: u64) -> u64 {
    let mut s = 0u64;
    for i in 0..=n {
        s = s.wrapping_add(i.wrapping_mul(i));
    }
    s
}

So I'm learning Rust, so I wrote this

fn main(){

let x = define_x(intial_x());

let y = x + 10;

println!("{}", y);

}

fn define_x(mut x:i32) -> i32 {

x = x + 5;

return x

}

fn intial_x() -> i32 {

let x = 5;

return x

}

I know it is supposed to be += in define_x, but that just looks weird to me. Why is let x = 5; in inital_x not mut even if I am changing it in define x? Sorry if it is bad I'm new, but I'm not AI so yay!

PEAR Configurator - Restore Apple devices on Linux
Built with Rust + Slint - native Wayland/X11, no Electron

- Instantly detects DFU / Recovery mode and identifies exact model (e.g. Macmini9,1)
- Lists signed firmware , downloads with resume + SHA-256 verify
- Two modes: Erase & Install and Keep Data
Ships as AppImage with idevicerestore toolchain bundled
-Supports iPhone, iPad, iPod, Apple TV and Apple Silicon Mac

\*tested on m1 mac mini,iphone 7 and iphone 16e in dfu mode restored succesfully*

Open source MIT:

https://github.com/denizomer10/pear-configurator

Looking for testers, especially for Apple Silicon restores. Feedback welcome!

Tov is a new programming language that transpiles to C but claims that it performs better than Rust and C, so I wrote a blog post that debunked its benchmarks.

FYI: I do not use LLMs (you should follow me in mastodon) :)

As you may or may not know, RP Pico is classified as micro controller with 264KB memory and few megs of flash - not like SBC like Pi that can run something like Linux or other monolithic OS like that.

The W adds WiFi to it and we can thus create some traps with it.

But it's now got a TLS.. HTTP and my little app that does something sus

sus being a Rick-Roll at every opportunity it gets bolted into embassy.dev:

https://github.com/yaws-rs/embassy/

My HTTPS server is called YAWS (not the erlang yaws but plays homage to it) - https://yaws-rs.github.io/book/

To get this done other than using https://embassy.dev latest and greatest from it's main branch that links to it's new TCP/IP stack called xarxa.

I made entirely new minimal TLS1.3 stack that works in no_std+no_alloc environment: https://docs.rs/ytls-server/latest/ytls_server/, https://github.com/yolotls/yolotls, https://yolotls.github.io/book/

I wired up RustCrypto already to it and plan to wire up other providers i.e graviola.

I tried to turn rustls as-is into no-alloc but I quit at 15 generics where as my takes about three.

However my is fixed into several primitives (ChaCha20Poly1305+X25519+SHA256 for now) and doesn't exactly follow MTI. It's also limited to small frames and there is bugs galore so do not use in production yet.

It does have pluggable crypto if you want to bring your own crypto (or someone else's crypto) and pick your own primitives as long as they convey into the traits I've designed among other traits maxxing:

https://docs.rs/ytls-traits/latest/ytls_traits/

I also use it in my io_uring HugeTLB runtime called yaoi:

https://github.com/yaws-rs/yaoi/tree/main/examples/blueprint-tls-http

But there it has the luxury of both alloc and std.

The fun bit also is that all the protocols are isolated state machines:

https://github.com/yaws-rs/h11spec

https://github.com/yaws-rs/tls

Which are no_std & no-alloc with heavy use of callbacks, traits and streaming parsing over parsing into holding struct some sort.

The Application layer injected into the h11spec is also isolated i.e.:

https://github.com/yaws-rs/h11spec/tree/main/apps/rick_roll

It's a hobby project so far and expect a lot of bugs but I wanted to provide how to make sans-io with isolated state machines in a way that can carry state.

The real value would come from composability i.e. where you can run 10 layers of TLS (if anyone wants to world should be your oyster!) or whatever protocols you want and switch in between sans hard linking them together.

With crypto I do not like current crop of feature flags in most crates which can lead into miscompilation or no-compilation.

Instead users supply the chosen crypto impls through trait impl:

https://github.com/yaws-rs/yaoi/blob/main/examples/blueprint-tls-http/src/ytls.rs#L68

Or even picked through generic (see RustCrypto concrete type):

https://github.com/yaws-rs/embassy/blob/main/src/bp_https.rs#L17

Hi folks, so I'm presently on a fun year-long project making a numerical application, and one experimental feature I'm trying to implement flexible fp types. Probably not super useful in most situations but it seems fun to make. I've made f16 and bf16 from the half crate work, and now I'm looking to try for f128 to see if it could be useful for numerically unstable procedures or data inputs.

As you guys may know f128 in Rust is unstable and apparently produce incorrect results as per the warning, so this isn't usable. Available crates don't quite suit my needs, e.g. astro-float is heap-allocated and arbitrary precision, which isn't what I want. I also need stuff to be cross-platform (including WASM).

I'm wondering whether any of you folks have any solution for using f128? The last resort would be hand-rolling this with a two-letter tool, which might be possible, but doing so for low-level numerics sounds a bit too hairy for my liking...

Thanks in advance.

Hello. I honestly don't know how to start this post because is the first time I post about programming in general.

I started working on a Rust project over the past few months in order to learn about the programming language, i like terminal a lot and needed a tool to change my brightness without touching my mouse.

I thought about using brightnessctl and just live my life normally, but there's no fun in letting someone else's program solve your specific needs when you want to learn. So, i had the idea to make my own script for monitor management using the i2c crate to communicate with monitors via DDC.

Which resulted in this project: https://github.com/EmmaThinks/MconfP

I want some feedback about it! it took me a lot to understand some concepts and i was stuck with a lot of things over this journey, so any comment about where i can improve the script would be appreciated.

Due to the nature of the security issue, I recommend updating this via a trusted network, and not a public wifi.

Context: https://www.reddit.com/r/rust/comments/1xba5mj/psa_if_your_program_does_http_requests_update/

Chain Reaction is a mobile game that my father and I enjoy frequently. I kinda disliked the fact that it wasn’t available on PC, and decided to rectify that by writing it myself.

The core library only uses std, array2d and log, and implements the basic logic for the game. An actual playable app is provided by a terminal application, written with Ratatui.

All of this is hand-written code, but not necessarily the best way to have written it, so if someone would like to go through and suggest changes, I would love to hear it.

I built an API client, free and open source.

It's called Tuma, Swahili for "send".

For years my API requests lived in someone else's cloud, behind a login, a sync button and a per-seat price. wanted something simpler:

- No account. Open it and send a request.

-No cloud. Your requests are plain files that sit in your repo, next to the code they test.

-Fast. Rust inside, not a bundled browser.

And it does a lot more than send requests:

-Runs your Postman collections and test scripts

-GraphQL, WebSocket, gRPC, OAuth 2.0

-Load tests with p95/p99 latency and security checks

-Mock servers and API docs generated from your requests

- An MCP server so Al coding agents can test your API too

It's available for Linux and Windows today, with macOS coming soon.

If it saves you time, a on GitHub helps more people find it. Feedback is very welcome.

Link: https://morriskm.github.io/Tuma/

New post from Deb Brouwer on the Tyr Rust GPU driver for Arm Mali, which now boots its firmware in mainline Linux 7.3:

https://www.collabora.com/news-and-blog/blog/2026/10/21/upstreaming-tyr-rust-drm-and-the-linux-kernel/

The parts most interesting for Rust folks:

- How a WARN_ON in the C page table code became an explicit safety requirement on the Rust `map_pages()` API

- Why Tyr uses the full GPUVM abstraction even for a simple, fixed firmware layout: to uphold those invariants instead of trusting assumptions

- What it's like to write a driver while the kernel's Rust abstractions are still being designed (Tyr has been rewritten several times)

(I'm at Collabora, where Tyr is developed. Happy to pass questions along to Deb.)