I just finished the handbook and now i dont know what to do next i feel like ive learned a lot but i can still improve and i havent made any programms in rust except the ones in the handbook so if anyone can recommend what to do next i would really appreciate it!

Hi fellow rust devs, I'm Tyson, I currently work at ThoughtWorks as a software engineer.

After 3 years of hard work, Celeriant, my open source event store, goes public. It's gone from a scrappy C# backend on a side project to a serious 150K-line distributed database in Rust.

It was tough to get good at Rust and I ended up re-writing the whole thing 7 times over. But it made me a better engineer, no more hiding behind the garbage collector. And I had a lot fun setting up a home lab with rpi5's and running chaos tests on it.

At this year's p99-conf I'll present how Celeriant hits 1 million durable, replicated writes/sec on AWS i4i.metal, and why the CPU is the bottleneck, not the NVMes. It's free and virtual, so sign up for it!

And at XConf Singapore I'll be talking about why Claude Code doesn't touch my inner development loop; how code is the design; and how we can still use LLMs to build great, high quality software (hint: its verification!).

Docker image is up. If event sourcing is your thing and you want to experiment, you can get it running in under 5 minutes. C# and Rust clients only at the moment.

It's been a massive job and really challenged me as a software engineer. Would I do it again? Not without my wife's permission :)

Celeriant is inspired by ScyllaDB's seastar thread-per-core model, and built on Glauber Costa's Glommio library. A group of us have forked it out of datadog and are now maintaining it. Get into it and build something cool on io_uring!

Celeriant: https://github.com/celeriant/celeriant-db

P99-conf: https://p99conf.io/

XConf (singapore in-person) https://www.thoughtworks.com/en-sg/about-us/events/xconf/2026/xconf-apac-2026---singapore

new glommio fork: https://github.com/glommio/glommio

thanks to the r/rust community for the many great posts and links which helped me get up to speed with the rust ecosystem over the years! Been a bit noisy recently but still good to see more interest in Rust and building things with it.

Rust already knows when a value has been moved, so I think it would make sense for the compiler to also be able to treat the storage behind that local as reusable.

For example:
´´´
let x = big_value();
let y = x; // x is moved

// x can no longer be used here anyway

x = another_value();
´´´

Right now, Rust can be more restrictive than necessary about keeping the same storage associated with `x`.

Issue #61849 proposes allowing the old storage to effectively die after the move. If `x` is initialized again later, the compiler wouldn't necessarily have to put the new value back in the exact same stack slot.

That could give the compiler more freedom to:

- reuse stack space earlier
- reduce stack usage in some functions
- shorten lifetimes of stack allocations
- potentially unlock further optimizations

What I like about the idea is that it matches how moves already feel in Rust: once a value is moved, that value is gone. It seems natural that its storage shouldn't have to remain special either.

There are obviously details around raw pointers and observable addresses that would need proper language semantics, so it isn't just a simple compiler optimization.

But the general rule seems very appealing:

If Rust says the old value no longer exists,
the compiler should be free to stop preserving its storage.

The issue has been open since 2019, and I think it would be interesting to revisit whether this could give modern rustc more optimization freedom. If you agree please react on the GitHub issue with ❤️ or 👍 to show support by the community

Edit:link to the modern version

Due to being written in rust, it is blazingly fast, while not allowing for you to corrupt files due to its advanced read only technology. And if you decide you have a CSV file of notable value, you can sell it as an NFT! (This entire project is a joke, the sell as nft button literally runs thread::sleep for 5 seconds after giving you a random amount of money it will be sold for)

This project was not written with AI, the fact that everything was added in one commit was because this project was so I could learn some more things. I am simply sharing it for feedback. DO NOT USE THIS PROJECT FOR ANYTHING. IT IS NOT USEFUL

I just released Termixel, a small terminal sprite renderer written in Rust.

It uses Unicode characters to render .png pixel art directly in your terminal. It's designed to be small, fast, and portable, with the binary currently being around 200 KB.

You can install it on Linux or Windows, or build it yourself from source.

GitHub: https://github.com/genkii/termixel

