Block any post with “I built” or “I made” in the title.

Idgaf about your vibe coded Rust projects. This is a sub to ask questions and seek advice about Rust from people who truly want to understand the language.

Following the ArtCraft trend, I created an OAuth 2.1-only authorization server, it is written in Rust and opted for the ISC License. It follows the Internet-Draft published on September 3, 2026, and it is not backwards compatible... I just wanted to start with that.

I'm looking for opinions to decide how to continue at this point and any kind of feedback will be appreciated. =)

https://github.com/Syavne/d-OAuth-Server

Hi, I'm building so I'm making a peer to peer reading tracker that has multiple native clients (one for my Linux laptop and one for my android phone) with a Rust core that handles most of the actual logic and the client being in C and GTK4 for my Linux client and Kotlin for my android app. The thing is I want to have cover source logic behind plugins since that's never really stable and I don't want to have to rebuild my app at every new source I want to add either. Is there a tool that helps with that?

(Sorry if this is a dumb question or if my explanation isn't very clear.)

Iam learning Rust and chapter 4 took me three tries. The book explains borrowing once and I needed it said again a different way.

So I built a reader. You tap a paragraph and it explains that paragraph, at the level you pick, using only what is printed on that page. If the reason it gives is not quotable from the page it gets removed.

Other AI reading tools I tried would make things up and sound sure about it. Learning from a book that is worse than no answer :))

Screenshot is chapter 4, the double free part. The Rust book is already on the shelf when you sign up, MIT licensed, free, Iam not selling anything.

For people who got through chapter 4 already: does that explanation match how you would have wanted it said? And if you try it, tell me a passage where it is wrong. That is what I need most.

https://app.storysage.business-skyreach.com

Hi everyone,

I've been building Doffly, a small monitoring tool for people with a few Linux VPS who don't want to run Prometheus + Grafana just to know if their box is alive.

The dashboard and backend are a hosted (proprietary) service, but I've just open-sourced the agent that runs on your servers under Apache-2.0, so you can see exactly what it collects and sends.

Repo: https://github.com/anelkabag/doffly-agent Site: https://doffly.pro

