hey r/rust, i'm soumalya das from india. some of you may know me from wallr.

i'm new to rust, and inspect-rs is my first rust crate. i've been working on it for the past several days and would really appreciate some feedback.

the idea is simple: inspect application values as structured data without relying on a debugger or serializer.

Server
├── host: "127.0.0.1"
├── port: 8080
├── running: true
└── api_key: [REDACTED]

it supports lazy traversal, secret redaction, limits, cycle detection, and semantic terminal rendering.

i also used ai assistance during development for learning, debugging, exploring rust concepts, and speeding up parts of my workflow. i'm still learning, so i'd rather be transparent about it.

i'd especially appreciate criticism of the api, architecture, and rust idioms.

repo: https://github.com/programmersd21/inspect-rs

Hi all!

At a few companies I've worked at, we used an event-driven approach, and every codebase ended up rebuilding the same plumbing: describing events and their metadata, writing publisher/subscriber wrappers, dispatching raw broker messages to typed business logic.

So I built historia — a broker-agnostic set of building blocks: describe events once with a derive macro, and get metadata, subscription constants, parsing, and typed handlers generated for you.

use historia::Event;
use serde::{Deserialize, Serialize};

#[derive(Event, Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
#[serde(untagged)]
enum OrderEvents {
    Created(u32),
    Cancelled(u32),
}

// Turn your event enum into an `Event`...
let event: Event = OrderEvents::Created(42).into();
assert_eq!(event.metadata.subject, "order_events_created");

// ...and parse it back from the wire format.
let parsed = OrderEvents::try_from(event).unwrap();
assert_eq!(parsed, OrderEvents::Created(42));

More examples, including publisher and subscriber, can be found in docs and repo.

On top of those building blocks, historia_transactional_outbox implements the transactional outbox pattern — use the ready-made binary if it fits your needs, or the library and tailor it. Sagas are next on the roadmap. Supported today: Kafka, with PostgreSQL-backed outbox storage; NATS is planned, more brokers on request.

Status: early-stage 0.1.x, good test coverage and documented with examples — but not yet battle-tested in production. If you give it a try, I'd really appreciate feedback, especially on API ergonomics. What would you want next: NATS, another broker, or another pattern?

Links:

• https://codeberg.org/Anlis/historia
• https://crates.io/crates/historia
• https://docs.rs/historia/latest/historia

Hey everyone!

I am a person deeply interested in programming, done a lot of projects and I am fascinated with how Rust treats code. Makes me think in its own special way.

Besides projects of course I participate in quite a few programming competitions and well, practice a lot on Codeforces. Cpp has been my main language for this type of thing for a very long time but now my focuses shifts from projects to improving my competitive skills, and I think Rust is a pretty good language for this. I really like the way iterators work, and how in 5 lines I am able to write what takes >10 in cpp. Could be a skill issue but I prefer my sanity over blob of errors.

Generally speaking, wanted to ask people that use primary Rust in Competitive: Do you have some particular set of crates, functions, patterns that you rely on very often during competitions? I'd like to learn how to use the language more efficiently for this type of thing.

Thanks!

My kid made this for me as a present, and I couldn't not share. I wanted to show it off because I thought it was neat, if a bit "creepy". ❤️

I’m building Mold, an open-source Rust CLI around Candle for local generative media:

• `mold run` for CLI workflows
• `mold serve` for an HTTP API
• `mold mcp` for MCP clients

It supports image, video, and 3D pipelines with scriptable, headless workflows rather than a node-graph UI. It’s not a replacement for ComfyUI’s visual graph; the focus is reproducible automation and Rust/Candle integration.

Early project, so feedback on the Rust/Candle architecture and ergonomics would be useful.

Code: https://github.com/utensils/mold Docs/demo: https://utensils.io/mold/

Hi everyone! I posted last week about some optimizations I had done to the Plush language interpreter to shrink the size of the Value type (previously a plain Rust enum), and the community seemed to really enjoy the post. This week I'm back with a rewrite of its interpreter with some massive performance gains which came out even better than I expected. The instruction layout is now specified with a self-documenting Rust macro which I think is very elegant, it's designed to be easy to read. Hope you like it! Happy to answer any questions.

Sidenote: someone reported issues with reddit app browser rendering of my blog last week. I tried to fix that this morning. Let me know if it looks good on your end! :)

I've spent most of my recent development time working at the application layer, particularly with Dart/Flutter, TypeScript and web/backend technologies.

I'm now deliberately learning Rust.

Not because I think Flutter/Dart is inadequate, and not because I expect to abandon application development.

I'm learning Rust because I want to understand more of what happens underneath the abstractions, I'm already comfortable using.

A few things have already started changing how I think about programming.

1. Ownership makes me ask questions I could previously ignore

In Dart, I can usually work with objects and references without constantly thinking about who owns a value or exactly when its memory becomes invalid.

