DKIM2 is now supported by the mail-auth and mail-send crates

For those not familiar with email internals, DKIM2 is the next iteration of DKIM, the email signing scheme that lets a domain cryptographically vouch for a message. The problem with DKIM1 is that a signature only covers content, so the moment a mailing list or forwarder touches a message the signature breaks, and a signed message can be replayed to any number of other recipients. DKIM2 turns a signature into a link in a verifiable chain of custody: each hop that modifies a message records a reversible "recipe" for its change and adds its own signature, the envelope (MAIL FROM/RCPT TO) is signed so replays no longer validate, and bounces can prove they're genuine. It's a fairly big rethink of how email authentication works.

DKIM2 support has been added to `mail-auth`, the Rust message authentication crate (it already does DKIM1, SPF, DMARC and ARC). The same release also implements DMARCbis (RFC 9989/9990/9991), the new DMARC standard that replaces the Public Suffix List with a live DNS tree walk.

If you want to see how DKIM2 actually behaves, there's a playground at mail-auth.stalw.art. It's the crate itself compiled to WebAssembly, running entirely in your browser and using DNS-over-HTTPS to resolve keys and validate signatures, so you can sign and verify DKIM2 messages and run DMARCbis checks with nothing to install.

If you don't care about the low-level details and just want to send DKIM2-signed email, `mail-send` integrates mail-auth behind a much simpler API.

For a more technical write-up of what DKIM2 and DMARCbis change and why, take a look at the blog post.

Feedback and bug reports welcome!

https://redd.it/1upxbcw
@r_rust

A standalone MVCC engine for transactional storage systems in Rust

We're open-sourcing **nexir-mvcc-core**, the transactional MVCC engine that powers the Nexir database.

The project focuses exclusively on concurrency control and version management, keeping storage, networking, consensus, and query execution outside the MVCC layer. It provides:

* Timestamp-ordered MVCC reads and writes
* Intent-based transactions (`prewrite` / `commit` / `abort`)
* Atomic multi-key batch transactions
* Guarded (CAS-style) writes
* Incremental MVCC garbage collection
* A backend abstraction that allows integration with different storage engines
* Backend conformance testing utilities

The goal is to provide a deterministic, reusable MVCC core that can serve as the foundation for transactional storage systems without requiring an entire database stack. 

We're interested in feedback from Rust developers working on databases, storage engines, distributed systems, or transactional KV stores.

