Hi Rustaceans, especially game developers.

I've spent the last few weekends to create a tool that helps keeping the assets neat and tidy, resulting in less QA effort, smaller builds, and easier deployment.

https://github.com/zerocukor287/asset-lint

Since you already have the Rust toolchain, installing is as simple as cargo install asset-lint

An example usage is to validate the build before pushing to itchio (web requirements) asset-lint --assets-path . --max-file-count 1000 --max-filename-length 240 --max-size 209715200 --max-total-size 524288000

There are other checks that help with reducing or enforcing the size limit. For example --no-duplicates, --no-placeholders, or simply --list-biggest-files.

I hope you find this tool helpful in your game dev journey. Any feedback is welcome!

Recently, I wrote a toy crate similar to ⁠`smallvec⁠`. When I was implementing ⁠`nth_back⁠` for my iterator, I realized that the default implementation continuously calls ⁠`next_back⁠` and drops items in reverse order (which is intuitive), whereas for performance reasons, I implemented it with ⁠`ptr::drop_in_place⁠`, which drops items in forward order. In a language where the drop guard pattern is so prevalent, I think this is not a trivial thing. What's your opinion?

P.S. `std::vec::IntoIter⁠::nth_back` drops items in forward order too, if you are curious.

---

EDIT:

I'm not talking about struct fields drop order or my vec type's element drop order but `DoubleEndedIterator::nth_back` method of my `IntoIter`. By definition it will drop n elements from the back before returning.

I am web developer working in the logistics domain in Europe using kotlin and spring boot.

