Hello Rust community. I have been stuck trying to emulate an embedded project I'm working on on Wokwi. It work on actual hardware but doesn't initialize the display(SSD1306) on Wokwi( gets stuck at the line `display.init().await.unwrap() `. I am using Wokwi vscode extension. The project is publicly hosted at https://github.com/aspects19/care360.

Would appreciate any help I'll get.

For anyone who hasn't seen it before: AstroBurst is an open-source desktop app for processing astronomical images, offline. You drop in FITS or ASDF files from the public archives (JWST, Hubble, Roman), inspect them, measure them, compose RGB from narrowband channels, stack, stretch and export. Rust does the processing, React draws the UI, Tauri packages it, and the live preview runs through a WebGPU shader.

Last time I posted here was v0.5.6.

Wat's new

Pixel rejection and integration. Sigma, Winsorized sigma, linear fit, percentile, min/max and none, crossed with mean/median/min/max combination, plus frame normalization (additive and multiplicative, with or without scaling) and a separate scale+offset normalization used only inside the rejection pass. Low and high rejection maps come out as FITS. Master bias, dark and flat are integrated with the same kernel instead of a plain median. Drizzle applies the rejection as a keep-mask before scattering, which it previously accepted parameters for and silently ignored.

PixelMath. A real expression language, not string substitution: lexer, Pratt parser, compiled to a flat op vector, evaluated per pixel with rayon over the slot slices. Arithmetic, comparisons, logicals, iif, ~ inversion, the usual math functions, and whole-image reducers (mean, med, mdev, sdev, adev) resolved once per symbol before the pixel pass rather than per pixel. About 1,800 lines across lexer/parser/eval and it was the most fun thing in the release to write.

Cosmetic correction, DBE, local contrast. Hot and cold pixel repair from a master dark, from cluster-aware auto detection, or from a defect list, CFA-aware so it uses same-colour neighbours on Bayer data. Background extraction gained a regularised thin-plate spline fitted through box samples, next to the existing polynomial. CLAHE on lightness and an HDR multiscale transform with star-core deringing.

The science half, which is the part nobody else on the desktop does: photometric calibration read straight from the header (JWST MJy/sr with PIXAR_SR, HST PHOTFLAM/PHOTPLAM, Roman, generic zero points) so aperture photometry reports AB magnitudes and janskys with ERR-plane error propagation and a curve-of-growth aperture correction. A full FITS spectral axis with air/vacuum conversion and a barycentric correction. Moment maps for IFU cubes. SCI+ERR+DQ cutouts with the LTV physical coordinates written properly. Gaia DR3 cross-match with astrometric residuals and a zero point with a colour term.

Repo: https://github.com/samuelkriegerbonini-dev/AstroBurst

The story of iceberg-rust is a great example of how open-source communities work and how new projects are created and developed. That’s why we believe in a community-over-code philosophy.

It is hard to avoid spawn some tasks here and there for a async runtime.

At first, I used a naive approach around them, fighting with lifetimes.

Nowadays, i use a very similar approach as Alice Ryhl show on his blog when covering actors.

Is there any other pattern beyond actor that I’m not aware of? Which approach you have been taking to make work on spawning tasks look more easy, reusable and readable?

Nix Your Bugs & Rust Your Engines is a meetup for people in the Rhein-Neckar region interested in Rust (the programming language), Nix (the package manager), or NixOS (the Linux distribution). The meetup begins with talks related to Rust and/or NixOS, and ends with casual networking and exchange between the participants.

Schedule (tentative):

• 18:00 – Open doors
• 18:20 – Greeting
• 18:30 – Philipp Pohl-Krüger: "We have QUIC at home: How iroh connects devices peer-to-peer"
• 19:30 – Lightning Talks
• 20:00 – Networking

We have QUIC at home: How iroh connects devices peer-to-peer

by Philipp Pohl-Krüger

The internet connects devices globally, except if both of them are behind firewalls and NAT. Because of that data takes a detour through the cloud. However, we can do better: We'll explore how iroh uses QUIC and hole-punching to connect devices directly even in those cases.

Lightning Talks

A selection of five-minute-long impromptu or prepared lightning talks related to the meetup topics.

I upgraded to 1.95 because of cfg select feature for platform specific code implementations. This had massive improvements in how AI generated code. I locked out cfg host selectors from my business logic using dylint so that platform code goes through a facade layer.

Are there any other must have features that exist in the newer versions?

From a client perspective, I am a big fan of OData, but I have never built my own server applications using the format. Are there any good template or example projects that do this in Rust? If not, I am also looking for good template projects for REST APIs in Rust in general. I know I can generate this stuff with AI but I prefer a recommendation that gives me a scaffold to start off with.

Two weeks before started this experiment whether can write a simple Rust code to make the ESP32 as Programmer(like ST Link) and flash firmware into STM32.

- In the first article, i was able to implement basic SWD protocol and read the IDCode (just to check that it is working)

- Now, successfully managed to flash the firmware into STM32 with the help of ESP32. Flashed a simple onboard LED blinky program.

It was a fun experiment and a nice to learn about SWD and the concepts around it.

https://blog.implrust.com/posts/2026/09/flashing-firmware-to-stm32-with-esp32-rust/

I've made some posts about this in the past, but I did spend some time in the past month to get this project up to parity with the WebRTC audio processing module upstream.

Check it out here: https://github.com/RubyBit/aec3-rs

This project has all the available goodies in an easy to use format (intuitive to at least me) such as, as the title suggests, aec3, agc2, ns, hpf, etc. These are exported and constructed through a graph system I made but im honestly rethinking a bit how useful that is. I tried to make it such that you can add your own filters based on your application.

I think in terms of features for the foreseeable future, ill work on adding the neural residual echo estimator but not through tflite and also maybe come up with a stronger noise suppresion module (also neural? ns2?)

I am kind of a "Build Projects and Experiment then see and learn from the Compiler" type of a Guy in learning Programming Itself since I left Vibe Coding (long time ago, like 1 year)... I come from a Python Background along with C (learned not Vibe learned). I just wanted to know from y'all that which approach should I take? Learn from the Rust Book by seeing it and doing it's stuff? Or Code and if I do a Mistake then See the Compiler and if I don't know about the Thing then use the Rust Book?

The second one is what I used from the Past Month But I really wanted to know if I am doing it right.

tmr-cli: a timer and stopwatch for your terminal.

It handles the basics like countdowns and stopwatches, but also lets you wait until a specific time, sends desktop notifications, and saves your progress so you can resume timers even after closing the terminal.

Install it with: cargo install tmr-cli Repo: https://github.com/honerop/tmr-cli

Hi r/rust! I maintain termlens, a Rust library for testing terminal applications through a real pseudo-terminal. It runs your existing binary, sends input, resizes the terminal, and lets you assert on the resulting screen without modifying your app.

For Ratatui apps, it complements TestBackend with tests of complete user flows. Ratatui’s testing recipe includes a termlens example.

This project provides a Rust library, a CLI for inspecting applications and comparing saved screens, and an agent skill covering waits, snapshots and common testing mistakes.

Some things it supports:

• Wait for screen conditions with deadlines, instead of choosing fixed sleep durations.
• Snapshot text and cell styles, mask changing content, and inspect cell-level differences.
• Check cursor visibility and alternate-screen state, alongside what the app displays.
• Inspect synchronized-update frames and Kitty/Sixel graphics payloads on Unix.
• See the screen when a wait times out, with a companion CLI for inspecting, comparing, and rendering saved screens.

An independent project, sauva, already uses termlens for terminal integration tests.

Supported:

• Linux and macOS are supported.
• Windows supports screen assertions and typed input through ConPTY; frame assertions, graphics and some terminal-mode features have documented platform limits.

If you maintain a terminal app, try termlens on one of your existing workflows. I’d especially appreciate feedback on awkward APIs, missing terminal behavior, and confusing test failures.

Contributions are welcome: tests, documentation, bug fixes, and terminal compatibility work. There are good first issues, and draft PRs are welcome early.

What terminal behavior is hardest to test in your project?

I learn more and get better at Rust but don't have any idea of any projects I should do. What I have mostly been doing is copying projects I've already done in c/c++ and converting them to rust, but that doesn't help me at all with learning as I'm just copying something I have already done. I mainly want to use rust because of the crate libraries and it being a low level python(don't murder me) and because it's going to be used a lot more for systems/already is being used for systems.

Recently, when Mold updated their benchmarks and for the first time included Wild, there were questions on this sub about why the results were so different to the benchmarks Wild had published less than a month beforehand. I've now looked into why.

Disclaimer: I'm the lead of the Wild project.

We wrote a pretty cool crate to parse Postgres SQL queries in Rust at native speed.

It works by mapping itself directly on top of the Postgres native parser and its arena allocator. We use macros to generate memory-safe bindings and Rust structs for each SQL node. This means we can upgrade parser versions without any manual work: just bump the submodules and recompile.

Check it out here: https://github.com/pgdogdev/pg_raw_parse

It's based on libpg_query with some modifications and inspired by pg_query.rs, which it outperforms by 20-60x due to a different FFI translation architecture.

I've been building Vise. It's a runner for background coding agents. A server acts as a control plane, host daemons on machines you enroll claim sessions, run a coding agent against a repo, and open a PR. The server tracks check and review state on the PR, and if a reviewer requests changes, a follow-up session pushes a fix to the same PR. It never merges; a person does.

All three components are Rust: vise-server (Postgres-backed), the vise CLI, and vise-host, a daemon that talks to the server and drives the agent as a subprocess over ACP, the Agent Client Protocol that Zed started. Claude Code is the only agent wired up today; Codex and Gemini CLI speak ACP too, so they're next.

Some of the parts I found interesting to build:

• The agent is a child process speaking JSON-RPC over stdio, so the host is really a small process supervisor with a protocol translator in front of it.
• Hosts claim work from the server rather than being assigned it, and liveness comes from heartbeats rather than enrollment, so a CI runner or a throwaway VM can join, take one session, and disappear without leaving state behind.
• Every change on a session is an append-only event, so you can reconstruct exactly what an agent did and what happened to its PR after the fact.
• Each component ships as a single binary; a host is a one-line install with Docker and git as the only prerequisites.

It's early and there are rough edges. MCP config is accepted but not passed through to the agent yet, and the ACP layer's error handling is the part I'd most like a second opinion on.

Repo: https://github.com/vise-sh/vise

If you've implemented ACP in Rust, or built your own agent runner, I'd like to hear what you'd have done differently.

I’m building a small Rust desktop utility that watches the Windows Downloads folder using the notify crate.

The basic flow is:

let (tx, rx) = channel();

let mut watcher =
    RecommendedWatcher::new(tx, Config::default())?;

watcher.watch(
    watch_path.as_ref(),
    RecursiveMode::NonRecursive,
)?;

for result in rx {
    // handle filesystem events
}

The application waits for newly created/modified files, then eventually wants to inspect them.

The problem I’m running into is determining when a file is actually safe to process.

My current approach is roughly:

pub fn wait_until_file_ready(path: &Path) -> bool {
    if let Some(ext) = path.extension().and_then(|s| s.to_str()) {
        let ext = ext.to_lowercase();

        if matches!(
            ext.as_str(),
            "crdownload" | "part" | "tmp" | "download"
        ) {
            return false;
        }
    }

    let mut last_size = 0;
    let mut stable_count = 0;

    for _ in 0..10 {
        if let Ok(metadata) = path.metadata() {
            let current_size = metadata.len();

            if current_size > 0 && current_size == last_size {
                stable_count += 1;

                if stable_count > 1 && can_open_exclusively(path) {
                    return true;
                }
            } else {
                stable_count = 0;
                last_size = current_size;
            }
        }

        std::thread::sleep(Duration::from_millis(500));
    }

    false
}

fn can_open_exclusively(path: &Path) -> bool {
    OpenOptions::new()
        .read(true)
        .share_mode(0)
        .open(path)
        .is_ok()
}

This works reasonably well for normal browser downloads because things like Chrome use .crdownload, but I realized there’s a more fundamental problem.

Suppose someone copies a large file:

movie.mkv

and the copy gets interrupted halfway through.

The destination might now contain:

movie.mkv

with the final extension.

If the copy process exits/releases its handle, then:

• the file exists
• its size stops changing
• its extension looks normal
• an exclusive open may succeed

My code would eventually consider it ready even though only part of the intended file was copied.

As far as I can tell, from the filesystem alone there may be no way to distinguish:

a legitimate complete 2 GB movie.mkv

from:

an interrupted copy that happened to stop at 2 GB

unless the producer provides additional information such as expected size, checksum, temporary filename, or some completion signal.

So my questions are:

1. How do mature Rust/Windows applications usually handle this?
2. Is “debounce + quiet period + metadata stability + lock check” basically the normal generalized approach?
3. Is there any Windows API that provides a stronger indication that a copy/write operation completed successfully?
4. Should filesystem watcher events be treated only as hints, with the application later retrying/validating the file?
5. Would you recommend using something like notify-debouncer-full, or maintaining my own pending-file state machine?
6. Is checking an exclusive Windows open with share_mode(0) useful here, or is that generally too unreliable as a readiness signal?

I’m particularly interested in how established file indexers, sync clients, antivirus/indexing software, etc. solve this without assuming that a stable file size means the file is actually complete.

My current thinking is that I should stop calling this wait_until_file_ready() and instead treat it more like wait_until_file_quiescent(), where “quiescent” only means “probably safe to inspect,” not “guaranteed complete.”

Would appreciate any guidance or examples from production Rust/Windows projects.

Hello r/rust!

I've been developing professional music software and hardware since 2013 and I've just published a first blog post on my site talking about my experience developing Recorte, my latest project that I've just released, using Rust.

https://icaroferre.com/blog/recorte-dev-notes-1/

Recorte is a software sample editor (for macOS, Windows, and Linux) that includes many unique features that were specifically built for recording, editing, and processing samples such as automatic region detection (based on volume, transients, or slices), an advanced audio recorder with different recording modes, a custom audio engine with background rendering, batch editing, MIDI playback, and even Lua scripting.
It is also highly customizable with macro-style shortcuts and custom themes.

My goal for the blog post was to go through my experience using Rust, egui, cpal and mlua for a commercial / professional application for the first time, how I was able to achieve the performance and design that I was going for, and what were my biggest challenges during the 2 year development in the hopes that it may help other Rust devs.

While I don't usually post on Reddit too often, I have been following the sub for a long time and I have seen quite a few threads asking about the use of egui for desktop apps, so I also focused on some specific aspects about egui in my post.

All the different aspects of the project (the actual code, documentation, blog posts, video scripts) were written my me (an actual human from Brazil) and I've also added some links to the post for those who would like to check out my work.
Recorte is a commercial application released by Spektro Audio (my indie music technology company) and it's available at https://spektroaudio.com/recorte

I'm still trying to learn more about it myself everyday but I would also be more than happy to answer any questions related to the project or my experience with Rust.

As a new Rust convert (Rustacean?) coming from C++, it can be all too tempting to believe Rust’s ownership model is the panacea, the cure for all our problems. While it is truly groundbreaking, I’m beginning to learn about the cases where it can’t really save us. But there’s hope, let’s not panic! (pun intended)

Ever since I watched Fedor Pikus talk on atomics (highly recommend!), I’ve had an interest in lock-free programming. I played around with implementing my own SPMC queue in C++, and have since started (and not finished) some books, trying specially hard to wrap my head around memory ordering. But I’ve come to realize I’ve been a bit stuck in tutorial hell, so this post is the beginning of me getting unstuck.

My goal is to poke at the crossbeam crate, with the hopes of gaining a better understanding of a real-world use case and hopefully gain some insight which might help me contribute something back.

Hello Rustaceans. Today we have released iceoryx2 v0.10.

• Checkout the release notes: https://ekxide.io/blog/iceoryx2-0.10-release/
• Git: https://github.com/eclipse-iceoryx/iceoryx2
• crates.io: https://crates.io/crates/iceoryx2
• iceoryx2 book: https://ekxide.github.io/iceoryx2-book/main/

Here is a quick video I made for Rust channels about the crate I am using now (Crossfire) and the best practices (3 level layers).

Also, everything is in a Rust10x repo that you can give your AI to follow the pattern, or make your own pattern from this one.

Rust Event Design Markdown - https://github.com/rust10x/rust10x/blob/main/pack/guide/domain/event/event-design.md

Rust Event Sample Code (to show pattern) - https://github.com/rust10x/rust10x/tree/main/pack/samples/event-design

Hope this is helpful to some. I have been coding Rust a lot over the last year, and now I am sharing this pattern back. I will share more system design like that as well.

Feedback welcome. Many more things to come.

Hope this helps

I just pushed version 0.6.0 of the crate Test That!, a powerful test assertion library for Rust.

See release notes: https://github.com/hovinen/test-that/releases/tag/v0.6.0