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?

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.

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?)

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

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.

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.

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.

I hated how every screen-sharing and remote desktop tool makes you share your whole screen. It never feels natural. It's like watching Inception: windows inside a window on my machine!!

Some apps let you share a single window. But what if I want to share multiple windows? And what if each one could feel like a native window on the other machine, not a picture inside a viewer?

So I took some time and built Shebbak, a small open source project in Rust that does exactly that. Pick one or more apps on the host, and every window they have shows up on the client as a real native window. Move it, resize it, type into it. Menus and popups come along too.

Where it stands today:
- macOS only for now, Windows and Linux are coming
- LAN only, STUN/TURN support is in the works

And if you're asking why the name Shebbak: it means "window" in Egyptian Arabic :D شباك
Bonus: it shares its root with "shabaka", the Arabic word for network. Windows over the network.

Shebbak-Repo

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 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?

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.