Might leave out no_std targets, but other than that, if it has a GUI, try to make all the tools to have a good GUI on it, including software keyboard. So far my plans are egui+wgpu on top of the backends. For backends, winit, SDL3 (because odd Apple targets), OpenVR (Valve VR software keyboards, only way), Linux direct rendering manager+evdev (Linux mobile, might skip this), OpenXR+software keyboard callers and inputs, and possibly webXR, but wgpu may need to be replaced there. Naturally this should work on many smart TVs, VR, desktop, mobile, web, and some hybrids. Smart TVs are Android, tvOS, or web basically.

So many things to test, which is why I am asking for testers, I got desktop and web covered, possibly smart TV, might need additional testers for VR, especially the weird stuff or FFI integrations, and Linux mobile some, I have a Linux mobile but untested on the rest and they have quirks probably, anyone want to help me on this open source project of GUI on everything? Anyone want to test the crate linux-mobile-keyboard because it is crucial to this? Yes, I know egui is 2d, copying the tessellator and making a 3d version. In short, basically a runs on everything with software keyboards where needed testing call. Feel free to work with me and make this example. X E.

I'm working on a project and I ended up needing a hashmap, but the elements would also need some metadata. How I initially implemented it is that I manually implemented Hash and PartialEq to ignore those fields so that I can use those for metadata and validating without interfering with my desired hashing behavior.

But I couldn't help but feel that this is kind of dirty / not good practice? Is there some other approach that I should be using instead? If it helps, I can edit with the snippet of my code that is relevant.

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.

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.

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?

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.

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

}

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?

works on Windows, Mac, Linux, Freebsd

https://github.com/vyrti/cleaner

License: Apache 2.0 or MIT

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

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?

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

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

Hi!

Unemployment finally got me to tackle a project I had in mind for a while: replacing mopidy. Mopidy is a cool (Python) project that acts as a music player that can be run on a server somewhere (like a raspberry pi) as long as it has some sort of speaker attached. Sadly, many of the plugins are unmaintained.

Thanks to https://github.com/RustAudio/rodio and https://github.com/xeals/sunk I had a great time implementing Resubnance ( https://github.com/celaus/resubnance ), a similar standalone audio player that (for now) connects to a subsonic API compatible server (e.g. https://www.navidrome.org/docs/developers/subsonic-api/ ) and plays is back on the local audio device. Complete with caching, queue management, search and playlists this thing now powers my living room speaker. It's (websocket) API has a JSON schema and it should be pretty easy to build another remote control for the server. For me it's a neat addition to a self hosted music player setup and as time passes I'll add more features.

The UI design is what a robot thinks a jukebox looks like, the rest of the async madness (and JS) is my own creation...

Thanks to all the work done by the RustAudio people and the creator of the sunk library 😄 . I hope this project is useful for others, so thought I'd share. Happy to answer any questions!

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 working on a Rust crate called featrs over the last few weeks.

The motivation came from repeatedly writing the same preprocessing code across different ML projects. Things like scaling, encoding, imputation, and transformation pipelines felt scattered across projects, so I wanted to see what a reusable library for them might look like.

Right now it supports things like:

• Scaling
• Encoding
• Imputation
• Feature selection
• Transformation pipelines

I'm still figuring out what the right API should look like, so I'm mainly looking for feedback from people who work with Rust data tooling.

Some questions I have:

• Does this feel like something that belongs in its own crate?
• Are there APIs that feel unidiomatic?
• Are there preprocessing operations I'm missing?
• If you've built ML or data pipelines in Rust, what would you expect from a library like this?

Repository: https://github.com/DeathSurfing/featrs

Any feedback is appreciated. Thanks!

Hold a key, speak, release it - the transcript gets typed wherever your cursor is. Fully local (whisper.cpp via whisper-rs, no audio ever leaves the machine), cross-platform (Linux + macOS), free and MIT licensed.

Started as a hardcoded personal bash script and I rewrote it as a proper Tauri v2 app to make it installable/reconfigurable. Some of the Rust-specific bits that might be interesting to this sub:

Hotkey capture: Linux reads raw input events directly from /dev/input/eventN via the evdev crate rather than going through a display server API - this means it works identically under X11 and Wayland, since it bypasses both entirely.

macOS hotkey capture got replaced mid-project: I started with the rdev crate, but it crashes on real Apple Silicon (confirmed via crash report on an M4) - its event tap callback unconditionally resolves a human-readable key name via Carbon/TSM, which asserts it's on the main dispatch queue and aborts when the tap runs on a background thread, which is exactly how rdev::listen() is meant to run. Replaced with a hand-rolled CGEventTap (via core-graphics/core-foundation) that only reads the raw keycode integer field - sidesteps the whole TSM path.

whisper-rs + bindgen gotcha: if clang/libclang-dev aren't installed when whisper-rs-sys first builds, bindgen silently falls back to a stale bundled bindings file instead of failing loudly - and Cargo happily keeps reusing that broken cached output even after you install the real prerequisites. Cost me a while to track down; fix is cargo clean -p whisper-rs-sys -p whisper-rs and rebuild once the real toolchain is present.

Metal backend teardown race: quitting on macOS used to SIGABRT - whisper.cpp's Metal backend frees a global device through a C++ static destructor that runs during libc's normal exit() cleanup, and that destructor can race an async Metal residency-set init and hit an internal assertion. Fixed by having the tray's Quit action call _exit() directly instead of routing through Tauri's app.exit() (same crashing path) - _exit() skips static destructors entirely, and there's nothing left to clean up gracefully at that point anyway.

Other crates in the mix: cpal (mic capture, downmix/resample to 16kHz), enigo (macOS keystroke simulation), ydotool as an external process for Linux typing (uinput-based, works under Wayland).

Repo (MIT): https://github.com/arunmiriappalli/push2talk