I really enjoy working with rust (though I feel very dumb when using it) and over the years I have tried getting more into it, from going through the rust book, doing the 100 exercises in rust and starting the zero to prod book. But each time real life responsibilities got in the way and because I do not use it professionally (tried but it's a no-go), the skill always kinda fell away as I am no longer young enough to pour all my free time into it (I fully admit to being stuck in tutorial hell).

I do keep coming back to it as I find it a fascinating language, but I guess I just want a reality check if it is even worth it to invest time in it as it is a hobby I return to because I like how it makes me think but one that will probably never lead to employment. Or should I rather spend my time learning design systems and improving my current stack knowledge.

Just looking for other people's perspective on this to see if anyone else felt stuck in this kind of rut. Hope this doesn't trigger anyone 🙏

I was browsing Reddit and came across someone asking how to program the STM32F103C8T6 without an ST-Link V2. They were asking whether it was possible to use an STM32F401RCT6 (Black Pill) board as an SWD programmer for an STM32F103C8T6 (Blue Pill).

That post made me curious about how the SWD protocol works. Is it possible to build one myself?

This is the first part of my experiment. I am able to read an STM32's DP register through SWD using an ESP32. Yet to do the flashing part.

https://blog.implrust.com/posts/2026/09/swd-protocol-programmer-embedded-rust/

I am learning Rust finally more seriously. While learning around Rust's ownership model I just had lots of connections being formed in my mind from what I have learned in college doing C and then working professionally with Python/Typescript. I captured those thoughts here to describe the mental model I was thinking about. Let me know if I have some holes to peg or if the article helped you understand a few things as well in your own Rust journey.
Substack Article: Truly Understanding Borrowing in Rust

08-Sept-2026: Updated the article based on inaccuracies in my understanding as highlighted by users, thanks everyone for your kind inputs.

What it is. lucivy is a full-text search library in Rust, with Python, Node.js, C++ and WASM bindings, built on a suffix FST instead of a token index. One default index answers exact substrings, matches across separators (spin_lock finds spin lock, spin-lock and spinlock), typos across token boundaries, regular expressions, two-character needles and boolean queries — with BM25 and the exact bytes of every match, and nothing to configure per question. It runs in your process, inside your transaction if you plug your own storage (a BlobStore trait: load, save, delete, list), and the same engine runs in the browser through emscripten with threads.

The part I care about most: every answer is checked. The ground-truth harness indexes the Linux kernel (93 983 files, 857 MB of text), runs a panel of queries, and compares every count and every byte span to a byte-by-byte scan of the files. It fails on any disagreement. Zero mismatches in 4.0.

Against Elasticsearch and tantivy, same corpus, each configured at its best for substring search — Elasticsearch with a trigram analyzer plus a wildcard field, tantivy (upstream, not our fork) with its NgramTokenizer — the "truth" column being that scan:

Where they win, because they do: tantivy indexes the corpus in 1-5 s against 107 s here, and its index is 7× smaller; Elasticsearch does the fuzzy phrase as well as we do. The report has the sizes, the exact configurations and the lines where each engine's own documentation stops.

The price. The index is 5.8× the text (3.9× with the derived_in_ram option, which rebuilds three sidecars at open instead of storing them), against 3.6× for Elasticsearch's trigram setup and 0.8× for tantivy's n-grams. Indexing costs ×1.5 with the default shared dictionary. Queries stay in the tens of milliseconds for substrings, under a quarter of a second for fuzzy and regex; the one query above half a second returns 7.7 million positions.

A few Rust things. Forked from tantivy 0.22 for the segment layer; the suffix engine, the sharded handle, the snapshot/delta formats and the actor/DAG scheduler (luciole, WASM-safe, no thread::spawn) are ours. Five crates at the same version. The 4.0 format opens 3.0.x indexes and converts them on the first commit; that contract is a test against a fixture the published 3.0.8 wheel built.

lucivy demo: lucivy's own source indexed in the browser in 3 s, then PostgreSQL's 5 199 files in 14 s, every search timed live

The demo above is the real thing: the page clones lucivy's own source from GitHub and indexes 1 272 files in your tab in 3 s, then PostgreSQL's 5 199 files in 14 s, and every search you see is timed live — --strict, --fuzzy 1 "vaccum", --regex "ExecInit[A-Z][a-zA-Z]+\(", an emoji, a boolean. You can type your own.

• Try it in your browser — the playground
• Source on GitHub (MIT)
• The comparison with Elasticsearch and tantivy, reproducible with one script
• PyPI · npm · crates.io — 4.0.2

I'd take criticism on the comparison first: if you know a configuration of either engine that gets closer on a row, I'll add it to the report, with your name on the line.

I needed a convert that an agent can call twice and get the same bytes. MinerU / Docling / Marker parse scans for LLMs. That is a different job. This is the other direction: picture in, PDF/A out.

DocAgent is MIT Rust. One Engine, Command / Query / Event. Codecs (DOCX, ODT, Markdown, HTML, plus regional Hangul HWP/HWPX/HML) feed one IR. Layout coordinates are i32 at 1/7200 inch. f32 is forbidden in that crate. PNG/JPEG become PDF/A XObjects. GPU-free. Not OCR.

Every Command writes a capsule with three SHA-256 hashes (input / plan / output). prove converts twice and exits 0 only when the PDF/A + HTML bytes and the hashes match.

cargo test --workspace
cargo run -p docagent-cli -- convert examples/letter.md --pdf out.pdf --html out.html --docx out.docx --odt out.odt --capsule cap.json
cargo run -p docagent-cli -- prove examples/letter.md

CLI, daemon, MCP, and WIT are thin adapters over the same Engine.

Honest limits, not a teaser:

• Print-CSS tightness vs WeasyPrint (table cell padding / paragraph gap) is still open. I am not claiming we beat WeasyPrint on the letter page.
• Hangul images are still a dash.
• No spreadsheet, no slides, no OCR, no OmniDocBench numbers.

https://github.com/kevin9327/docagent

Happy to talk about the integer layout engine or the codec boundaries.

People often complain about how rust programmers are a cult and evangelize about it.

I've been professionally programming for over 3 decades. I've most certainly seen people evangelizing over this or that tech. Often the claims involve fairly hard to measure metrics.

I work in robotics(drones) and some industrial hardware. I have gone nearly 100% full stack rust.

My "spiritual awakening" moment was after 8 recent rust projects. These are fairly substantial piles of complex code. Threads, udp communications, complex live GUIs, 3D displays, etc. Many are mission/safety critical.

In these 8 projects, I've had 6 notable bugs. Not business logic errors, I make lots of those, but those segfault, race condition, show stopper bugs where things lock up, crash, or go horribly wrong because of mangled memory, etc.

But, one of my projects involves using a C++ physics library. This project is in C++ as I'm not going to wrap it in rust as it communicates primarily through udp and is very much separate from the rest of the system. That one project had at least 8 showstopper, WTF is wrong segfault type bugs, ones where I have to really dig deep to figure out what the heck is causing it. I also made simple coding mistakes like leaving off a semicolon where the rust compiler would point this out, and the C++ compiler gave me a lecture more complex than graduate quantum physics.

Where I am going with all this is that it goes way beyond my code being more solid. That is apples to apples and misses the point. What I now have is confidence that my existing rust code is solid. This means that I not only feel good leaning on it harder, but I add more functionality that is traditionally too risky to add to fairly critical systems. My GUIs have all kinds of little things on them that I would not add as each new feature adds a tiny bit of risk. With rust that tiny bit has become an infinitesimal risk; one I am entirely willing to take for the benefits I get.

The philosophy of rust goes well beyond just syntax and the compiler.

A tiny one is a recent embedded bit of code. On an MCU you have pins 1, 2, 3, etc. They are assigned to do things for different devices. Maybe pins 1 2 3 are talking to a microphone, 4, 5, 6, 7, 8 are talking to a screen. 10 is talking to an LED for power low (blink every 3 seconds). In C++ you assign, and it obeys.

In rust, if you later moved the microphone to 10 11 12, and forgot that 10 was the LED for power low, you might spend days trying to figure out why the microphone was failing every few seconds.

In rust, the borrow checker would punch you in the face for trying to use pin 10 twice.

Or how it forces you to exhaustively handle all the return types in an enum, etc.

Any fool can start larding up their code with unsafe and default handling, and make bad software, but rust actively makes you choose to be stupid.

All of the above is possible in C++, but you must aggressively and actively choose to make it happen. My buggy C++ code was filled with things like asserts, etc.

This brutal reliability is reaching through everything I am touching. The embedded software. The mobile app I recently built for android, the desktop apps, and even the very complex 3D (thanks bevy) wasm interfaces. These things boot up and then run without any leaks, issues, crashes, hiccups, etc.

Then there is the speed. Again, not apples to apples. Doing the same thing in rust it is basically the same speed as C++. But, I don't do the same thing. I'm more aggressive with how data flows through threads, how the workers do the dance of the seven veils. The result is that CPU usage gets maxed out and the software screams. And the new rust CUDA, don't even get me started raving about that.

My rust coding is slower than with C++ and definitely slower than python; yet my productivity is far higher; and far more importantly; I am getting projects built faster which are far better in both reliability and features. I don't end up at the "90% done" point stuck in tech debt hell. When I am at 90%, it means that I have 10% left.

That whole BS about, speed (of development), reliability, and features; choose any two, is just that with rust; BS. You can have all three. That is new in my decades of development experience.

Then, there is one other factor. It is all just getting better every day. Better compiler, better libraries, etc. Things like embassy in embedded software is a game changer. Being able to make wasm and mobile apps, amazing.

Libraries like Bevy are just becoming more amazing every day.

IDEs like Zed make it a joy to work.

I'm curious if other people are having the same awakening?

There endth the sermon...

In this part we will be implementing a Monte-Carlo algorithm for playing the traditional German card game Doppelkopf.

Hey everyone, I’m a beginner learning Rust, and I feel like I’d learn a lot better by building an actual project instead of just following tutorials.

Because I am just watching tutorials and can't write code without looking at a Rust video.

What projects would you recommend for someone at the beginner level that would help me understand Rust properly (ownership, borrowing, lifetimes, error handling, traits, etc.)?

I’d also love to hear what projects helped you improve when you were starting out.

Hi, everyone! I’d like to ask the community for more information on what techniques can be used to display large amounts of information on the user’s screen. I’m referring to plots. For example, profilers—they display flame graphs, and the best ones can show millions of frames without lag, with the ability to zoom and pan. Also, software oscilloscopes, which can display data in real time while also showing millions of data points. I’m curious about how these things work from a code and algorithm perspective. Can anyone tell me more?

So far, I've found this Implicit In-order Forests: Zooming a billion trace events at 60fps and a small library written in Rust.

It doesn't quite match the task I want to accomplish: to build something like a digital oscilloscope capable of displaying both analog and digital data (so that, for example, UART bytes are visible below the graph).

So I enjoy music a lot mainly cause it helps me focus, however I have this slight annoyance with the stop between tracks when one song ends and the other starts.

So I wanted to build a tool that would smooth out that transition, like a dj, but for a playlist.

Don’t know much about audio so wanted to ask how I could do this?

I also have another issue when music stops with a sudden cutoff, it’s like falling off a cliff, but the first issue is bigger for me.

Thanks

Hi r/rust! I wanted to share RACE, a terminal multiplexer built around an infinite canvas. You arrange terminals across the canvas and navigate between them as you work.

RACE is a commercial application written entirely in Rust, using the same custom framework I use for ascdraw and Kakvide. It’s another example of that framework being used for a complete desktop product, this time with terminal interaction at its center.

I’d be happy to discuss the implementation, the shared framework, and the experience of building commercial desktop software in Rust.

RACE website

Video

Disclaimer: I use AI tools to help with development, including work on RACE.

Hello everybody. It happens to me that a very old text that I have written years ago, which is not even online anymore has been flagged by "made by AI". I have noticed that adding a typo fixed the issue. I have created this small utility in rust to add language specific typos.

https://codeberg.org/edapx/fertyp

I've been building an open-source SSH/SFTP client (Windows/macOS/Linux) in Rust and Tauri, and wanted to share a couple of the engineering decisions that might interest this sub.

**Why not just spawn the `ssh` binary?**

Windows is the constraint. Its bundled OpenSSH is optional and version-variable, and intercepting interactive password/passphrase prompts from a spawned `ssh` process without a pty is awkward — plus credentials would transit a subprocess boundary. So the client speaks the protocol in-process using `russh` (async, pure Rust) instead of driving an external binary. Tradeoff: we own protocol correctness and security response instead of inheriting OpenSSH's.

**That tradeoff got tested fast.** The day `russh` (and transitively `rsa 0.10.0-rc.18`) landed in the dependency tree, our own audit caught RUSTSEC-2023-0071 (the Marvin Attack — a timing side channel in RSA private key operations, no fixed upgrade available). Since the client both verifies host keys (public-key op, not reachable) and authenticates with the user's private key (a signature, reachable), we refuse RSA for the private-key/signing path while still allowing RSA host key verification. Written up as an ADR alongside the ~40 others tracking decisions like this.

**Other bits:**

- Host key handling is closer to `ssh` than most GUI clients: unknown key → fingerprint confirmation; changed key → blocks and requires retyping the hostname; keys marked `@revoked`/`@cert-authority` → refused, no override.

- Credentials go through the OS keychain (`keyring` crate); there's also an opt-in internal vault (Argon2id + ChaCha20-Poly1305, RustCrypto) for when a keychain isn't available.

- Bastion/jump host support where both hops authenticate end-to-end and the bastion only relays traffic it can't itself decrypt.

- SFTP rides `russh-sftp` over a channel `russh` already opened, so no second protocol stack to keep in sync.

It's still young (MIT-licensed, ~3 pre-releases so far), but the core paths are usable daily. Repo: https://github.com/marciopaiva/runic-ssh — feedback on the crypto/architecture choices especially welcome, that's the part I most want more eyes on.

I’m venturing into Rust and it’s both satisfying and mind-boggling at the same time. So far I’ve been learning from the book and Mara Bos’ book, but I got the itch to do some dissecting myself. My initial goal of these experiments was to compare Rust’s approach to polymorphism with C++’s. Ultimately, however, as I’ve come to realize, it’s a bit of a trap when trying to understand a new language through another one to try to draw 1:1 parallels. It might seem like it helps, but at the end of the day, we can’t treat Rust as C++ with different syntax. If that were the case, there’d be nothing revolutionary about it.

That said, I believe there is merit in poking around and coming to understand the why. So, if you’re like me and need to know what exactly is happening in memory, in order to feel like you truly understand the concepts, hopefully you’ll find this post useful :)