GitHub: [https://github.com/nexirdb/nexir-mvcc-core](https://github.com/nexirdb/nexir-mvcc-core)

Happy to answer questions about the architecture and design decisions.

https://redd.it/1uq204t
@r_rust

rama 0.3 released
https://plabayo.tech/blog/rama-0-3

https://redd.it/1uq14t1
@r_rust

Is there a CSV search crate yet?

What I am looking for is like binary search or faster of a CSV file for IP addresses, does something like this exist yet or not? Not MaxMindDB, CSV, more free stuff is CSV, so?

https://redd.it/1uqach6
@r_rust

Rust splits polymorphism into two completely separate design choices

Coming from a traditional object-oriented background (Java/C#), inheritance gave me polymorphism. You create a base class, extend it, throw your subclasses into a contiguous array, and call it a day. When you migrate to Rust, inheritance disappears. But instead of leaving an architectural void, Rust actually splits polymorphism into two entirely separate, highly intentional design strategies based on your data layout boundaries:

1. Closed Polymorphism (Compile-time completeness)

This is where your types are strictly locked down at compile time, typically using uniform-sized Enums.

The Trade-off: The compiler calculates the exact footprint of your largest variant, adds a small tag, and sets up a flat block of stack memory. It is blazing fast and gives compile-time guarantees that every variant is accounted for.
The Catch: If you want to add a type later, you have to modify the central definition. It entirely prevents third-party modular extension.

2. Open Polymorphism (Infinite extensibility)

This is what we step into when we use dynamic dispatch, vtables, and heap-allocated Boxed Trait Objects.

The Trade-off: You can drop in entirely new data types from separate, external third-party crates next week without touching a single line of your core engine code.
The Catch: You give up data uniformity, force pointer-heavy allocations onto the heap, and pay a tiny dynamic dispatch tax.

To map this out practically, I used both strategies to build character types for a game backend. Coming from an OOP background, my first attempt at the closed solution with Enums resulted in massive data duplication and tons of repetitive match-statement boilerplate.

I ended up solving the data clunkiness by forcing Composition over Inheritance—separating shared stats into a standard struct, variant-specific data into an enum, and wrapping them both in a parent struct. This kept my storage in a perfectly flat Vec while letting me read common fields cleanly without paying an access tax.

However, the moment I wanted to let third-party modders add custom player types, my beautiful closed enum solution hit a hard, unyielding structural wall.

For those writing large-scale systems in Rust, how do you map out this boundary early on? Do you find yourself defaulting to enums for performance until requirements force you onto the heap, or do you architect for open extension from day one?

Context: I run a channel focused on software engineering in Rust using high-fidelity animations to trace memory footprints and system boundaries. If you want to see a visual breakdown of this exact Closed vs. Open memory model and the refactoring step-by-step, check it out here: https://youtu.be/l\_q9U10JueE (Full code for the closed, open, and hybrid implementations is over on the GitHub linked in the description).

https://redd.it/1uqgk6t
@r_rust

Is it tauri good for cross platform apps?

My goal is to create a cross platform app using Tauri with rust. On the front and side, I'm planning to use react with a typescript and on the backend well, of course, rust. However I am not so sure if Tauri is a great choice for Android apps, given the fact that Tauri uses webview to render apps.

I want to make it feel lightweight and with a small size overall. My focus is Linux, Windows and Android, my primary OSs that I use. I know for desktop apps is ok, but when it comes to desktop AND Android apps I am not sure if performance could be harmed or even impossible to do.

I just finished the rust book so you could say that I am new to rust and this would also be my first cross platform app outside webdev (granted: tauri uses webview and I planing to use web technologies, but still, it feels like another world). I am doing my research but any guidance would also be pretty much appreciated.

PD: For more context, it is a document viewer, like a pdf and epub viewer.

https://redd.it/1uqad41
@r_rust

This Month in Rust OSDev: June 2026
https://rust-osdev.com/this-month/2026-06/

https://redd.it/1uq1xps
@r_rust

How do people feel about AI being used in the core language?

I know this is Reddit, but I would like to preface this by saying that I'm interested in having a balanced and reasoned discussion with other rustaceans about their feelings regarding AI commits in the core language, and how they think it might impact their choice of programming language in the future.

With that out of the way, how do you feel about Generative AI being used in the core language, and the rust foundation accepting donations from AI companies? Personally, I don't like AI. Not through some aversion to new technology (rust is my language of choice, after all), but because I have no desire to use something with so many unanswered ethical questions (environmental impact, training on stolen data, reinforcement of existing biases etc) in my processes. This is not a binary black and white stance, but a desire to minimize my impact where I can.

Rust has long been my favourite programming language. It's fast, comes out well in energy usage benchmarks, and the compiler makes me feel a lot more confident in the code I write. However, the official position of the rust foundation is very pro AI. They've accepted large donations from OpenAI, and there have now been commits to the core language that have used AI to a certain extent.

This leaves me with a conundrum. Overall, I feel that Generative AI is rapidly making the digital world a worse place (we're drowning in slop) and I want to avoid that as much as I can. Do I stick to an older version of Rust? Do I move to another language like Zig that has an anti-AI stance (impressed by that, not impressed by much else that I've heard from the main developer)? Do I try and fork the language myself knowing that I lack the knowledge or time to do anything more with it than make a statement?

I'm still not decided yet, but would be very curious to hear if others are currently contemplating similar choices, and what your feelings are on the matter.

https://redd.it/1uqm388
@r_rust

broadsheet: a Rust animation engine where the whole video is a pure function of time — tech demo (binary search, hash rings, union-find)
https://redd.it/1uqn0bm
@r_rust

Still surprised by how helpful Rust's compiler is

I've been spending more time learning Rust lately, and one thing that keeps surprising me is the compiler.

At first it felt like it was constantly telling me I was doing everything wrong. But after sticking with it for a while, I realized most of the error messages are actually pointing me in the right direction instead of just saying "this doesn't work."

I'm definitely still a beginner, but I've had several moments where I fixed a bug simply by following what the compiler was trying to tell me.

Did anyone else have that moment where Rust's compiler went from feeling like an obstacle to feeling like a really patient mentor? I'm curious how long that shift took for others.

https://redd.it/1uqpppm
@r_rust

memegen.rs - a meme generator where the entire meme is the URL (no database, ~1900 lines of Rust)

https://preview.redd.it/d9b3rj1b60ch1.png?width=675&format=png&auto=webp&s=d0d7bbb2d1bb3347ffe2f3580b2e1f9df87ae11a


The image above was rendered by the thing itself. This is its entire existence:

https://memegen.rs/images/bell-curve/just_put_the_meme_in_the_url/no,_you_need_postgres,_redis,_s3,_a_cdn,_and_auth/just_put_the_meme_in_the_url.png

That URL is the whole meme: template id, then one path segment per caption box, spaces as underscores. No database, no cache server, no accounts - every image is rendered on demand from the URL alone, so any meme is shareable and reproducible forever.

It's a reimplementation of [jacebrowning/memegen](https://github.com/jacebrowning/memegen) (the Python service behind memegen.link). Stack: `axum` for HTTP, `image`/`imageproc`/`ab_glyph` for rendering (caption autosizing, word wrap, outlined text, animated GIFs), `maud` for a compile-time-checked web UI. 1924 lines across three source files, 701 templates bundled, fonts embedded with `include_bytes!`, `unsafe_code = "forbid"`. The deployment is one binary plus a directory of template folders.

Deploying it was its own adventure: it runs as a Cloudflare Container that scales to zero when idle, with a Worker in front caching rendered images at the edge, so cache hits never touch the Rust process. Two gotchas for anyone trying the same: Cloudflare's registry can't pull from GHCR, and it rejects the `latest` tag.

A side effect of the API being nothing but URLs: agents can use it with zero setup - there's a drop-in skill file at [memegen.rs/skill.md](https://memegen.rs/skill.md) (and `/llms.txt`).

Repo: [github.com/tenequm/memegen-rs](https://github.com/tenequm/memegen-rs) \- code is MIT, the bundled template images aren't (see README)

Live: [memegen.rs](https://memegen.rs)

Since a meme is just a URL, it works anywhere you can paste a link - Reddit comments included. Template id, caption in the path, done. All 701 templates are in the gallery at [memegen.rs](https://memegen.rs).

https://redd.it/1uqrvfb
@r_rust

Orbolay - A Discord overlay alternative created with Rust + Freya
https://redd.it/1uqwvb1
@r_rust

Three years after rewriting RootAsRole in Rust, v4.0 is here
https://redd.it/1ur3fab
@r_rust

Rewriting Bun in Rust
https://bun.com/blog/bun-in-rust

https://redd.it/1ur8ca1
@r_rust

Textract: Texture Extraction tool made with Tauri
https://redd.it/1uqxisc
@r_rust

Rust proliferation in the Linux Kernel

If you ever wondered, how it's started vs how it's going, with hard numbers (and some charts) here is a single-pager: https://rusted-kernel.com/ (GitHub pages, open source)

Feedback welcome.

https://redd.it/1ura8xu
@r_rust

How to poll the value of a future after spawning it with spawn_local



I am trying to make an app that can open a file dialog and save the selected file(s) as a string path. I am using rfd for the file dialog and Slint for the UI. It's to my understanding that I need to poll the value of a future in order to get the result (assuming it is completed), but I can't seem to figure out how to poll the value when using Slint's `spawn_local` function. Here is my code:

fn main() -> Result<(), slint::PlatformError> {
let main_window = MainWindow::new()?;
let window_handle = main_window.as_weak();

main_window.on_test_function(move || {
let main_window = window_handle.unwrap();

let future = async {
let file = AsyncFileDialog::new()
.add_filter("media", &["mp4", "mp3", "m4a", "wav"])
.set_directory("/")
.pick_file()
.await;

if (!file.is_none()) {
let data = file.unwrap().read().await;
}
};

let future_result = spawn_local(future);
let future_unwrapped = future_result.as_ref().unwrap();

let good_result = future_result.is_ok();
println!("{} Good result = ", good_result);
if good_result == true {
if future_unwrapped.is_finished() {
// poll value and set the path to the resulting path
// main_window.set_path(future_result.poll());
}
}
});

main_window.run()
}

I am using an async function because I am building this application for Linux. I read on Slint's github:

>

One of the contributors recommended to use the async file dialog with slint's `spawn_local` function to prevent the dialog from freezing the event loop.

EDIT: Probably should've included this in the initial post,. I am very new to rust, I started learning it yesterday, but I have experience with C# in unity and godot.

https://redd.it/1urau7l
@r_rust

I built a WASM SIMD inference engine in Rust - semantic embedding model in 7MB - no torch, no ML framework (~2ms embedding inference)

Hobby project. I built a sentence-embedding model (distilled from MiniLM) where the entire runtime - forward pass, BERT tokenizer, and weights - is in Rust.

Compiles to webAssembly (ubiquitous runtime). One \~7 MB .wasm, no torch, no ONNX, no ML runtime.


Why from scratch: the weights are ternary (every weight is -1,0,+1), so inference is int8 multiply-accumulates, adds and subtracts, not floating point matrix multiply. This leverages vectorized parallelism (SIMD), which makes inference lightening fast on CPU.

Some additional musings:

\- The hot loop is WASM SIMD via `core::arch::wasm32` of quantized activations + weight row, `i16x8_extmul_low/high_i8x16` widening multiply,

`i32x4_extadd_pairwise_i16x8` + `i32x4_add` to accumulate. 16 elements/iter, int8 MAC.

\- `target-feature=+simd128` is pinned in `.cargo/config.toml`, and a `compile_error!` in lib.rs refuses to build without it.

\- The four embedding variants (fp32 / int8 / ternary / int4) are mutually-exclusive Cargo features

\- Hugginface `tokenizers` with `default-features = false` + `unstable_wasm` + `fancy-regex` - pure rust, no C dependency, cross-compiles to wasm cleanly.

\- Custom `.bin` wire format packs model + tokenizer, bit packing weights and special header that encodes model architecture



Numbers (M-series, single thread), two tiers:

\- mini: d256, \~2.5 ms/embed, \~400 emb/s, 5 MB wire

\- base: d384, \~5 ms/embed, 7 MB wire, 0.844 Spearman vs the MiniLM teacher


I'd genuinely love critique of the engine, especially the SIMD kernel and the quantization path. Repo: github.com/soycaporal/ternlight



https://redd.it/1urd2hp
@r_rust

nasa/spacewasm: A flight-compliant WebAssembly interpreter for safety-critical execution
https://github.com/nasa/spacewasm

https://redd.it/1urgjui
@r_rust

This Week in Rust #659
https://this-week-in-rust.org/blog/2026/07/08/this-week-in-rust-659/

https://redd.it/1ureq0r
@r_rust

Axum and Toasty RESTful Template Now Adds Garde and Utoipa Support
https://github.com/dumindu/axum

https://redd.it/1urlj0l
@r_rust