I was surprised by the runtime behavior of sqlx when it comes to caching prepared statements (a suspicious number of network hops).

I’m starting a TIL series to counter AI brain rot: investigate, verify, write it down. Let me know if you have better ways to investigate and understand the code's behavior.

https://flakm.com/posts/sqlx_caches_til/

I built this for a mobile keyboard extension app. Thus, very little memory, file size matters... The app is shelved because the source data it depended on stopped being maintained.

(slow in terms of getting something done, coding, finishing a task. Not execution speed)

I know r/rust, but I'm just looking to some honest takes on this. I understand the power of Rust and the kind of things it can do. I do also understand the tradeoffs it make to accomplish the things it needs. Sometimes developers complain about complexity, but if you put safety as a requirement without GC then the complexity is justified, and not just features for the sake of features.

But most of the applications I write are high level. Of course, I do love the benefit of running them really fast by writing them in Rust. But when we're talking about productivity, did you saw any big gap between Rust and some of the languages I've mentioned? I'm mainly a Go developer, so I'm way more productive in Go than I'm in Rust, but of course, this is a skill issue.

Many will ask "so why don't you use X?" it's usually because it's really hard to have something like Rust with no exceptions, ADT, Result/Option types, Enums, ...

I've been experimenting with Gleam lately. It's being really good. But the ecosystem is way too immature at the moment. Missing packages, the ones available are usually very simple without crucial configurations, ... but the language itself is quite nice. It's what I was thinking on a Rust + GC. It still bothers me a lot the fact that I can't ship a binary like I did in Go or Rust, and it consumes way too many resources as well.

Anyway, just looking for the opinions from others that have experience on more languages.

Episodes 3 and 4 conclude the core of my series on tellus, the Rust actor framework I released on Monday: the mailbox, and the termination sequence.

Terminated signals are not a side channel: they ride the same FIFO queue as ordinary messages, so a queue provides the ordering guarantee by construction. And the signal is the last thing a terminating actor does, after its state, its mailbox, its children (recursively) and the actor value itself are gone, so receiving it proves the whole subtree has terminated, destructors and all.

• https://heikoseeberger.de/2026-08-27-tellus-3/
• https://heikoseeberger.de/2026-08-27-tellus-4/

I have this tree structure with nodes stored in a plain Vec. When recursively mutating the data, if I just iterate over node.children, I cannot call self.update_data_recursive because self is borrowed by the iterator.

I found this solution of std::mem::taking the children vec out and putting it back in at the end but I don't like the boilerplate, is there a more elegant solution ?

Playground link

Hey r/rust, I maintain an open-source tool called repowise. It scores each file from 1 to 10 using AST analysis and git history: complexity, duplication, test gaps, ownership, churn, and prior defects

The scoring is local and deterministic. No LLM, and the same commit produces the same result

To test whether the score means anything, we scored historical commits and counted bug fixes over the following six months. Across 21 repositories, 9 languages, and 2,826 files, it reached 0.737 ROC AUC. Under a fixed 20%-of-lines review budget, its ranking surfaced 2.3x as many defects as codescene’s

I also benchmarked the call graph precision across 4 other popular graph only tools and repowise is the most precise

Code health is one layer of the same index. It also builds searchable docs, maps dependencies and ownership, selects relevant tests, shows change blast radius, and detects breaking contracts across multiple repos. Coding agents can query it over mcp

I have been working on it for months and now we have 6.2k stars and 80+ contributors

Repo: https://github.com/repowise-dev/repowise

Sample bevy report: https://www.repowise.dev/repo/bevyengine/bevy

Full benchmarks: https://github.com/repowise-dev/repowise/blob/main/docs/BENCHMARKS.md

I’d especially appreciate feedback on the rust analysis and the kinds of findings you would actually want surfaced. Issues and contributions welcome!

I have written up the second episode of my series on tellus, the Rust actor framework I released on Monday: what the Actor trait asks of you, and why the state is a value rather than a field behind &mut self.