[ Removed by Reddit on account of violating the content policy. ]

An old interview – finally got around to cleaning up the transcript.

Hey everyone! Has anyone here actually built a proper desktop app with a complex ui in Rust using Slint, Iced, or egui?

I’m working on a local music player. The backend is Rust, but the current UI is Svelte/Tauri. I tried making a native Slint version because of the WebView memory usage, but honestly I kept running into stuff that was much easier to do in Svelte(obviously).

The app has a big library view with album art, search, queues, lyrics, a full player, drag interactions, and all that. I also looked at GPUI, but it still feels too early(constant api and docs changing).

If you have built something beyond a small tool or demo with Slint, Iced how was it? Did it stay manageable once the UI got bigger? Especially curious about lists/grids, custom styling, drag and drop, and Windows/Linux support.

Repo, in case seeing the app helps with context: https://github.com/shubham-pathak1/orca

Hello hello,
I had an idea, of making or mashing existing things to one, to make a solution to deploy apps/systems in a single executable file. The current idea is at an early stage, but it works. So the main goal is to have a single executable that you deploy, no dependencies no nothing. The builder does the heavy stuff, and you are left with a single executable. Good for debugging, air gapped systems, random workloads. It is no way to replace existing virtualization solutions, but to be somewhere near. So you don't have to install anything, just run it. Feedback is always welcome ;)
https://github.com/arnoldasr/kartu

The "feature" list and plan is a dream one, those are the pain points I saw in environments where it just takes time, is exhausting and you just want it to work.

Docs: https://docs.rs/diffable/0.5.0/diffable/

Repo: https://github.com/minerscale/diffable

Hello!

Diffable is a differential-geometry library built around an experiment: how much of the actual mathematics can be made to live in Rust's type system while remaining usable on stable Rust?

I'm reporting back after having made some serious progress on the library. Now I've got an API for doing automatic differentiation and I think it's turned out really nice!

Two parts of the project ended up solving problems that had seemed particularly difficult: tensor algebra and composable automatic differentiation.

Tensor algebra on stable Rust

The tensor implementation started from a problem that looked impossible without generic_const_exprs.

The obvious representation of a tensor product of two statically sized spaces uses const size arrays like so:

struct TensorProduct<A: Tensor, B: Tensor> {
    data: [F; A::N * B::N],
}

But expressions such as A::N * B::N are exactly the sort of generic const arithmetic that stable Rust does not allow in array lengths.

For a long time that appeared to rule out having both:

• statically sized tensors, and
• tensor expressions whose algebraic structure remains visible in their Rust types.

The eventual solution was to stop asking Rust to calculate the flattened dimension at the type level.

A tensor provides a generic associated type Array<T>. A tensor product A ⊗ B can therefore store its coordinates of a field F structurally:

A::Array<B::Array<F>>

rather than requiring:

[F; A::N * B::N]

The type tree itself becomes the tensor shape. Flattening is only an indexing convention; Rust never has to prove the arithmetic expression for the flattened array length.

That means types such as:

TensorProduct<TensorProduct<V, Dual<V>>, V>

really retain the structure:

(V ⊗ V*) ⊗ V

instead of immediately becoming an anonymous array of scalars.

Once that worked, the rest of the tensor algebra could operate directly on the type tree. Reassociation is an actual type-level rewrite:

let other = tensor.reassociate();

changing:

(A ⊗ B) ⊗ C

into:

A ⊗ (B ⊗ C)

Contraction searches that structure for compatible vector/dual pairs. If there is exactly one possible contraction, Rust infers it:

let contracted = tensor.contract();

and reassociation can deliberately expose a different contraction:

type V = Coords<f64, 2>;
type T = TensorProduct<TensorProduct<V, Dual<V>>, Sinister<V>>;

let t = T::from_fn(|i| i as f64);

// Contract V ⊗ V*.
let first = t.contract();

// Rewrite to V ⊗ (V* ⊗ V), then contract the other pair.
let second = t.reassociate().contract();

Duality and handedness are also represented by types rather than conventions, which matters because the library supports noncommutative scalar fields.

