Lineup:

• Egor Lebedev - Welcome and a short note from the RustRover team
• Iván Ovejero - Compiling Rust Ideas into Go: Learnings from Lisette
• Orhun Parmaksiz - Debugging Rust in 2026

Event page: https://www.meetup.com/rust-berlin/events/316661690/

I'm a beginner in OS dev and have been tinkering with creating a RISC-V operating system in Rust. There are a lot of great resources out there, but most of the posts I found are slightly outdated, so I wanted to write a bit about my own journey. My goal is to use Rust's features as much as possible!

First, we'll go over creating a bare-metal binary and finish with a small executable that immediately shuts down the machine when it runs in QEMU. Hope you find this interesting, as I did!

https://ltungv.com/note/rv-bare-metal/

If yes is there a tutorial or a guide somewhere? I am using the STM32H7R3Z8J6 dev board from WeAct studio.

I wrote a small blog post documenting my journey of writing small green threads runtime in under 1000 lines of Rust. Any feedback welcome

The short version: adding X25519 to ML-KEM-768 costs 1.88x on keygen, 2.85x on encapsulate and 1.79x on decapsulate. We pay it on purpose, and only for key exchange.

I'm COO at 0x307, and we publish pqc-kem, a pure-Rust ML-KEM (FIPS 203) crate that also ships the X25519 hybrid and X-Wing. Whether the hybrid is on by default was a product decision before it was a crypto one, so here is how we made it.

The numbers (pqc-kem 0.3, criterion, dedicated Xeon Platinum 8488C, fixed-seed RNG, three passes, largest shift between runs 4%):

• keygen: 51.7 µs for ML-KEM-768 alone, 97.2 µs hybrid
• encapsulate: 54.6 µs alone, 155.8 µs hybrid
• decapsulate: 64.0 µs alone, 114.4 µs hybrid

X-Wing lands within 4% of our HKDF hybrid on every operation, and it also binds the X25519 ciphertext and public key into the shared secret, so it's the one we recommend for new deployments.

The trade, as arithmetic: about 100 µs more for the sender and about 50 µs more for the receiver, per handshake. Against that, a session recorded today can't be re-encrypted later. If ML-KEM turns out to have a structural flaw in five years, every session recorded with ML-KEM alone is exposed, and nothing we ship then fixes it. A hybrid holds as long as either half does.

What we're not doing: hybrid signatures. A broken signature scheme can be rotated. You revoke, reissue and re-sign. So pqc-sig keeps its Ed25519 hybrid off by default. The rule we use is to hedge where a break is permanent, not where it can be repaired.

Write-up with the full methodology: https://0x307.com/insights/hybrid-kem-measured

Numbers, CIs and the bench harness: https://github.com/0x307/pqc-kem/blob/main/BENCHMARKS.md

If the methodology is wrong, or you'd make the opposite call on signatures, I want to hear why.

I'm starting to write a series of articles about Rust, but in Spanish.

There is already a lot of great Rust content in English, but I wanted to contribute more material for the Spanish-speaking community. I'm planning to write about Rust patterns, architecture, and backend development.

This is the first one:

Command Pattern in Rust
https://codigolinea.com/patron-command-en-rust/

I'm sharing it here because I know there are Spanish-speaking Rust developers in this community as well. If the articles are useful, I may translate them into English later.

I'd also be interested in feedback from the community, especially on the technical side.

https://github.com/wyfo/maillon

Hello Rust,

I've just published my latest crate, a concurrent intrusive list for building synchronization primitives, featuring a high-level wait-list with atomic emptiness check, customizable synchronization, and lock-free insertion.

But first, what is it and why did I write such a data structure?

An intrusive list is a linked list whose inserted nodes directly embed the linking pointers. It is practical as it doesn't require allocating the nodes, which can live directly on the stack. It is especially used all over the async ecosystem in Rust, like in tokio, but also in std primitives like Once, as it allows cheap registration (no allocation) of wakers into primitives' wait-lists. However, having nodes on the stack is dangerous with futures, as futures can be dropped at any moment, releasing their stack memory. That's why node access must be synchronized, and the easiest way to do it is with a mutex, as done by 100% of the Rust implementations I know.

As I'm currently working on an MPSC channel implementation, I needed some synchronization primitives for the producers and for the receiver. In my previous post, I talked about the one I crafted for a single receiver. Then I needed one for multiple producers. Both synchronization primitives have the same design goal in mind: the cheapest possible wake/notify_one operation (i.e. read-only) when no waiter is registered, and a customizable synchronization to use SeqCst atomic operations or SeqCst fences (or RMWs) depending on the use case and/or the platform. Being read-only limits contention so the primitive can be stored in the shared cache-line of the channel.

Because multiple producers might be waiting and register themselves, an intrusive list with stack-allocated nodes was the ideal primitive. There are a few crates in the ecosystem providing this type of list, like pin-list, but there are also many crates that implement their own internal intrusive lists, which is a shame. However, I found no crate providing the primitive I needed (cheap notify_one + customizable synchronization); the closest ones were event-listener and async-event.