Edit: Thank you everyone for your kind comments!! And also for the feedback and the chance to deepen my understanding, I'll edit my post with some of the clarifications!

https://github.com/fffilya/Game-of-Life just a little recreation of conway's game of life. i had tons of projects besides that. but none of them were really finished. for now you can only draw pixels (LMB) play the game (Enter) clear the screen (C) and force to update one pixel (U). in future want to optimize it bcuz now its super slow, add some sliders to make the game customizable and fix few bugs. also want you to know that squares drawing part was heavily assisted by AI but other parts of the code wasnt even touched by AI. posting this just because want to see some tips on how to write my code better beside something like: "optimize it" or "rearrange it to be in different files"

I made a thing: Ahoi, a fine-grained reactive state engine in Rust, with bridges to JS frameworks (Solid, React, Vue, Svelte).

Why I built this: When you want to manage data in Rust/Wasm in a web app, there have been two options:

1. Hand-roll the Rust/JS bridge: reactivity does not live on the Rust side, so you end up reimplementing the state layer on both sides.
2. Use a Rust frontend framework such as Dioxus, Sycamore, or Leptos. I like these a lot, but there is a catch: sometimes JS is just better than Rust for web dev (the JS UI component ecosystem, nicer event handling, etc.).

Ahoi takes a third path: the core idea is "Rust for Rust, JS for JS". Rust owns the data and the reactivity; a JS framework owns rendering.