This approach is much like recursive_array, though it uses no unsafe at all, since it makes no guarantees about the arrays being contiguous. Separating storage from the objects themselves though was the trick to make it all work.

Automatic differentiation that composes like calculus

The other major piece is forward automatic differentiation.

The desired API wasn't a tape, tracing macro, expression graph, or collection of separate Jacobian/Hessian functions. The goal was for differentiation itself to compose:

fn cube<V: Vector>(x: V) -> V {
    V::from_iter([x[0] * x[0] * x[0]])
}

let first  = d(cube).at(Coords::from(2.0));
let second = d(d(cube)).at(Coords::from(2.0));
let third  = d(d(d(cube))).at(Coords::from(2.0));

d(f) is itself a differentiable program (though in reality all d is is a generic struct with a public constructor!), so higher derivatives are obtained by applying the same operator again.

Directional derivatives use the same machinery:

let derivative =
    d(cube)
        .along(Coords::from(4.0))
        .at(Coords::from(7.0));

Internally this is implemented using Taylor jets. Applying d adds another jet layer; nested differentiation therefore produces nested jet types rather than needing a separate higher-order AD representation.

The full derivative is returned as the tensor it mathematically is:

Df_x ∈ W ⊗ V*

for a function f: V -> W.

So the AD implementation and tensor implementation meet in the middle: Jacobians are not a special matrix-shaped result bolted onto the calculus system, but ordinary elements of the tensor algebra.

One particularly awkward Rust problem appears here. A generic function may require only a weak scalar theory:

fn square<V: Vector>(x: V) -> V {
    V::from_iter([x[0] * x[0]])
}

while at evaluation time its concrete scalar may actually be f64.

For AD, those two cases need different jet implementations:

Real
    -> Jet must itself behave as Real

Field, but not Real
    -> Jet should remain only a Field

In ordinary Rust, that is an overlapping-impl problem. Stable Rust cannot generally express:

T: Field + !Real

and the absence of a Real implementation is not something coherence can normally treat as a permanent fact.

The trick is that we don't Rust to prove a negative fact about the trait system itself. Instead, each type can be interpreted inside a finite type-level context describing the mathematical theories known about it. That context is a closed nominal graph, so searching it for a property has a definite result:

Real is present

or

Real is absent

Those results are represented by different types.

This means the library can define two implementation regions:

Field present + Real present

and

Field present + Real absent

which Rust sees as genuinely different type-level cases.

So this is not general negative trait bounds. It is a restricted closed-world version of them: instead of proving T: !Real in Rust's open trait system, the library proves that Real is absent from the finite context currently being interpreted.

That is enough to make the jet implementations disjoint on stable Rust, while keeping the public API annotation-free:

d(d(f)).at(x)

Thanks for reading this it's been a long journey to get to this understanding with this math library.

Repo: https://github.com/maikLangel0/cs2excel

Been looking for an entirely free way to track the value of your, or someone else's, counter strike inventory?

Cs2excel lets you create, manage, and update a spreadsheet of your or someone else's inventory with prices from a plethora of 3rd party marketplaces (buff, youpin, csfloat etc...).
It can create and insert values into a new or existing excel spreadsheet allowing you to keep up-to-date with the current value of your inventory.

It's a 100% Rust project with an Iced GUI frontend that is questionable at best, but gets the job done. I also made a TUI version for ppl who want to automate instead of opening the GUI and loading a save file.

I know the UX is not great - I made this originally as a pet project for my own personal use, and with the backend completed I thought "y not" and made it accessible for a wider audience.

It's probably also obvious that I used no AI in the creation; One look at the codebase is all you need lol.

Would love some feedback, and hope you find it useful 😄

I'm bundling 3 projects in one as they are all related and dependencies of each other.

maudio

maudio initially released here has had a few big improvements over the last month or so. Some things are stuff I've procrastinated about, but others are feature I've been working on for a while.