I could have gone with a mutex-protected pin-list beside an atomic emptiness flag, which is by the way roughly what crossbeam-channel uses (with a Vec instead of an intrusive list). But I had another idea in mind: what if I could make the node insertion lock-free? This is indeed a good property for an MPSC channel, where all producers register at the same time once the channel is full, while the receiver might concurrently release a slot. This idea led me to the current design, where the tail of the list is an atomic pointer which can simply be loaded to know if the list is empty (correct synchronization is not trivial though).

Then I got another idea: when the list is empty, the tail bits could be used to store an arbitrary state, like a semaphore counter or a mutex state. With it, I reimplemented tokio-compatible Semaphore and Notify, which beat tokio's on its own benchmark. Actually, the maillon-based semaphore beats all other semaphores of the ecosystem (futures-intrusive, asyncband, etc.) by a fair margin. I didn't imagine there were so many of them, but here is a new one to rule them all; you can find the numbers behind this claim in the crate's dedicated README.

But most importantly, my wait-list works well and is as fast and customizable as it can be, so I can use it in my channel. And the crate is of course extensively tested with loom and miri to ensure its correctness; the semaphore and notify reimplementations also pass tokio's loom test suite.

If you are interested in synchronization primitives, don't hesitate to take a look. There is a lot more to talk about (safe API without abort, generic linking strategy, persistent state, priority inversion, etc.), but this post is already quite long. Happy to answer your questions.

LLM disclaimer: most of the code was written at the beginning of the year when I was barely using LLMs to generate code. I did use LLMs for my recent work on it, mostly for refactoring, but also POCing a lot of ideas. There is not a single generated line that I haven't reviewed, and only a few non-boilerplate lines that I haven't reworked. However, while I wrote 100% of the documentation and comments myself in my previous projects, I used AI to sketch a significant part of the documentation, and I have to admit it sucked at it (surely a skill issue). So I ended up rewriting most of it, but LLMs are still fantastic at reviewing. Of course, this post was 100% written by me.

hi_sparse_bitset is a bitset that stores only non-empty bitblocks. It has hierarchical structure that speed ups intersection, merge, etc. by order of magnitude.

This release ( adds no_std support ).

Hey everyone,

I've been thinking of learning Rust, and I'd like to be able to make web backends with it. If you were to start today, what libraries and resources would you use? My goal is to make a simple CRUD app with some additional basics (authentication, multiple database writers, etc.).

Since I'm doing this out of passion and because I'd like to truly learn Rust, I don't plan on using any AI tools to code or design the apps for me. I'll be looking out for your suggestions! :)

I have a successful iOS app and I want to port some analytics-style features to desktop, things like receiving CSVs, lists, and input data, and showing dashboards, while keeping some of the core functionality my mobile app already has.

I was thinking about using Rust for the desktop app, but I also have experience using Flutter for the Android app (yes, I use native for iOS, but Flutter for Android, since using Kotlin was the worst experience I’ve ever had with a technology). I’d love some Rust recommendations to try

Hey everyone,

A few months back I showed a git client I was working on, written in Rust, with a UI in Tauri and React.

People asked why I didn't make the UI in Rust too. My answer was "skill issues".

Since then I have studied the blade and finally got around to doing this!

I put this off for a while, but growing pains with window panes forced my hand. Also Linux support.

From my past attempts to try every Rust UI library I liked Iced the most, and so I used that. It went much better this time, and I ended up with a shiny new interface.

I wrote a blog post about my adventures here:

https://www.gitcherrytree.com/blog/rewriting-the-ui-in-rust/

To entice you, here are some numbers and letters about the main bits, with mysteries revealed in the blog:

Overall I find myself happy to have done this. I always felt that you should be able to do everything in the same language and swapping out Tauri left me in Rust. I'm happy here in my hole.

lzbench published new results after a year, and mbrotli is now sitting next to Google Brotli.

The interesting part isn't just who is faster, but why: safe Rust and raw C make very different trade offs once you get into the hot loops.

TLDR:
The subject is not compiling each files.
The subject is composing you main application of independently build libraries.

That's the question. Why not making multiples crates and composing your app out of it.
Why build everything all at once.

It's not dynamic link, it's not dynamic libraries, just separate the work in multiple crate and having the main app using those crates instead

---

I'm looking at a few Rust projects around, not big ones; I'm still learning.
And most of the time, everything seems to be one compilation unit for binaries.
I have a background in C (but an old one) and we were compiling every file into its own .o then making libs with them and using them in the app that would compose with thoses libraries.
But there, it seems like you're building everything grouped in one crate.

Would not having it separated into multiple sub-crates, like a kind of lib (obviously not everything, but logically), make the next builds rely on the local already built?

I used to build basically libs that do their work and expose what they need to be used, and have a binary that links everything together.