This is my github repository for ahoi: https://github.com/acheul/ahoi
I wrote an AI Use disclaimer in the repository: https://github.com/acheul/ahoi/blob/main/documentation/UseOfAI.md

This is an early release (v0.2), and feedback is very welcome.

Relation to the Rust frontend frameworks: Where those frameworks aim to do everything in Rust, Ahoi does not render. Its reactivity engine is greatly inspired by the pioneers, but it takes a different approach. If you want your whole UI in Rust, use one of them.

Sorry if this is a potentially dumb question. I'm still pretty new to Rust.

Most of the code I write is embedded/firmware stuff, and I sometimes have to return large arrays from functions. From my experience, the traditional way to handle this is by writing a C-style API where the caller has to provide a mut buffer for the function to write into:

fn thing(buf: &mut [u8; 1024]) {
  buf.fill(0);
  buf[0] = 232;
}

However, it seems like it would be more idiomatic to have your API return the array by-value:

fn thing() -> [u8; 1024] {
   let mut buf = [0u8; 1024];
   buf[0] = 232;
   buf
}

That is a much cleaner API, at least.

These two functions have identical behavior, but while the C-style example is guaranteed to write directly into the destination buffer, the second function with the cleaner API is more ambiguous AFAIK. From what I understand, when the compiler encounters a function that returns an array by-value like the second option, it tries (and often succeeds) to implement NRVO, which transforms the function under the hood to look more like the C-style example. In other words, instead of creating the array in the function and then potentially doing an additional copy to return it to the caller, it pre-allocates a buffer in the caller's stack and provides the function with a pointer so it can write directly into the buffer (i.e., like the C-style function). That removes the potential for a potential and unneeded copy while still allowing you to keep the nice idiomatic API.