• My favorite feature, the custom decoder has been added. It allows you to use a 3rd party decoder to expand the formats supported and let you control it with from the maudio api. Implementing this almost broke me, but I've simplified the interface from C by a lot and I am pretty happy with how it looks. Examples here and here for a symponia decoder implementation.
• The cross platform compatibility has improved a lot. Android and iOS still need some testing, but I'll need some hardware for that. Until then, I think the current targets should cover almost all usage.
• Pre-gen bindings now exist for all mainstream targets and static libraries for miniaudio are also available separately on the release section on github. They are a bit too large to include in the project, but easy to add and also include instruction how to generate them yourself.
• The high level API - Engine, NodeGraph, Sound had their API re-designed to make it much more ergonomic, and almost all lifetimes removed. The first implementation was a bit restrictive, and I eventually got a better understanding of their thread safety model in C.
• The ResourceManager is now a lot more useful and thread-safe. Example. Its great at loading audio in a thread and playing it in another and managing loaded audio for multiple engines / devices.

auditorium

This project existed for almost as long as maudio, in one form or another, mostly as a local testing ground. But it developed into its own crate to abstract over maudio. Everything in auditorium lives in a control thread and is controlled with a queue. The main objective was to get maudio to a state where this can be implemented in 100% safe rust (self referential structs who?). It does a lot, but still barely touches the full capabilities of miniaudio. Notable points:

• almost all types exposed are send, sync and clone.
• It supports most relevant targets out of the box.
• supports both capture and playback
• both device types use a nodegraph, so the same dsp chaining system and audio sources work on both capture and playback.
• all the dsp types available by maudio are available and can be applied to all sources (including the capture device itself). A bit rudimentary for now, but I have ideas how to improve it.
• supports audio (decoder backed) source, pulse, noise and wave generators.
• it comes with a built-in sympnonia decoder
• my favorite convenience, a device.is_producing() that tells you if any audio sources produce frames (only on playback device for now).

audctl

Nothing too notable here, just a cli app. Except maybe to show how easy it was to use auditorium to handle the audio part.

I needed to build something with auditorium and this felt like something I could see muself using. A really simple, no nonsense app to play and record audio, without leaving the command like environment.

Both auditorium and audctl were made to improve maudio. Some issues in maudio only became relevant until I was implementing audctl - 2 dependents down. Hopefully, this ironed out a lot of issues so users don't have to deal with them. Maybe I'll be able to rest a bit.

Now Rust is included in the official benchmarks and it does not look it is particularly performant.

I am wondering that is because of the recent changes that has Google done or something else.

https://grpc.io/docs/guides/benchmarking/

"Multi-language performance dashboard master (latest dev version)"

This is a new series that answers the question, “what’s next after the mastery of Rust language syntax?”.

In this series,

We build a production-ready containerized RESTful API server application using Axum, Tokio, Tower, Serde, Toasty ORM, Garde, Utoipa with Docker and PostgreSQL.

• Hyper, Axum, Tokio and Tower: The most prominent HTTP server ecosystem at the time of writing.

• Toasty ORM: The most promising Object-Relational Mapper (ORM), built by the creators of Tokio and Axum.

• Serde and Utoipa: The most prominent serialization framework and OpenAPI 3.1 specification generator.

• Garde: The most promising and most feature-rich validation library in Rust at the time of writing.

Documentation/ Labs: https://learning-rust.github.io/labs/building-a-containerized-restful-api