I'm wondering if that is still a good way of building things or if I’m wrong, as I'm seeing many small projects adopting the "monolith binary" instead of a lib composition kind of architecture.

I don't mean dynamic lib; I mean splitting into multiple crates, then using those crates. Like the workspace option in Cargo. I don't see that used as much as I thought it would be used. More full projects in one crate.
So it's more a one-crate project vs workspace with multiple crates project.

Is there a reason I'm missing?
Thanks if anyone can help me understand that!

The first part of a series I'm writing on writing/implementing Linux Kernel modules in Rust.

Thats all. It is such an important feature and it would make me sleep better. I know i can switch to nightly and i consider that, but this has other implications.

Currently as i understand it the plan is to release this as part of 1.100 and this is somewhere near end of November.

What do you think?

Have a great day

Tauri's updater re-downloads the whole installer on every release, even for a one-line change. Delta updates have been an open feature request since 2024 (tauri-apps/tauri#11863), so I built them as a plugin.

tauri-plugin-updater-delta doesn't patch installed files. It rebuilds the exact signed installer from a zstd --patch-from patch, then hands it to the official tauri-plugin-updater. Same manifest, same signing key, same installer. If anything fails (cache miss, bad patch, network), it falls back to a normal full download.

Numbers from a benchmark app with ~88 MiB of bundled assets and a feature-sized release:

- macOS .app.tar.gz: 6.9 MB instead of 78 MB

- Windows NSIS: 7.0 MB patch (bsdiff got 6.6 MB on the same pair)

The video shows a small demo app taking a 714 KB update.

The interesting problems weren't the diffing:

- Diffing .app.tar.gz directly gave patches ~95% of the full size, because gzip scrambles everything. Diffing the inner tar gets ~15%, but then the gzip has to be rebuilt byte-for-byte or the signature fails. That only worked after reading tauri-bundler and replaying how it streams tar::Builder into flate2, and only with the zlib-rs backend (miniz_oxide can never match).

- NSIS solid LZMA gave ~98% patches. The fix is NSIS compression "none" for the updater artifact, while full downloads come from a zstd copy about the size of LZMA, so they don't cost more than stock Tauri.

- zstd patches of a 105 MB installer were 31% of full until I sized the hash and chain tables to the window. Then 6.9%.

- Tauri's updater verifies signatures in download(), not install(), so on the delta path the plugin's own check is the only one. The release version is authenticated through minisign's trusted comment, and the installer handoff only accepts a VerifiedArtifact type that can't be constructed outside the verification function.

Honest status: v0.2, pre-release. Proven with real installs on macOS aarch64 and Windows x86_64 NSIS. No Linux, MSI or Windows ARM64 yet, no notarized/Authenticode end-to-end run yet, and no external security audit.

Feedback from anyone shipping Tauri apps is very welcome, especially on Intel Macs and with signed builds.

Repo: https://github.com/Chahdane/tauri-updater

Write-up: https://dev.to/chahdane/tauris-updater-downloads-your-whole-app-every-time-making-it-download-only-the-diff-took-more-1j8m

I maintain a desktop network monitor where the UI is Flutter and the probing engine is Rust (Tokio), exposed through a plain C ABI over FFI. A code review found three problems that tests and clippy never caught. Sharing them because they're not specific to my project.

1. A panic in extern "C" kills the whole host process Since Rust 1.81, a panic that unwinds out of an extern "C" fn aborts. For me that meant one .expect() in a lazily built runtime could take down the Flutter app, not just the engine. The fix: every exported fn now goes through a small wrapper:

   fn ffi_guard<T>(fallback: T, f: impl FnOnce() -> T + UnwindSafe) -> T { std::panic::catch_unwind(f).unwrap_or(fallback) }

Gotcha: this does nothing with panic = "abort" in your release profile, so I pinned panic = "unwind" and added a test that panics on purpose across the boundary.

1. sleep(interval) in a loop is not a period My probe loop did sleep(interval) and then probe().await, so the real period was interval + probe time, and it drifted further under packet loss (exactly when you want accurate timing). Switched to tokio::time::interval with MissedTickBehavior::Skip.

2. #[cfg(not(windows))] code rots silently if CI is Windows-only The native ICMP path is Windows-only, and the non-Windows stubs had unused imports and params. clippy -D warnings failed on Linux/macOS, but CI ran only on windows-latest, so nobody noticed until a contributor on macOS did. Now CI has an ubuntu job, even though that platform uses the fallback path.

Bonus (not Rust-specific but it bit me): an "ICMP failed, fall back to TCP" path was silently hiding real packet loss in the stats. If you're measuring something, a fallback has to be visible in the data, not just in the code.

Curious how others handle FFI panics. Is catch_unwind in every entry point the norm, or do you push everything onto a worker thread and only pass results across?

(Code for context: https://github.com/Cadman021/VeloceNet-Studio, GPL-3.0)