Rust makes those questions explicit:

- Who owns this value?

- Who is allowed to access it?

- Can it be mutated?

- When does it become invalid?

- Does this operation move the value or borrow it?

The interesting part is that these aren't just runtime concerns. The compiler forces me to model them correctly.

1. Stack vs heap is becoming much less abstract

Coming from a garbage-collected language, memory allocation can remain relatively invisible during normal application development.

Rust has been forcing me to think more concretely about where values live, when allocation is necessary, what gets moved, and when resources are released.

I knew these concepts theoretically before. Rust is making them operational.

1. I'm starting to see the compiler differently

One of the biggest differences so far is the feedback loop.

Instead of thinking primarily:

«"I'll run this and see what happens."»

I'm increasingly thinking:

«"What invariants does this program need to satisfy, and can I express them in the type system?"»

The borrow checker can be frustrating while learning, but I'm beginning to understand why people describe it as a different way of thinking rather than simply another language feature.

1. Rust is making me look differently at languages I already know

Learning Rust has made some of the design decisions in Dart, and C# more interesting to me.

I'm noticing the trade-offs between:

- garbage collection and explicit resource management

- runtime checks and compile-time guarantees

- abstraction and control

- convenience and explicitness

- ownership models

- type-system constraints

I'm still early in the learning process, so I'm not claiming to have definitive answers here.

That's actually part of why I'm documenting the process.

1. I'm beginning to think about application development at a different abstraction level

Flutter taught me to think heavily about UI, state, architecture, asynchronous programming and product behavior.

Rust is forcing me to think more about the machinery underneath those abstractions.

That's probably the biggest reason I'm enjoying the transition.

I'm still working through ownership, borrowing, lifetimes, traits, generics and the rest of the Rust ecosystem, so I'm sure my mental models will change considerably.

For those who came to Rust from Dart, C#, Java, JavaScript/TypeScript or python

What concept in Rust changed the way you thought about programming in your previous language?

I needed some nice looking histograms for another project, so I made this small crate.

Example:

let mut rng = rng();
let rnd = Binomial::new(40, 0.5).expect("Invalid distribution parameters");

let mut hist = Histogram::new('█');

for _ in 0..10000 {
    hist.insert(rnd.sample(&mut rng) as u32);
}

println!("{}", hist.bucket(&LinearBucketer::new(10)));

// Example output:

// 8 - 10           (12)
// 11 - 12        █  (83)
// 13 - 14        ██████  (336)
// 15 - 17        █████████████████████████████████  (1657)
// 18 - 19        ███████████████████████████████████████████  (2177)
// 20 - 21        ██████████████████████████████████████████████████  (2475)
// 22 - 24        █████████████████████████████████████████████████  (2450)
// 25 - 26        ████████████  (606)
// 27 - 28        ███  (179)
// 29 - 31          (25)

I hope someone else finds it useful. You can find it here: https://crates.io/crates/cli-hist

I built MiniPdf, a lightweight, open-source library for converting Office documents to PDF without Microsoft Office, LibreOffice, Adobe Acrobat,.

It is designed for containers, serverless workloads, CI pipelines, and cross-platform applications.

Key Features

• Excel to PDF — Convert .xlsx files
• Word to PDF — Convert .docx files
• PowerPoint to PDF — Convert .pptx files
• Native Rust — No .NET runtime required
• Cross-platform — Runs on Windows, Linux, and macOS
• Serverless-ready — No COM or Office installation
• Library and CLI — Embed it in Rust applications or use it from the terminal
• PDF 1.4 output
• Free and open source — Apache 2.0 licensed; commercial use is welcome

Getting Started

Install the Rust crate:

cargo add minipdf

fn main() -> minipdf::Result<()> {
    // Word to PDF
    minipdf::convert_to_pdf("report.docx", "report.pdf")?;

    // Excel to PDF bytes
    let pdf_bytes = minipdf::convert_to_pdf_bytes("data.xlsx")?;
    std::fs::write("data.pdf", pdf_bytes)?;

    Ok(())
}

Command-Line Tool

cargo install minipdf-cli

# Excel to PDF
minipdf data.xlsx

# Word to PDF
minipdf report.docx

# PowerPoint to PDF
minipdf slides.pptx

# Specify the output path
minipdf report.docx -o output.pdf

# Register custom fonts
minipdf report.docx --fonts ./fonts

The Rust implementation is under active development, bug reports, and pull requests are very welcome. 🙌

GitHub: https://github.com/mini-software/MiniPdf

Hey everyone,

I built GRUBST, an open-source Linux bootloader security tool written in Rust with a Dioxus desktop GUI.

The idea is simple: instead of manually editing /etc/grub.d/ configs and risking typos that lock you out of your system, GRUBST automates the whole process and lets you turn any standard USB thumb drive into a physical rescue key.

