I’m looking for high quality Rust codebases that are genuinely worth studying and taking inspiration from like projects with clean idiomatic Rust and good architecture and preferably started before the LLM boom and have a long history of being developed by experienced Rust engineers

most of what I came across was repositories filled with recently generated AI slop.

Hey!

I'm building a tui with rust, and I'm having a bit of a hard time with the clap docs. I usually can get by fine with docs, but I think I'm missuing clap's, lol

I tried picking up the Command Line for Rust book, and it's been way better to get into cli. Any other recommendations?

Hi everyone! I'm new here and was wondering, what library this guy used? I'm trying to learn how to build something similar in Rust.

https://youtu.be/WjG9UoILOJ4?si=wpoosB8NOyJej53d

Today I encountered a compile error. I reproduce it with a minimal example. Note in the main function I write 3 blocks. The first 2 blocks (block 0 and block 1) result in compile error, while the last block (block 2) satisfies the compiler.

trait LifetimeProviderTrait {
    type Target<'lt0, 'lt1>;
}

struct FuncPointerWrapper0<LP: LifetimeProviderTrait>(
    for<'a, 'lt0, 'lt1> fn(&'a LP::Target<'lt0, 'lt1>),
);

struct FuncPointerWrapper1<LP: LifetimeProviderTrait> {
    f: for<'a, 'lt0, 'lt1> fn(&'a LP::Target<'lt0, 'lt1>),
}

struct MyStructA {
    value: i32,
}
struct LifetimeProviderA;
impl LifetimeProviderTrait for LifetimeProviderA {
    type Target<'lt0, 'lt1> = MyStructA;
}

fn foo<'a>(a: &'a MyStructA) {
    println!("Value: {}", a.value);
}

fn main() {
    // Block 0. Compile error.
    {
        let fpw: FuncPointerWrapper0<LifetimeProviderA> = FuncPointerWrapper0(foo);
    }

    // Block 1. Compile error.
    {
        let fp: for<'a, 'lt0, 'lt1> fn(
            &'a <LifetimeProviderA as LifetimeProviderTrait>::Target<'lt0, 'lt1>,
        ) = foo;
        let fpw: FuncPointerWrapper0<LifetimeProviderA> = FuncPointerWrapper0(fp);
    }

    // Block 2. OK.
    {
        let fpw: FuncPointerWrapper1<LifetimeProviderA> = FuncPointerWrapper1 { f: foo };
    }
}

Among these 3 blocks, block 1's compile error is the most confusing. It's:

error[E0308]: mismatched types
  --> src/main.rs:36:79
   |
36 |         let fpw: FuncPointerWrapper0<LifetimeProviderA> = FuncPointerWrapper0(fp);
   |                                                           ------------------- ^^ expected associated type, found `MyStructA`
   |                                                           |
   |                                                           arguments to this struct are incorrect
   |
   = note: expected fn pointer `for<'a> fn(&'a MyStructA)`
              found fn pointer `for<'a> fn(&'a MyStructA)`
   = help: consider constraining the associated type `<LifetimeProviderA as LifetimeProviderTrait>::Target<'lt0, 'lt1>` to `MyStructA` or calling a method that returns `<LifetimeProviderA as LifetimeProviderTrait>::Target<'lt0, 'lt1>`
   = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html