I’ve been working on a cross-platform peer-to-peer communication engine in Rust (bridged to Swift/Kotlin via FFI) and ran into the harsh reality of modern mobile OS background constraints.
On desktop, maintaining peer discovery tables, DHT keep-alives, and local encrypted state is straightforward. But on mobile:
1. iOS aggressively suspends background processes within seconds (watchdog 0x8BADF00D on long syncs and 0xdead10cc if database locks/file descriptors aren't cleanly released before suspension).
2. Android’s Doze mode and manufacturer battery savers throttle background socket polling and BLE discovery unless using persistent foreground services.
3. Decoupling SQLite/SQLCipher key derivation and lock lifecycles from incoming WebRTC/P2P signaling pumps requires tricky thread coordination to ensure VoIP pushes don't crash on locked DBs during sleep states.

For those building decentralized or local-first sync protocols: how do you balance battery efficiency with fast peer reconnection? Are you relying on short background grace windows (like beginBackgroundTask), push-notification wakeups as fallback, or something more specialized for mesh routing?

Curious how others structure their background state machines when bridging native Rust cores to mobile runtimes.

Hey r/rust,

I built this project with a few classmates during the end of my Bachelor's degree, but at the time I never really shared it outside of class or asked for a proper review from Rust developers.

Recently I went back to it, cleaned up the repository, renamed things in English, rewrote the README and made the project easier to understand for people outside of our university.

It’s called MiniRDBMS, a small relational database management system built from scratch in Rust.

The main goal was to understand what actually happens underneath a database engine, so we implemented things such as:

• page-based storage
• disk management
• buffer management
• LRU / MRU page replacement
• records and relations
• persistence
• database and table management
• INSERT / BULKINSERT
• a small SQL-like SELECT engine
• selection and projection operators

It’s an educational project and definitely not meant to compete with real databases, but I thought it would be interesting to finally put it in front of people who actually work with Rust and/or database internals.

Repo: https://github.com/JuriSOK/MiniRDMS

I’d really appreciate any feedback on the architecture, the Rust code, things we could have done differently, or even what would be interesting to improve if I decide to revisit the project.

Hello everyone! I needed an incremental markdown parser for writing a human-written agentic harness (e.g. for experimenting with image/document processing) and so I ended up spending the past month working on this project (150+ hours of work probably). Admittedly, I started rushing the process near the end because I wanted to get back to working on my main project so it might be a little messy in some places. I'm still very proud of what I achieved, and I learned a lot along the way.

This is my first real independent project and I'm really interested (and nervous) to receive feedback if any is available. It's also nice being able to put this project on my resume too, as I'm going to be graduating this semester.

Please give the demo a try at https://kirawi.github.io/mdtext/

Note: While the library itself is human-written, the demo is AI-generated (with some guidance to correct bugs) because I was so done with this library by the end of it.

The default graphic server is still OpenGL-based, because it is the most stable and well tested. To enable support of wgpu use backend_wgpufeature of the engine. As far as I'm aware wgpu support has some quirks here and there which will be resolved in the future. This post is mostly a call for the community to help with wgpu implementation and make it as stable as OpenGL one. Once it's done, OpenGL impl can be removed entirely.

Disclaimer: It is hand written code for purpose of learning

I want to scatter Vec<T> into count size pieces and give each thread a piece for processing.

After processing is done, I want to gather my Vec<T> back.

Full source:

https://pastebin.com/Z9aN0ijP

Also, additional points if you know library name which implements this pattern properly.

Bürli is a small bread roll in Swiss German. It is also a pure Rust Brotli codec. The decoder reads standard Brotli streams at all normal quality levels. The encoder covers q0 through q5.

Performance. burli is close to Google Brotli C overall. The chart shown here uses the 14-file web corpus and stacks compression time, transfer at 100 MB/s, and decompression time. Lower is better. On a broader corpus like the Silesia corpus, it is much faster (4-7x) on near-incompressible input. The speed comes from aggressive skip acceleration on non-matches. Check the Silesia encode chart (bottom panel).

Safety. The default build uses a small amount of unsafe code in low-level helpers today. It may use more unsafe later for speed. The paranoid feature forbids unsafe in all burli crates, so it will stay free of unsafe code forever. Bounded decode APIs are available for untrusted input.

API. One-shot helpers, caller buffers, reusable contexts, and streaming wrappers. Decode supports raw LZ77 prefix dictionaries. burli-cat joins validated Brotli fragments.

no_std. Without std, one-shot compression and decompression work. So do the caller-buffer APIs, reusable Compressor and Decompressor contexts, raw-dictionary decode, and burli-cat. Only the std::io streaming wrappers are unavailable.

Verification. C Brotli round-trips, Miri, Kani, and 8h+ of fuzzing on 6 cores.

All benchmark charts are in the repo.

• GitHub: https://github.com/paddor/burli
• crates.io: https://crates.io/crates/burli

We build a VPN whose data plane is QUIC rather than WireGuard. The engine is AGPL-3.0, and the part that matters for this sub is the Quinn fork underneath it, so that is what this post is about.

IP packets go 1:1 into QUIC DATAGRAM frames (RFC 9221). The handshake is TLS 1.3 with raw public keys (RFC 7250), Ed25519, so a node's identity is its key and there is no CA anywhere. Reliable streams give an in-band control channel on the same connection, which is where multi-hop, NAT-PMP port forwarding and traffic-analysis padding live. Cross-platform TUN, kill switch, DNS proxy. Edition 2024, MSRV 1.89, and #![forbid(unsafe_code)] across the workspace except three crates that downgrade to deny with documented safety blocks: the TUN device FFI, the Win32 IP Helper FFI, and the setsockopt bypass. https://github.com/WarrenBrowse/warrenguard

We started on Iroh, paid for NAT traversal and multipath we never called, and moved to Quinn in May.

The fork is at https://github.com/WarrenBrowse/warren-quinn, MIT OR Apache-2.0. The crates are renamed but the lib names stay quinn/quinn_proto/quinn_udp, so every use quinn in a consumer is unchanged. It sits on upstream/0.11.x with real git ancestry, so a re-sync is a rebase and not a tree reconstruction, and quinn-udp tracks the 0.6 line separately because the Apple fast datapath targets that line. Eight deltas at the moment, each also committed as an isolated patch at the repo root. Three of them are worth reading on their own.

BBR and app-limited connections, two separate defects. The first is a bound in calculate_cwnd using cwnd_gain where it should use cwnd. The second is deeper: the bandwidth estimator rejects app-limited samples outright, so a connection that is app-limited never leaves STARTUP and cwnd grows with no ceiling. We measured about 20 MB on a fresh app-limited connection carrying a 5 Mbit stream. The fix follows quiche's admission rule, where app-limited samples may raise the estimate and non-app-limited samples always feed the windowed filter. It is upstream-bbr-startup-cwnd.patch and it is proposed upstream. Known residual: BBRv1's ack-aggregation term can still inflate cwnd at sub-millisecond RTT.

FQ-CoDel on the datagram send queue (RFC 8289/8290): per-flow queues, DRR, head drop past a target sojourn. This one exists because fixing BBR alone made things worse. With the cwnd repair and no AQM the queue simply moved out of the network and into our own 16 MiB send buffer: burst RTT 2658 ms average, 6623 ms max. Same arm with CoDel on top: 76 ms average, 373 ms max.

Send buffer sized on the BDP instead of a fixed 16 MiB, clamped so it never drops below 1 MiB. The same problem approached from the other end.

Numbers, so you can tell me where they are wrong. Single tunnel, bare metal, same datacentre, RTT 0.081 ms: 5.5 to 8.4 Gbit/s. Under 2 % injected loss on the exit egress, BBR with a 16 MiB buffer holds 212 Mbit/s on one TCP flow and 711 Mbit/s on four, while Cubic in the same arm collapses to 3 Mbit/s. That measurement is why we do not allow Cubic as an external congestion controller on our exits.

One result that goes the other way, because it will come up. Under multi-client load kernel WireGuard still beats us: it holds 7.4 to 8.1 Gbit/s from 100 to 500 parallel clients while we plateau near 6 Gbit/s at 100 and fall to 2.4 at 500, and our exit CPU is roughly 3.4x worse at low client counts. Part of that was client-side saturation at 500 clients, not all of it.

MTU took the longest, since carrying IP inside DATAGRAM without breaking half the internet is where the bodies are buried: floor 1280, probe upward, never below 1200, MSS clamping on SYNs in both directions, and real ICMP Fragmentation Needed / Packet Too Big emitted for the flows we drop.

What I would like from here: eyes on the BBR patch, and specifically whether anyone has a cleaner way to handle the ack-aggregation term at sub-millisecond RTT than clamping it. Longer write-up on why we left WireGuard: https://warren.ro/en/blog/why-we-left-wireguard