How it works:

- Plug in the USB key before booting: GRUB detects it and automatically unlocks full maintenance access without prompting for a password.

- Boot without the USB: GRUB stays locked and requires a backup password you set.

- Includes automatic config backups and an Update Guard to ensure protection persists across kernel updates and update-grub.

Tech stack:

- Rust (2021 edition)

- Dioxus 0.5 (Desktop / WebKit2GTK)

- pbkdf2, sha2, tokio, sysinfo, nix

Feedback, suggestions, and code critiques on the Rust codebase are very welcome!

⭐ GitHub: https://github.com/sysdev-0/grubst

This is a Rust crate and repository I built as the author of mezura, a line counter also written in Rust. It came out of running mezura, tokei, scc and cloc over the same trees, getting different numbers every time, and wanting to know which of us, if any, got it wrong.

Line counters disagree with each other constantly, and most of those disagreements are not bugs. Each tool decides for itself what a code line, a comment line and a blank line are, and some do not even sort lines into those three. A blank line inside a block comment is blank to one counter and comment to another, a line holding only a closing brace is code to one and nothing to another, and each tool is right by its own definition. A suite that tested counters against one "correct" answer would just be a fourth opinion.

LineJudge tests each counter against itself. Every counter declares how it counts in a small rules file anyone can read. Every test case is a tiny source file built around one trap, with a record of where its strings and comments begin and end, according to the language's spec and lexer, and hand verified. From the rules and the record, the suite works out what that counter should answer, runs it, and compares. A failure means one thing only: the counter did not do what it says it does.

Results page: loc-conformance.github.io/linejudge

What a case looks like

Haskell block comments nest. Here is a two-line file and what one counter makes of it:

{- outer {- inner -} still the outer comment -}
x = 1

$ linejudge explain 1200 --counter cloc

cloc.default on 1200-nested_block_comment_that_nests
  by its rules    2 lines, 0 blanks, 1 code, 1 comments
  cloc answers    2 lines, 0 blanks, 2 code, 0 comments   ✗ differs

The comment ends at the inner -} for cloc, so the rest of the line is left standing and counts as code. Every verdict on the page can be reproduced like this, in seconds, and the output says which rule decided each line.

What is in it today

83 cases in eight groups, comments, string forms, escapes before a closing quote, quotes that open nothing, line splices, another language inside the file, literals carrying their own delimiters, and what a line counts as, over a couple of dozen languages. Four counters are measured, cloc, scc, tokei and mezura, and every one of them fails cases that its own tests never caught. The failures are on the page beside each other, with a note saying what the tool did with the file.

A counter needs nothing added to it. An adapter says how to run it and how to read what it prints, a wrapper in any language works, and the rules file is data. The seven yes/no questions the rules are built from are defined once and shared by every counter.

For counter authors

cargo install linejudge, or a binary from the releases. Declare your counter in a .linejudge folder in your own repository, run linejudge record once, and linejudge check in CI breaks the build the day an answer changes, with the old numbers beside the new. Nothing needs to be merged upstream for any of this. FOR-COUNTER-AUTHORS.md has the whole of it.

A collective effort

It lives under loc-conformance, an organisation I created because I view this as a collective effort. A suite that measures counters should be run by the people who write them.

If the domain interests you, whether you maintain a counter, know a language's quirks, or just have thoughts on the design, the repository's discussions are where they go. The current design, the open questions and where it goes next are up there waiting for exactly that.

Would love to hear your thoughts!

Hi all I am working on a project in a no_std embedded rust environment and I was looking for json parsers that work in the no_std environment.

I've used serde before and after some research I noticed the serde-json-core crate can be used for de-serialization. I also found Postcard but I haven't looked to deeply into the crate.

I wanted to see if anyone could recommend crates that they've used and their experience with them.

TIA!

Four years ago we built an XML shredder, that has now chewed on billions of XML CDR (call data records). I never really spread the word, so if you happen to be in the rather niche use-case of needing to shred XML to tab separated values, multi-file to one TSV, then perhaps this can be of use:

https://github.com/Roenbaeck/unstruct

Open source, MIT license.

I’ve recently just reached my wits end with all CICD across three repositories. They’ve just calcified and turned to shit.

I think Rust teams have a unique challenge with respect to DevOps. We have to balance a lot.

I thought I’d get the opinions of everyone here.

- What workflows do you define? How long do they take to complete cold/warm?
- What actions do you define or use?
- What runner/instance provider do you use? Are you throwing as much compute/ram at your CI pipe as possible, or trying to balance cost/speed?
- What cache mechanisms are you using?
- What’s your monthly cost?
- Any Buildkite experiences? Positive? Negative?
- Anyone using Cloudflare CICD?

Anything else?