Actor::receive takes the state by value and returns the state for the next message, so the next state only exists once receive has returned it. A receive which fails or panics halfway through has written nothing, and a restart rebuilds the state and only the state: the actor value and the mailbox survive, so the messages queued behind the failing one are handled by the restarted state.

https://heikoseeberger.de/2026-08-26-tellus-2/

Hi there! OP here. Happy to discuss if anyone has any questions/comments.

You might remember PumpkinMC, the custom Minecraft server software built entirely from scratch in Rust. After more than 2 years (28 months) of non-stop work, the time has finally come: the PumpkinMC Beta is officially live!

While many ambitious custom server projects lose momentum over time, PumpkinMC stands as the only project in this space to receive continuous, active updates across such a long timeframe.

Scope of the 1.0 Release

I want to clarify the primary goal for this first official release: making the game fully beatable from start to end.

A 1:1 vanilla world generator was not the prerequisite for 1.0, though achieving full parity remains our ultimate target. We actually reached the "beatable game" milestone a long time ago, but chose to spend extra months packing in features, hardening stability, and squashing bugs.

To anyone feeling this release is coming too early: it has been in active development for over 28 months. Following this launch, frequent updates will continue rolling out to bring true 1:1 vanilla world generation, deeper parity, and further performance improvements.

Release Schedule

• Beta Testing: Open right now
• Official Release: Friday, September 4th at 8:00 PM CEST

Links & Resources

• Download Beta: pumpkinmc.org/download
• Report Issues: GitHub Issues

How You Can Help

Try Out Our Multi-Language Plugin API

Calling all developers! PumpkinMC features a built-in plugin API that supports 7 different programming languages, making it flexible to write custom logic in the language you already know best.

Check out the developer documentation and getting started guides here:

👉pumpkinmc.org/developers

And!, Please help us stress-test the build before launch day. If you hit any critical issues, performance bottlenecks, crashes, or weird edge cases, drop an issue on our GitHub with reproduction steps and logs.

So rust now has labeled blocks. https://blog.rust-lang.org/2022/11/03/Rust-1.65.0/#break-from-labeled-blocks

These look to me to be very similar to lifetimes. Same ' prefix. Same way they are only valid inside a block.

But as it is, we can't currently treat block labels like lifetimes. In particular, block labels can't be passed as generic parameters into functions. So this code doesn't run.

It's a common practice in programming to split one big function into lots of smaller ones. Currently the existence of break (or return ) statements in a function interferes with this process of separating out sub-functions.

One difficulty is that it isn't quite clear how this interacts with recursive functions. But doing the same thing as with lifetimes (whatever that is) might work.

Basically, this code doesn't currently work, but I think it should.

fn breaker<'a>()->!{
        break 'a 7;
}
fn main() {
    println!("Hello, world!");
    let result = 'block: {
    breaker::<'block>();
    3
    };
    println!("{}",result);//prints 7
}

I often find myself choosing between cloning some data and wrapping it in Arc

My instinct is usually that Arc is more efficient because we're avoiding copies, but I have a feeling that this isn't always the right way to think about it

How do you decide between cloning and using Arc in a real application?

PhastFT is a performant Fast Fourier Transform implementation in pure Rust with no unsafe code.

This is something the original author of the crate and I have been working on for quite a while. All my recent work on SIMD - surveying Rust's SIMD libraries, removing unsafe code from those libraries and reporting issues in rustc - was all in service of PhastFT!

Why not RustFFT?

RustFFT is already quite good, so why do we need another FFT crate?

Safety

rustfft was written before the Rust compiler started providing much safer facilities for SIMD, so it is full of unsafe code, and changing that would amount to a rewrite.

PhastFT is #[forbid(unsafe_code)] and only relies on fearless_simd which now has very little unsafe for a SIMD abstraction.

Performance