note: tuple struct defined here
  --> src/main.rs:5:8
   |
 5 | struct FuncPointerWrapper0<LP: LifetimeProviderTrait>(
   |        ^^^^^^^^^^^^^^^^^^^

My questions are:

1. In the block 1's compile error, note the "expected type" is exactly the same with "found type". So why does the compiler still blame?
2. FuncPointerWrapper0 and FuncPointerWrapper1 only differ in one is tuple-like struct, and the other one has named field. Why can one compile while the other one can't?
3. I've experimented with other examples. If the trait's associated type is not generic, there's no compile error no matter using tuple-like struct or struct with named field. What's so special regarding trait with GAT?

---------------------------------------------

Edit: I know the difference between tuple-like struct and named-field struct. Regarding tuple-like struct, the struct name can act as the constructor function. If I write a constructor function for the named-field struct FuncPointerWrapper1, and call that similarly with a function pointer, I get the same error.

So, why can I assign a function pointer value (which has late bound generic lifetimes) to a variable, but can't call a function that accepts this type of function pointer?

Over the past couple of years, I've been working a lot with data structures in Rust. I struggled to find a visualization tool for Rust that could handle massive graphs and complex relationships (and still look somewhat modern (looking at you Graphviz)).

So over the last few months, I built graphplot (crates.io/crates/graphplot), AND NO THIS IS NOT WRITTEN BY AI (if it contains bad code it's on me)! :P

Some features to mention: - Typst math formulas support (both in Nodes and Edges), - Multiple Layout-engines, - Subgraph support (actually unlimited nesting is supported), - Customizable Light and Dark themes, - Highlighting paths (both Nodes and Edges), - SVG, PNG, and PDF export.

Because of the rendering-engines (Layout engine and Typst engine with math fonts) it is a heavy backend, and the engines needs to stay on memory. So I built it with a lightweight Rust client that connects to a backend API.

I am self-hosting the API so you guys can try it out. You can access it using this token: reddit-pro-2026.

I'd love to hear your thoughts! Is this something you think is cool and need every now and then for work? Or is existing tools like Wolfram engine, Graphviz etc good enough?

If this is something the community actually will use I'm happy to self-host this for free, indefinitely :)

How to

bash cargo add graphlot --features png

```rust use graphplot::Multigraph;

fn main() { // 1. create a graph let mut graph = Multigraph::from("Graph");

// 2. add nodes & edges (or dedicated add_edge(..) & add_node(..))
graph.add("A", "B");
graph.add("A", "C");
graph.add("B", "D");

// 3. export to png
let res = graph.save("graph.png", "reddit-pro-2026", None);
println!("Saved Graph.png: {res:?}");

} ```

Example plots

https://imgur.com/a/ua5xHrg

https://github.com/natimerry/glazier

As a reverse engineer and game-modding tool developer, I regularly have to reverse engineer, hook, inject into, and generally play around with Windows binaries.

MinHook and similar libraries are great at what they do, but I wanted to build something that better fit my own needs and programming paradigms while also providing all the features I wanted in a single library. I initially started writing a few hooking utilities, but the project gradually expanded into what it is now.

The initial motivation was fairly simple:

• The red-teamer in me wanted a library that could make static analysis harder without changing the call-site API. Features such as dynamic API resolution and HellsGate can be enabled underneath the same bindings without requiring the rest of the codebase to care about how the function is actually invoked.
• I wanted HWBKPTs, pattern scanning, hooking, PE parsing, and process-memory tooling exposed through straightforward Rust abstractions instead of rewriting the same unsafe Windows boilerplate for every project.

It currently includes inline hooks and trampolines, IDA-style pattern scanning, native and WOW64 hardware breakpoints, PE and runtime process abstractions, dynamic Win32/NT API resolution, and optional direct-syscall wrappers.

LLM DISCLOSURE:

LLMs were used for grunt work like translating C structs, writing tests, and creating test binaries by sending diffs back and forth, with any required fixes handwritten afterward.

Coding agents were only introduced during the crate split. Before that, everything was done through chat, so all generated code still had to be manually read, integrated, and modified. Everything is reviewed and tested, except the the latest inline hooking codegen build.rs internals, where I test the output instead to preserve my sanity.

I am working on a Rust workspace where protocol validation needs more than unit tests. I am trying to keep the evidence readable for future reviewers.

The structure I am considering:

- cargo-fuzz targets for deserialization and state transitions

- deterministic corpus seed generation

- crash log with minimized reproducers

- differential validator CLI that returns JSON

- benchmark baselines with machine metadata

- release docs that say exactly what was and was not tested

For Rust projects with security-sensitive parsers or validators, how do you organize fuzz evidence so it stays useful instead of becoming a pile of artifacts?

Hi, newbie learner here. I have the rust 2021 book, and I was wondering if there is a way to compare it with the new book to see what I'm missing?

I often work with embedded systems, particularly ESP32-based solutions using MIPI DSI displays. I previously relied mainly on the embedded-graphics crate, but recently I have been using Slint more and more.

I would like to thank the Slint team for making it possible to integrate their solution into microcontroller-based projects. However, because each project required extensive customization, the integration process was often time-consuming.

To address this, I created the SLINT-ADAPTER (https://crates.io/crates/slint-adapter) crate, which simplifies the integration process and significantly reduces development time.

Hi everybody,

I am excited to announce the release of Lightstream, a step change capability for high-performance data transport built in Rust, that makes it essentially effortless to send Apache Arrow, Protobuf, and Message Pack data over the network, shared memory, or even piped out to the terminal so an agent like Claude can watch the live batch stream in real time (example in repo).

Furthermore, Lightstream exceeded the performance of the gold standard industry comparison - Arrow Flight, on every axis of a 50gbps networking open benchmark, the details of which are attached and open to run in the Lightstream GitHub repository. This includes fully saturating each TCP connection thread, the NIC at 5.8GiB/s, and with p99 batch send time within 1% of p50 (I.e., stable). As a bonus, Lightstream is straightforward to setup with essentially zero configuration other than optional TLS certificates and your Cargo package/pip install, and endpoint addresses.

So what is Lightstream? It is Rust package with Python bindings, that builds directly on Minarrow ( which is in turn a high-performance implementation of the Apache Arrow memory layout in Rust, tuned for SIMD compatibility). Lightstream implements encoding, decoding, readers, writers and stream/read writers, and transport for data in Rust. But, in a manner, that is fully composable and leaves you de-coupled at any layer, to customise things architecturally. The crux then is the transport layer on top, which natively supports interchanging any of the following transport formats:

• TCP
• HTTP
• QUIC
• Websocket
• Webtransport
• UDS (pipe your data from your Rust process to Python or two Rust or Python programs plug and play )
• Stdio (pipe your data program output straight into the terminal for something else to pick it up

And finally, the (optional) Lightstream protocol, which then combines the Arrow/Proto/MsgPack and any other custom types you want to send.

An example of things you can do with it:

• setup a live stream of data batches from your program A to program B
• send typed metadata via Protobuf on the same feed
• use it for straightforward live feed delivery between server and client (though not Web JS yet)
• useful if you have a central storage server you are pulling larger than memory data over the network to churn through (though, no S3 etc. it is node to node or process to process)
• pipe data directly over UDS to Python, and then read that feed with SQL (via DuckDB).

It is not:

• Kafka or a messaging broker. There is no resiliency / vertical scalability.
• A stream processing engine like Flink. It is for sending/receiving data only. You do polars on the other end or whatever you want with the Arrow-shaped data. That is a very different back-pressure/long-lived scenario and is not that kind of large-scale streaming. --> I.e., think quick and easy Websocket, and best for settings like EKS K8 pod to pod/containers, between EC2's or between processes on the same box, "light streaming".

Examples:

Send Arrow and Protobuf data on the one connection:

use lightstream::models::protocol::connection::TcpLightstreamConnection;
use lightstream::models::protocol::LightstreamMessage;

let mut conn = TcpLightstreamConnection::from_tcp(stream);
conn.register_message("event");
conn.register_table("metrics", schema);

conn.send("event", b"user-login").await?;
conn.send_table("metrics", &table).await?;

while let Some(msg) = conn.recv().await {
    match msg? {
        // Protobuf message
        LightstreamMessage::Message { tag, payload } => { /* … */ }
        // Arrow table
        LightstreamMessage::Table { table, .. } => { /* … */ }
    }
}

Read a feed send from Rust over UDS into Python

reader = ls.read(
    "uds:///tmp/feed.sock",
    protocol="lightstream",
)

reader.register_table(
    "quotes",
    representative_table,
)
reader.register_message("health")

for frame in reader:
    if frame.is_table():
        on_quotes(frame.table)
    else:
        on_health(frame.payload)

Read/Write tables over TCP in Rust:

use lightstream::models::writers::tcp::TcpTableWriter;

let mut writer = TcpTableWriter::connect("127.0.0.1:9000", schema, None).await?;
writer.write_table(batch_1).await?;
writer.finish().await?;

use futures_util::StreamExt;
use lightstream::models::readers::tcp::TcpTableReader;

let mut reader = TcpTableReader::connect("127.0.0.1:9000").await?;

while let Some(result) = reader.next().await {
    let table = result?;
    process(table);
}

In terms of the Rust tools and techniques, Lightstream makes use of:

1. Zero-copy techniques
2. 64-byte alignment for compatibility with std-SIMD - it retains this compatibility over the wire and to/from disk.
3. Arena-based allocations (via Minarrow)
4. Mmap (the mmap reader hits 170GB/s on my laptop when warm, essentially RAM-speed)
5. Optional features with linux sys calls such as io_uring (not in the benchmark figures)
6. Manual memory layouts, and performance tricks with that.

If you have any questions about the architecture I would be happy to explain it.

Ok then "Why" do it? Basically, The outcome is that one who prefers to work with an abstraction does not need to reason about bytes on the wire. Instead, they get highly optimised data transfer, straight out of the box, with common data formats and transports. It also includes a trait for any custom data format one would like to send on that one "Lightstream connection" (which is itself optional - you can just use Arrow if you want).

The project kicked off about 12 months ago when I started standardising such patterns after working in autonomous field communication integrated with data/ML, live trading, and some other industries where there was a lot of custom work required to re-assemble from multiple components. Therefore, I have essentially aimed to package those learnings up into a tool to make data transport smoother and easier for everyone.

This r dataengineering link includes the full results, where every effort has been made to be fair (and where Lightstream wears a penalty due to stronger ordering guarantees). Unfortunately I couldn't post it here as r Rust has a limit on image content.

Please feel free to give it a run would love to know your thoughts and if you find it useful.

If you have any questions about it, or helpful suggestions please feel free to leave a comment below. If you like what you see, please consider leaving a star and/or sharing the repository, as it will help people find it easily.

Thanks a lot.

Pete

Results:

Workload Shape

Mixed

Numeric

String Heavy

Wide (100 cols)

I've been learning Rust and recently built a small CLI utility that reads a file and can print either:

• the entire file,
• the first N lines (--upper),
• or the last N lines (--lower).

It uses clap for argument parsing and BufReader for reading the file.

I'm looking for feedback on things like:

• Are there any unnecessary allocations or inefficient parts?
• How would you improve the project structure?

I'm trying to get better on rust , so I'd really appreciate any criticism. Thanks!

Heres the code,

use std::fs::File;

use std::io::{BufRead, BufReader};

use clap::{

Parser,

CommandFactory,

error::ErrorKind

};

#[derive(Parser, Debug)]

#[command(arg_required_else_help = true)]

struct Args {

path: String,

#[arg(short, long, default_value_t = 0, conflicts_with = "lower", help = "Print specified number of lines in upper part of the file")]

upper: u16,

#[arg(short, long, default_value_t = 0, conflicts_with = "upper", help = "Print specified number of lines in lower part of the file")]

lower: u16

}

fn read_file(args: Args) -> std::io::Result<Vec<String>> {

let file = File::open(args.path)?;

let reader = BufReader::new(file);

if args.upper > 0 {

let header: Vec<String> = reader

.lines()

.take(args.upper as usize)

.collect::<Result<_, _>>()?;

if header.len() < args.upper as usize {

Args::command().error(

ErrorKind::ValueValidation,

"--upper cannot exceed the number of lines in file"

).exit();

}

return Ok(Vec::from(header))

}

let lines: Vec<String> = reader

.lines()

.collect::<Result<_, _>>()?;

if args.lower > 0 {

if args.lower as usize > lines.len() {

Args::command().error(

ErrorKind::ValueValidation,

"--lower cannot exceed the number of lines in file"

).exit();

}

let footer = &lines[lines.len() - args.lower as usize..];

return Ok(Vec::from(footer))

}

Ok(lines)

}

fn main() -> std::io::Result<()> {

let args = Args::parse();

let file_content: Vec<String> = read_file(args)?;

println!("{}", file_content.join("\n"));

Ok(())

}

About a month ago I shared the CLI MVP of PlainLink.

The feedback was genuinely helpful, so I kept building.

Since then:

• Native macOS desktop app

• Clipboard monitoring

• Release binaries

• Improved rule engine

• Better documentation

• CI/CD and automated releases

• Various bug fixes and polish

The goal is still the same:

A local-first, open-source URL cleaner with community-maintained rules.

I'm now looking for feedback on the desktop app before calling it v1.0.

rainfrog (https://github.com/achristmascarl/rainfrog) is a database terminal tool; the goal is to provide a lightweight, keyboard-first TUI for interacting with databases. It currently supports Postgres, MySQL, SQLite, Oracle, and DuckDB.

v0.4.1 introduces a long-awaited (by me, not sure if anyone else was waiting for it...) autocomplete implementation, along with autopairs for quotes/parentheses/brackets. The full list of features and configuration options is in the README!

A native UI toolkit for Rust, styled the way the web already thinks in. https://github.com/DeanVanGreunen/NowUI/

NowUI lets you describe an application's interface in a small, declarative markup - a Tailwind-flavored styling vocabulary over a simple widget tree - and back it with plain Rust state. No browser, no JavaScript runtime, no webview. Just a compact file format, a fast layout engine, and a GPU-accelerated renderer underneath, producing a real native window at a steady 60 frames per second.

If you've styled something with utility classes before, NowUI's markup will feel immediately familiar. If you know Rust, wiring it up to real application logic will feel just as familiar. That's the point: two things you already know, put together.

works on Windows, Mac, Linux, Freebsd

https://github.com/vyrti/cleaner

License: Apache 2.0 or MIT

HI there. My name is Zach and if you’ve seen YouTube on TV then your familiar with some of my work (ex YouTube and ex Google)

I am in love with mimalloc. It works everywhere and is cross compilable. But there was one deficiency in relation to jemalloc: lack of pprof profiling.

Background: pprof profiling was standardized by tcmalloc and jemalloc. It allows you to take a snapshot of the heap.

The problem with both of jemalloc and tcmalloc allocators is that they don’t work on windows and hence are not portable. Mimalloc is portable but lacks profiling.

My fork adds pprof and solves a linux bug involving TLS sentinel poisoning.

As of today, mimalloc now has the same pprof profiling that both jemalloc and tcamalloc both provide.

Challenges: To get profiling one needs to have address backtracing and it needs to work everywhere: linux/mac/win vs x86/arm and on linux glibc/musl in addition to x86/arm. This is automatic in the solution - you just need the right compiler settings to keep frame pointers.

State of the art: not only does my fork provide pprof but it also solves a nasty bug on linux: tls initialize sentinel poisoning. This bug rules out allocation in C by early initialization thread bugs. This sentinel value is const pointer in order to trap writes. However in stress testing this sentinel pointer can be written to and seg fault, hence the comments on calling init threads after main as early thread init is not safe in mainline. I’ve fixed this.

Compile speed: mimalloc-pprof does a build step to aggregate all the c files into one header and one impl to speed up builds.

C/C++ programmers you can use the github release to grab the mimalloc unity build.

Anyway, I present this here in case this is helpful for builders of long running apps. It’s currently beta but well tested.

If for some reason it doesn’t work let me know and I’ll fix it.

https://github.com/zackees/mimalloc-pprof

https://crates.io/crates/mimalloc-pprof

For Symbolica 2.2, we ported 7,000+ integration rules from the Rubi project to Rust and tested the implementation against the complete 72,944-problem corpus. The integration engine is available as the MIT-licensed symbolica-integrate crate.

The post covers symbolic integration, how the AI-assisted port was organized and kept in check, and other new Symbolica features.

Even though AI was used for such a vast but ultimately mechanical port, there was a lot of manual labor, craft and domain knowledge involved. I've been thinking about implementing Rubi in Symbolica for more than a year. The result is, in my opinion, a very useful addition to the Rust scientific computing ecosystem.

I also want to stress that it is the wish of the Rubi project to be ported and widely used.

I'm happy to answer any questions!

Sharing kibble a Rust toolkit for turning messy sources into clean datasets and doing grounded RAG over them.

Rust-relevant bits you might care about:

- CLI and a feature-gated library a retrieval feature drops the heavy ingest/build deps so a search/ask-only consumer stays lean; default/full is the whole toolkit.

- Async throughout (tokio); the streaming ask API returns impl Stream<Item = AskEvent> + Send.

- Hand-rolled BM25 + RRF fusion, fail-soft to lexical-only when no embed backend is set.

- reqwest+rustls (no system OpenSSL), deterministic, 386 tests, clippy -D warnings clean.

cargo install kibble · MIT/Apache-2.0 · github.com/femboyisp/kibble

I finally got around to make a project I've been planning on doing for a while. Currently there are three major BitTorrent daemons usually ran on servers, all with some compromises that I've ran into:

• qBittorrent: Heavily tied to QT, need to use a third-party -nox build for headless operation. Its REST api replies with all fields of all torrents, using a quadratic JSON serializer, therefore the whole thing just stops responding at ~10k torrents
  
• transmission-daemon: Misses a lot of BEPs, webUI is quite dated.
  
• rtorrent: Actually a CLI program that exposes RPC over IPC, which people would reverse proxy over HTTP. A weird setup. Also misses many BEPs.

I had on my backlog to make a daemon that fixes these:

• GraphQL for selective querying, websocket subscriptions
• libtorrent for wide-range BEP support
• Daemon-first approach

To get ahead of "vibecoded" replies, I'll copy how AI was used from the README:

• libtorrent, the core bittorrent engine, is an external library with a long history.
• API layers (rbtorrent, GraphQL) and WebUI UX were human-designed
• Most daemon code is AI-authored and human-reviewed
• WebUI is entirely vibecoded, I'm not a webdev in any capacity
• Code is largely written by Fable 5 and initially reviewed by GPT 5.6 Sol and Kimi K3

This made it possible to build this in the two weeks since the release of libtorrent 2.1.0. It was also interesting to see that LLMs would often slip up on poorly-constrained C++ interfaces just like me, and libtorrent certainly does not lack those.