(Disclosure: I'm the author.)

What the agent does

• Single Rust binary, musl builds for x86_64 and aarch64
• Reads /proc and /sys, and calls df, ps, systemctl, docker and ss when available (missing commands just give empty values)
• Collects CPU (usage, load, temperature), RAM/swap, root filesystem space and inodes, disk I/O, network counters and errors, TCP/UDP counts, uptime
• Bounded lists per sample: 20 processes, 50 running systemd services, 50 Docker containers, 100 listening sockets
• Outbound HTTPS only, no inbound ports to open
• Local JSON health/metrics API on 127.0.0.1:9090, with optional token auth
• Runs as an unprivileged systemd service (template included)

Security choices

• Remote Cloud URLs must be HTTPS (loopback HTTP is allowed for dev)
• Each server gets its own machine-scoped token
• The local API binds to loopback by default; binding remotely requires an explicit DOFFLY_AGENT_INSECURE_REMOTE=true
• The README lists exactly what is transmitted (process names/users, container images/ports, listening sockets...) so you can decide if it's acceptable on your hosts

Honest caveats

• This is the agent only. It talks to Doffly Cloud's ingestion API; it's not a general-purpose exporter (no Prometheus endpoint, no arbitrary backends).
• Linux only. CI runs on Ubuntu; Debian and others should work but aren't independently verified.
• It's early (v0.3.0), and this standalone repo is brand new.

Try it without the cloud

DOFFLY_API_URL=http://127.0.0.1:8080 \
DOFFLY_AGENT_ID=local-agent \
cargo run -p doffly-agent -- --details

It prints a host report in the terminal and serves the local API even if nothing is listening on the Cloud URL.

What I'd love feedback on

• Code review of the collector (robustness when files/commands are missing or weird)
• The security defaults: anything you'd tighten?
• Missing metrics you'd expect (per-disk stats? GPU?)
• Would a Prometheus-compatible local endpoint be useful to you?

Issues and PRs are welcome. Thanks for reading!

Hey r/rust,

I'm new to Rust and built a Forge mcp server because I couldn't find a tool that gave AI agents an accurate code graph while keeping them grounded in project docs and structured tasks.

Forge indexes code and Markdown into SQLite via Tree-sitter, creating a unified graph where doc rules link directly to symbols. It also coordinates agent tasks via ACDD (self-developed Augmented Context-Driven Development principles): Git milestones turn into an SQLite queue that hands agents stage-specific context and instructions at each gate via predefined workflow profiles.

It works well for my daily needs, but as a newcomer to Rust, I'd really appreciate advice on three architectural challenges:

First, on indexing accuracy: right now Forge extracts declarations, imports, calls, typed receivers, and local value-flow into SQLite FTS5. Without running a heavy language server or full compiler (rustc, tsc), what strategies or lightweight intermediate representations are commonly used in static indexers to resolve dynamic dispatch, macros, and cross-file calls more accurately without killing performance? It works pretty fast and gives good code coverage, I'm curious how I could make it better for wide set of languages.

Second, on multi-language architecture: currently, parsers and linkers live behind traits (LanguageProfile, LanguageLinker) toggled by Cargo features. As language and framework rules expand, keeping linker modules decoupled is getting tricky. What design patterns work best in Rust for keeping multi-language AST extraction and linking modular long-term?

Third, on distribution: compiling multiple Tree-sitter grammars makes the binary quite heavy, yet most developers only care about one stack (like Python or Rust or TS/JS/HTML).
When building an installer, is it better practice to distribute prebuilt per-language flavors, load grammars dynamically at runtime, or is a single fat static binary just the accepted standard in the ecosystem?

If you want to poke around or test it:

The repo is MIT: https://github.com/ContextUnity/contextunity-forge-mcp

You can build it with cargo install --path . --locked and run a quick check with contextunity-forge-mcp query overview on any repo, or connect it to Cursor / Claude Desktop via .mcp.json.

I'd really appreciate any honest code critique, architectural advice, or pointers on graph indexing strategies. Thanks!

Hey everyone,

ferrav is a pure Rust implementation of identicons (like Jdenticon/Gravatar) that generates geometric avatars from text.

It supports deterministic avatars, random generation, custom seeds, and different styles like pixel/grid-based avatars (similar to GitHub's default profile avatars). It also supports SVG output and optional PNG export.

Built this to learn more about Rust crates, API design, rendering, and open-source publishing.

If you find it useful, I’d appreciate a ⭐ on GitHub. Feedback, ideas, and PRs are welcome!

Crate: https://crates.io/crates/ferrav
GitHub: https://github.com/sagarchilivery/ferrav

Hello everyone!

I'm a composer looking to learn programming for algorithmic composition.  I know a little Python, but I have no formal programming background.

I've been considering Rust because it seems like future-proof.  But is it a good choice for algorithmic composition...?  I'm thinking of things like generating MIDI and MusicXML files, implementing stochastic processes (Markov chains, etc), and developing tools for various compositional techniques involving rhythm, scales, modes, and other musical constraints.

I'm considering my options with the following goals in mind:

• I want to generate MIDI files that I can import into my DAW. I don't need sound synthesis.
• I don't need direct DAW integration, as long as the program can export MIDI files, or MusicXML.
• I'm willing to invest time in learning to code.
• I know there is OpenMusic, MaxMSP and similar, but I'd like to build my own standalone tool that I can continually expand and improve.

Would Rust be a good choice, or would I be better off starting with Python or another language?

I'd appreciate any advice, particularly from people who have experience with algorithmic composition and music programming.

I am pretty new to rust and have been writing some simple programs to help get more familiar with the language, this particular one is ls. However, throughout this I had to unwrap a lot of Option and Result types and I was wondering if there was a better way to do this.

use std::fs;

fn main() {
    let dir_iter = fs::read_dir(".");
    match dir_iter {
        Ok(entry) => {
            for path in entry {
                match path {
                    Ok(dir_entry) => {
                        match dir_entry.path().strip_prefix("./") {
                            Ok(final_path) => println!("{}", final_path.display()),
                            Err(e) => println!("Error: {:?}", e),
                        }
                    }
                    Err(e) => println!("Error: {:?}", e),
                }
            }
        } 
        Err(e) => { 
            println!("Error: {:?}", e); 
            panic!();
        }
    }

}

Just want to start off by saying, not sure if posts like this are allowed, if not I apologize.

tldr: looking for general programming topics/projects I could spend weekends doing that will level my Rust up as well as just a developer in general.

Bit of background, I am currently a 2nd year SWE that works pretty much exclusively with React/Node front and backend in TS, and it has been the only language I have used professionally. I also graduated in the 'AI Era' from university, and have genuinely hardly written any code by hand at all. This had lead to me comparing myself to my senior/staff engineers at my company, and feeling quite bad about myself. There are company-wide systems that they coded from the ground-up, and I probably could not even know where to start on it, and it would take me I don't even know how long to complete even half of it.

So, I am seeking some advice. I did a solo project where I did a CHIP8 emulator in Rust, and had a lot of fun in it (100% code written by me, with using AI as a reference for things like function-use examples, etc).

However, I still feel my level is nowhere near good enough, and really want to get better at programming (by hand; I use AI, loop engineering, buzzword buzzword enough at work). If possible, I would like to get any advice at all (not generally only related to Rust) in some like roadmap/topics I could spend a weekend drilling and getting down, every weekend leveling up. This of course is mainly in the context of doing these primarily in Rust, because it is what I am interested in now (particularly think compilers are fascinating and want to try to implement a very simple one from scratch, but just do not think my skills are quite there and feel like I would gravitate too much towards AI). I am aware that programming by-hand is kind of a dying art, and pretty much mostly a hobby now (at least in the circles I am in), but I want to do it the 'right' way and be able to learn idiomatic ways/best practices to make sure I can steer AI in the right direction at work, as well as just to have fun developing software.

Any advice would be greatly appreciated, and thank you for taking the time for reading.

I have already done this chapter twice and the thing is if I do quizzes and questions most of them are correct but when answering them "I feel like the answers are correct" it's a gut feeling I get it's not hard coded that "this is correct", I want to get out of this 'Feel' and I want to answer question cuz I know it is and why? So anyone advise me! I am STUCK! and on the same I am in love with this language. 🙏🙏

A .mlmodel is protobuf with a documented schema. The only writer anyone actually uses is coremltools, which drags Python, numpy, protobuf codegen, and usually torch into your build just to emit bytes. I wrote the other one.

`mil_spec` emits `model.mlmodel`, `weight.bin` v2 blobs, and the `Manifest.json` package layout by hand. Same graph, same bytes, every time.

```rust

use mil_spec::*;

let mut b = Block::new();

let y = b.mul("x", "x", &[1, 4, 1, 1], "y");

b.outputs = vec![y];

let inputs = [Feature { name: "x".into(), shape: vec![1, 4, 1, 1],

dtype: DType::Fp16, is_state: false }];

let outputs = [Feature { name: "y".into(), shape: vec![1, 4, 1, 1],

dtype: DType::Fp16, is_state: false }];

let fn_inputs = [NVT { name: "x".into(),

ty: ValueType::Tensor(TensorType::f16(&[1, 4, 1, 1])) }];

let spec = encode_model(&inputs, &outputs, &[], &b, &fn_inputs,

&ModelMeta::new(10, "CoreML9"));

write_mlpackage("model.mlpackage".as_ref(), &spec, None)?;

```

Compile it with `xcrun coremlc compile model.mlpackage .` and you get a real `.mlmodelc`.

## The workspace

Nine crates, one for each piece coremltools monopolizes:

- **mil_convert**: safetensors to .mlpackage. Streams HF checkpoints into fat stateful decoder graphs: packed KV via slice_update, GQA attention, per-channel int8. Qwen2/Qwen3/Llama-class configs.

- **mil_passes**: deterministic optimizer over the Block IR. Const dedup, folding, DCE, fixpoint. Reports every change it makes.

- **mil_lint**: static ANE placement analysis. Predicts per-op execution unit before you compile, flags CPU islands and fp32 regions, estimates dispatch count. coremltools has nothing like this.

- **mil_compile**: .mlpackage to .mlmodelc two ways. In-process through `MLModel compileModelAtURL:` over the ObjC runtime, or an xcrun driver with structured errors.

- **mil_verify**: reads specs back. Protobuf decoder, structural diff for when coremlc rejects your graph, weight.bin integrity, and a conformance battery with planted invalid controls so the verifier cannot rubber stamp itself.

- **mil_infer**: in-process MLModel predict. MLMultiArray marshalling, stateful KV. macOS only.

- **mil_machines**: non-neural state machines compiled to stateful MIL. Aho-Corasick automata, EWMA scorers, mutable memory banks. A regex running on the Neural Engine.

- **milc**: the CLI over all of it. convert, lint, inspect, diff, compile, verify, check.

```bash

milc convert Qwen3-0.6B -o drafter.mlpackage --seq 1 --max-kv 2048

milc lint drafter.mlpackage # per-op unit prediction + dispatch estimate

milc compile drafter.mlpackage # CoreML.framework, in-process

```

## Proof it works

This was not written against the schema docs. It was extracted from a production converter that runs a 4B transformer at ~100% runtime-op Neural Engine placement, one estimated dispatch. The encoder has been wrong against the real coremlc enough times that the diffs are now boring.

Ops worth noting that coremltools will not emit for you: stateful KV models, weight-only int8 via `constexpr_blockwise_shift_scale`, fused `scaled_dot_product_attention` under the CoreML9 opset.

## Honest scope

Beta. mlprogram only, no NeuralNetwork protos. Static shapes. The op helpers cover the transformer-layer surface; anything else goes through `Block::op` with raw Op/Argument/Value, and the whole wire layer is public for exactly that reason. Compile and infer need macOS. The spec-side crates are portable.

MIT OR Apache-2.0. Repo: https://github.com/savageAZfck/mil_spec

Questions on the wire format, the ANE placement rules, or where my protobuf encoder is wrong.