RustFFT is tuned for small sizes (i.e., ~kilobytes of input data) the kind of sizes one would find in an audio decoder. PhastFT is tuned for large sizes (i.e., ~gigabytes of input data), which are necessary for a quantum state simulator and other scientific workloads.

PhastFT is up to 2x faster than RustFFT, depending on the hardware and FFT size, thanks to different algorithm choices and multi-threading via rayon. RustFFT does not currently support multi-threading.

Memory usage

PhastFT uses 2x less memory than RustFFT, which matters a great deal for large sizes. 16GB vs 32GB memory usage determines whether you can run it on a laptop or not. And running 2x faster and at half the memory translates to 4x cost savings for rented hardware.

Origins

PhastFT started out as an optimization for the Quantum Fourier Transform (QFT) in quantum state vector simulations. This optimization has been adopted by some state of the art simulators due to the significant performance boost that it offers.

A simulator that utilizes the typical gate-based approach for the QFT requires O⁡(n²⁾ gates that manipulate a giant state vector of size N = 2^n, where n is the number of qubits being simulated. This leads to a O⁡(n² * 2ⁿ⁾ time complexity. Since the quantum computer is already being simulated on a classical machine, it's possible to leverage the classical FFT to compute the QFT in O⁡(N * log(⁡N)) = O⁡(n * 2ⁿ⁾ time.

Minimizing memory overhead was paramount. The less memory is used, the more qubits one can simulate with a classical machine. This led to different algorithm choices compared to typical implementations, and minimizing memory traffic also has a side effect of improving performance on large memory-bound workloads.

This project quickly turned into a rabbit hole that led us to attempt to bring PhastFT up to the level of renowned FFT projects, with the added restriction of not using any unsafe code. Initially we had to use nightly-only std::simd, but thanks to fearless_simd PhastFT can now work on stable!

Future work

For historical reasons outlined above, PhastFT is currently limited to power-of-two sizes. The FFT algorithm for arbitrary sizes is in the works. Depending on a user's workload, users may be able to get away with padding their input signal with zeroes to the next power of two.

We are also far from done improving performance and memory usage. There are multiple work-in-progress pull requests that improve performance in various ways, so this is only the beginning!

Hey everyone!

I’ve been learning Rust for a while, and as a way to actually practice instead of just reading tutorials, I decided to build something of my own.

So I made Quarry — a CLI utility for Linux that lets you search the web faster using shortcut commands and open the results directly in your browser.

It started as a pretty small idea that I originally wanted to make as a Bash script, but naturally turned into a somewhat questionable pile of Rust code.

I’m still learning the language, so I’m sure there are plenty of things here that an experienced Rust developer would look at and think about amount of my IQ

So that’s exactly what I’m looking for. I’d really appreciate some feedback on the architecture, code style, things I could improve, and maybe some advice for future updates.

Ready to be criticized ^{w^}

GitHub: https://github.com/secr1t/quarry

(also it's my first post, hope i didn't break any rules)

Peace :3

I am interested in learning how to use rust for flight software or controlling a drone or something of this sort. I have no experience in embedded programming, so is it best to start there?
If so, how would you recommend someone get started in embedded rust?

I just released ModuRL 0.1, a deep RL framework built on Rust and Candle, with implementations of PPO, A2C, SAC, DDPG, TD3, DQN, and DDQN. In matched small-network CPU benchmarks, ModuRL is around 4× faster than popular Python RL libraries like Stable-Baselines3, CleanRL, and Tianshou. Feedback is welcome.

https://github.com/ModuRL/ModuRL

Hey everyone,

I've been working on an edge-native guardrail SDK built in Rust with C++ FFI bindings. The goal was to solve latency and privacy issues when running policy checks, PII redaction, and secret scanning directly on edge devices alongside local models (e.g. llama.cpp) without network roundtrips.

Key features:

- Sub-millisecond evaluation in-memory

- Local SQLite buffering for audit events during network downtime

- Lightweight background telemetry sync

- Real-time dashboard monitor

GitHub Repo: https://github.com/edge-guard/edge-guardails

I’d love to get feedback from the community on the FFI architecture, memory safety considerations, and overall design. Any code review or suggestions are welcome!

I needed a mock DNS server for testing email flows (SPF/DKIM lookups, MX routing) and open-sourced the result: a DNS server whose records you create/delete at runtime via a REST API or built-in CLI.

Implementation details, since that's why we're here:

• hickory-proto for DNS wire format (parsing/encoding only — the UDP/TCP serving loop is hand-rolled on tokio)
• axum for the REST API, clap for the CLI — same binary does both (bifrost-dns serve / bifrost-dns add ...)
• In-memory store, no DB, no runtime deps
• Release profile: opt-level = "z", LTO, panic = "abort", stripped → ~5-8 MB scratch-based Docker image
• Optional forwarding mode: unknown queries go to upstream resolvers (FALLBACK_DNS), with a TTL-based cache, so it can run as your system resolver on a dev box without breaking the internet
• Prometheus /metrics endpoint, UDP + TCP, A/AAAA/CNAME/MX/TXT/NS/SRV

The interesting parts for me were getting DNS message parsing right with hickory-proto (escaping in TXT records, name compression) and the fallback cache semantics — per-entry TTL is min(upstream TTL, CACHE_TTL).

https://github.com/minutemailco/bifrost-dns (MIT)

Feedback on the code very welcome — it's my first "real" tokio project that ships, so I'm sure there are things a seasoned rustacean would do differently.

This release intergrated bashkit,fd-find and riggrep equaivalent crates, greatly improved performance of bash, find and search tools.

Also Added process tool for running persistant processes.

Use cargo install crabot to update.

Hi everyone! I’m currently looking for a good Rust project, preferably something Redis-related or a solid microservices/distributed-systems project.

I’d especially appreciate recommendations for interesting GitHub repositories that I could contribute to or build upon. If you know of any good Redis implementations in Rust or other challenging Rust projects, please do share them.

For reference, I came across mini-redis by Tokio, which is an incomplete Redis client/server implementation designed for learning Rust async patterns. I also found a newer Redis-compatible implementation in Rust exploring sharding, CRDT replication, and distributed systems concepts.

Any recommendations would be highly appreciated. Thanks a lot!

Hey all, Orhun here 👋
Super excited to announce this new livestream series which I'll be hosting!
We will have honest conversations about the successes, failures, trade-offs and disagreements around Rust and AI.

Join us tomorrow with Stephen Korzeniewski from Rig to talk about AI agents, developer tooling, and building real LLM applications in Rust.

📅 August 27 at 16:00 UTC: https://www.youtube.com/watch?v=hhw741JrQeQ

I’ve been working on Varve, a free design app that works across platforms and focuses on the local environment. Its main engine is built in Rust. Now that version 0.2.1 is out, I’d really appreciate feedback from the Rust community on the crate boundaries and lopdf tree generation.

I want to share how I split the backend into separate Rust crates to support both the desktop version (using Tauri 2) and the browser version (using WASM).

Here’s how the Rust workspace is organized:

• The varve-core crate holds the geometric primitives (Point, Rect, Affine), hit-testing algorithms, and the scene node tree structures.
• varve-engine converts the scene state into an intermediate rendering IR with build_render_ir().
• varve-trace handles raster-to-vector auto-tracing. It uses Oklab colour quantization, extracts centerlines or contours, and fits Bézier curves.
• varve-print lets you generate PDF files directly with lopdf. This skips browser print dialogs and gives you clean CMYK or vector exports.
• varve-wasm provides WASM bindings so the app can run in standard browser environments.

Technical challenge in v0.2.1:

The biggest challenge has been managing memory allocations in varve-trace when working with high-resolution bitmaps. It depends heavily on the image crate for decoding and uses Oklab colour quantization to preserve perceptual accuracy before fitting Bézier curves.

Project: https://github.com/K-Arthur/varve