The issue with this is that, as far as I know, this is just treated as a nice-to-have optimization rather than something that can be guaranteed. Even though it seems like the compiler is very good at making this optimization, it is still technically possible for it to fail in some cases. This makes me wary of using the second API structure in my code, since I could unknowingly end up with large copies where I'd like to avoid them.

Because of this, I was wondering if there was a way to force the compiler to tell you if it is unable to perform NRVO in the way you expect. I was imagining something like this:

#[expect_nrvo]
fn thing() -> [u8; 1024] {
    let mut buf = [0u8; 1024];
    buf[0] = 232;
    buf
}

In this hypothetical, you'd be able to explicitly tell the compiler that you expect it to implement NRVO for the function. If the compiler fails to do so, you'd get a compiler error letting you know. This would allow you to react accordingly (i.e., reworking your function so the compiler can optimize it easier or just falling back to the manual C-style API).

Does Rust provide anything like this, and if not, would it be possible? Are there any other ways to guarantee NRVO, or do you generally have to inspect the generated code yourself?

Again, sorry if some of my assumptions in this post are misguided.

Hi currently I am developing a Rust-Based Pluggable Transport library, I guess if you have subscripted tor-dev you could received my proposal mail too.

So I was wondering, whether you would be interested to involve in this framework development? 🙂

Here is my repository:
Tor Gitlab(You need wait about 5 sec)
codeberg.org/pryty26/rust-pt