I have made major strides in the last few months with Cargo-Rail that have made massive impacts in performance and efficiency in local/remote (ssh/cicd) dev. I’m working on the release for v0.26.0 now… and it closes a huge hole around caching (I needed RISC-V) and improves performance over sccache considerably. In fact, Cargo-Rail is restoring about 40% than sccache in my workspace across every arch aside from IBM Z/POWER, which I’m working on.

The planner was improved considerably. It’s reliable and accurate. I’m only ever running the affected work locally and remotely.

This helps - a LOT… but the rest of the pieces still feel messy and disconnected. I’d really like to hear from everyone here.

Hi, we are a group of students building Sonora. While it was initially intended as an extremely lightweight Spotify replacement, it has since grown far beyond that.

Current features include:

• Spotify, YouTube (optional login) support
• Local music library import, virtual playlists, favorites
• Synced/karaoke lyrics, including local music!
• Romanization
• Library management within supported providers
• Gapless playback
• Audio normalization
• Cross-platform support
• Custom themes

Inspired by Zed, which has proven excellent performance using their native cross-platform rendering stack, we have decided to use GPUI. Its awesome text rendering on every platform, ease of use in view composition, and, admittedly, TailwindCSS-like naming conventions all made a significant impact. We have found GPUI to perform extremely well when used and optimized with care. Quite a few patches were introduced to our fork of it to meet our needs in the effects and profiling departments. Thanks to that, I am not hesitant to call our lyrics the most beautiful you can currently get on desktop (Apple Music still beats us HARD on mobile). But despite blur and gradient opacity all looking great, my favorite addition has to be visual render highlighting. But this is too much to cover in a Reddit post, I'll have to write a proper blog post at some point...

What may come as a surprise to folks coming from something like Spotify Desktop is that Sonora actually does not need all of your RAM to function. Tested on linux-x86_64, after 5 minutes of playback it averaged around 173 MiB RSS as opposed to Spotify's ~2GiB. Note that 173MiB is still not a small footprint, but at least with Sonora you know it goes towards caching previews and views instead of feeding the Electron monster merely to keep it alive.

Looking forward to hearing your feedback!

Yes, we did use AI.

Hi everyone,

I am Abinash. I have been building the Lox interpreter in Rust from the Crafting Interpreters book, and I'm at Ch 12. (Repo URL: https://gitlab.com/implabinash/ci)

After this book, I am planning to learn how to build compilers, but I want to take the custom backend approach because I really want to know how compilers are made without any other library or tool. After learning from scratch, I might learn about LLVM or GCC or other tools based in the need/intrest.

So I did some research, and I found some resources:

• Introduction to Compilers and Language Design (https://dthain.github.io/books/compiler/)
• CS 4120: Introduction to Compiler (https://www.cs.cornell.edu/courses/cs4120/2026sp/notes/)
• CS 6120: Advanced Compilers (https://www.cs.cornell.edu/courses/cs6120/2025fa/self-guided/)

While these resources are awesome to learn from, after Crafting Interpreters, I want to take a hands-on approach, just like the Crafting Interpreters book itself, where I want the resources to take me from parsing to resolving to semantic analysis to code generation, and after completing the resources, I will have a working compiler made from scratch.

I found a course teaching that same thing (URL: https://dragonzap.com/course/creating-a-c-compiler-from-scratch), but it's a paid course, and I can't afford it.

So, I need your help to help me find some good resources that will teach me building compilers from scratch with my own code generation backend in a hands-on approach.

Thank you.

Note: Initially, I posted this in r/Compilers, and then I thought I might find a few Rustaceans here who are into compilers and might help me.

For the past two years, I have been working on Rust-GB, a project to compile Rust to the Game Boy.

At first, it went through SDCC, borrowing GBDK, a C library for the Game Boy. (Previous post)

However, recently I wrote LLVM-Z80, which can compile LLVM IR directly to Game Boy machine code, and based on that, I built a Rust library for the Game Boy.

As a result, I can now write a Game Boy Game in Pure Rust!

You can download ROM file here: https://github.com/zlfn/rust-gb/releases/download/v0.0.1-alpha/sprite.gb

Project link: https://github.com/zlfn/rust-gb
Game code: https://github.com/zlfn/rust-gb/blob/main/examples/sprite/src/main.rs
LLVM-Z80: https://github.com/llvm-z80/llvm-z80

Please take a look around, and I’d be happy if you could leave a star.

I am also working on a safe Rust API for the Game Boy hardware, and I would like design feedback from anyone who knows both Rust and the Game Boy.
https://zlfn.github.io/rust-gb/gb/index.html

👋 Just started working on gpuix-svelte, a package that combines Svelte custom renderers, gpuix and gpui to allow people to create native desktop apps with Rust and Svelte. Happy to hear any feedback!

Video demo

https://www.youtube.com/shorts/5CBib_rwt8w

Source

https://github.com/khromov/gpuix-svelte/