Hi fellow Rustaceans 🦀,

I was tired of the heavy reliance on NVIDIA/CUDA for local AI generation, especially since I run an AMD RX 580. To solve this, I decided to build my own inference engine from scratch using Rust as the core orchestrator.

How Rust made this possible: The backend is a heavily modified C++ Vulkan environment, but the entire lifecycle, memory management, and routing are handled safely in Rust.

FFI & libloading: I used libloading to dynamically bind the Vulkan .dll.OnceLock for VRAM Safety: To prevent massive VRAM leaks and crashes when switching between image generation (Flux) and video generation (Wan 2.1 I2V), I wrapped the dynamic library load in a

OnceLock. This ensures the .dll is statically loaded into memory only once, allowing Rust to safely spin up and tear down the Vulkan context (sd_ctx) per thread without ever reloading the binary.Concurrency: Rust's fearless concurrency handles the background NLP processing (via a local LLM acting as a router) and safely passes the extracted directives directly to the Vulkan C-pointers.

It's completely open-source. You can check out the repo here:https://github.com/Yanko0615/Xyron_Vulkan_Core

I would love to hear your thoughts on my FFI implementation or any tips on optimizing the unsafe blocks!

This is less an announcement of capability, than a call for timers and tuners. I want a solid ai/tensor development stack in Rust. I'm a big fan of burn, and I'm trying to put effort into moving us towards that world.

I've been developing bunsen (tomorrow's burn problems today!) as a front-runner common library for extensions to the burn tensor ecosystem which aren't solid enough yet for the core.

A big part of that has been porting existing pretrained model families; and working to modularize their internals into reusable components, strong tests, and flexible rust-oriented configs.

I've been working to port a number of modern ASR (automatic speech recognition) models to bunsen; and wire up the pull/cache/load pathway for several ASR families.

bunsen-asr is a binary crate released against the bunsen library, against the burn library, showcasing drivers for these ASR stacks.

Currently, this has support for:

• whisper - openai public models through turbo, huggingface loads.
• qwen3-asr - qwen3-asr public models, phonon-1, huggingface loads.
• parakeet - nvidia public models, phonon-2, huggingface loads.

But it's slower than the released pytorch-based asr tools. Weights load slower, some internal buffering is worse, probably half a dozen tiny issues I haven't found yet.

The core burn team is very busy with GPU correctness; and edge utility stuff. I'm targeting what comes next: tensor shape contracts, path-based parameter selectors, complex sub-graph combinators, and now, timers.

I'm looking for approaches to make asr calls through this toy binary faster; and to instrument it in ways which are useful for determining where to work.

• should we implement `tracing` + otel on ... everything?
• when downloading weights, should they be loaded from source, then re-saved as burnpak files?
• how do we time repeated chunk calls? histogram on call delay?
• etc.

Do correct me if Im wrong, but I recall that one principle that was used in the development of Rust was to only use tried and tested research material when choosing what to implement. Given we’re more than 10 years out from Rust’s initial development, I’m curious what research ideas have matured enough to either

1. Be added in future editions/versions of Rust, or
2. Be used in whatever successor language might come that follows much of Rust’s philosophy around development.

This is all basically one massive ask about interesting developments in programming and type theory, since I’d like a few new rabbit holes to fall down.

P.S. whatever successor language does come around, I hope it also cultivates a community that takes ergonomics as seriously as performance, because that, even more than memory safety or other aspects of the language, is why I pay attention to this language and ecosystem.

I recently wanted to compile something for a bevy game I was messing around with, then cargo looks me in the eyes and tells me I need to compile hundreds of dependencies, all for the end result to be 30 mb? I was wondering if there were any systems like a .dll for rust? I understand that you would lose some type checking, but I think that could be solved just with a type definitions segment towards the start, then a functions table of all the code for the system, is this something that would work, or am I oversimplifying a major intentional design choice in rust?

Hi, i just wanted to share my project for ImGui that also uses Rust, you can create windows with imgui just by drag & drop no code, exporting to Rust code or applying it into your project : D
https://kavro.pro

For anyone unfamiliar with Cornucopia or sqlc, they generate type-safe code from plain .sql files.

Large scale physics, using Bevy, though Bevy themselves suggest using Godot, whereas I was told that UI-based engines tend to be more annoying and reduce motivation to work on the project, which I agree with, but the inspiration game (Terratech) suffers from outdated libraries and such, and killed the game which I don't want to happen here.

(Competitors in the space, Trailmakers, 2017, still relevant, Scrap Mechanic, 2015, still more relevant than TerraTech, 2016, it was the studio's first game.)

Note that all of these are open world and varying numbers of physics collisions.

Background stuff aside (can you tell I have ADHD) The structure of rust feels overwhelming. I know a tutorial can help but I want to get advice from people who daily drive this or may have switched from the more OOP-heavy C# and Java into the DOD-oriented space. It feels illegible compared to Lua and Java, and Java is already a bit messy in my opinion. I AM still a novice, but I get basics, though stuff like Arrays in java are weird, and I don't get things like why and when you would have Java return Null? You can kind of see where my knowledge is. Lots of hours ingame and poking at game systems, not too much writing myself, though I am capable of it, made a couple of Lua mods.

Should I skip Bevy and go Godot with custom ECS implementation and skip their gameobjects? I really don't know enough to make an informed choice and one person understood my issue best:

"Everyone who says this is premature optimization doesn't understand your goal; Your game IS optimization, and bad architecture isn't free."

So hopefully this explains enough about my situation to get good replies.

TLDR;
I like Lua and I can do Java but Rust is foreign and overwhelming and I'm scared of the compiler :(

I'll be doing a quick silly gun game to get used to the tool.

I don't have delusions of doing this quickly, I just want to know I'm not wasting my time. I don't want sunk cost fallacy to be a potential issue by starting with an inherently flawed system, or something I simply won't be able to use effectively.

Should I use Rust in Godot or Bevy, or should I skip rust entirely and go with an ECS in a language I'm familiar with?

I've been building a sandboxed microVM execution engine to test/benchmark backend architectures under heavy load.

I set up a stress test: process a synchronized burst of 10,000 out-of-order payloads with a strict 128MB memory cap and hidden concurrency invariants.

Right now, the fastest verified execution time on my engine is 34ms using Rust. I feel like it could be pushed under 30ms, but I'm maxing out my own lock management skills.

Is 34ms actually a good baseline for this, or am I leaving performance on the table? If anyone wants to try and beat the 34ms record to test their concurrency skills, let me know and I’ll drop the sandbox link in the comments.

I’ve been building an isolated microVM execution engine designed to benchmark actual production constraints (latency, memory limits, thread safety) instead of just testing standard algorithms.

I just deployed a new benchmark quest: process a burst of 10,000 out-of-order webhooks under a strict 128MB memory cap, with hidden concurrency invariants meant to trigger race conditions.

Right now, the top verified execution is 34ms.

I wanted to see how [Go / Rust] handles this specific adversarial load compared to the baseline. If you want to stress-test your concurrency chops, you can run your code against the microVM runner here: https://meritual-meritual.vercel.app/quests/2c351db0-0ebf-4c47-a49d-db0ae3637d85

Warning: The test suite will fail you instantly if your lock management isn't flawless. I’ll be monitoring the ledger to see if anyone claims the #1 spot today.

Here is a video I made to explain the various IPC patterns in Rust.

The lesson is that just because a communication technique is newer doesn't mean it's necessarily the right one.

For example, for my custom coding harness, I went with Unix Domain Sockets, and the speed and reliability are through the roof for that particular use case.

Also, I've started making interactive videos these days, and feedback is more than welcome.

Hey everyone,

My project Indicatrix kept growing, and I wanted a way to verify its Slint UI end to end without clicking through it by hand. The result is slint-harness:

• runs your real app headless on Slint’s testing backend
• scripts whole flows as scenarios (open a file, set values, press buttons, wait for results)
• checks the outcome and takes screenshots along the way
• writes a pass/fail report (Markdown + JSON), so it fits into CI

In Indicatrix it has already caught several end-to-end bugs that unit tests missed, and after every app update I use it to regenerate all the screenshots for the website, so they never go stale. My smaller project z-stackr uses it too.

Repository: https://github.com/suitable-name/uiprobe

Full disclosure: I built it with AI assistance. Twenty years ago I’d have had the time to write it all myself. Today I have the experience to know what to look out for when redirecting it. If you have an issue with AI-created stuff, nevertheless it could help you or not, this project just isn't for you, but that's ok :)

Have fun!

Edit:

It's also published on crates.io, so you can easily import it via the dependencies.

My first post on this was removed for being too much of a code dump, which was fair. It was some code and pointers to where to find the solutions. Sorry about that, all. Lesson learned, so this time it's the problem and a question.

Leptos leaves HTML comments in the page to connect the server's HTML to the wasm. htmx's parser drops them, so the island can't hydrate.

Some 30 LoC JS glue keeps the comments and wakes the island. But Leptos never frees an island it woke, so when htmx removes it, its state stays in memory.

About 200 lines of Rust keep every woken island's state. Every 30 seconds they check which islands are still on the page, and free the ones that are gone.

It works, any other solution or idea?

Today I ran cargo update only to realize that all zip crate versions were yanked and a lot of new 9.0.x versions were created. I don’t see any CVE or anything that would explain such a drastic move. There isn’t anything on the GitHub page about it as well.

Does anyone know what is going on there? Is that considered a best practice?

Cargo compilation model only works if you are creating a monolithic executable or a shared library, and assume all other system libraries somehow get built, or are just random binaries from the internet.

This is not a good state of affairs, any non rust app you have will be orders of magnitude larger because each dynamic library you link you are statically linking all crates.

rustup is a toolchain in binary format, in which it is literally just "random binaries from the internet", which is not ideal at all. You as a developer have an idea what the heck are you doing when targeting a platform or writing software, I can guarantee you, most rust devs don't even know what libc version their app links against.

All these things make the language filled with slop projects, and this is not a good thing.

I am new to rust and I would like to build something. I came across this https://dioxuslabs.com/ and it seems it is a fullstack framework with declarative style on building functions.

I am comparing frameworks with rails actually. Convention over configuration is good way on building stuffs quickly.

Any other opinions or suggestions?

Two years ago, DARPA announced the TRACTOR program, which aims to automate the translation of legacy C code into Rust (original announcement on Reddit).

I recently wondered whether there had been any updates, and discovered that the program's first report was published back in February. Sharing it here for anyone interested in the project's progress.

The project website, where I found the report: https://www.ll.mit.edu/r-d/projects/translating-all-c-rust-tractor-benchmarks

was cleaning up my mac and found one projects target folder sitting at 13 gb. debug and release builds, incremental cache, deps for every feature combo i ever tried, all for one project

things that actually helped. `cargo clean` in projects youre not touching right now is the obvious one, it all rebuilds when you come back. cargo sweep is nice if you want to keep recent stuff and drop artifacts older than a few days, `cargo sweep --time 14` for example. and if you have a lot of small projects, pointing `CARGO_TARGET_DIR` at one shared folder stops every repo from compiling its own copy of the same deps, though parallel builds can block each other on it

to see whats there, `find ~/code -name target -type d -prune -exec du -sh {} +` works, just swap in wherever you keep projects. heads up it also catches maven target folders if you have java stuff

curious what other people do, especially anyone with a big workspace

Previous discussion on the miscompilation that was fixed: https://www.reddit.com/r/rust/comments/1wzn34d/1990_miscompilation_with_ffi_bool_return_type_on/

#[derive(Debug, Clone, Serialize, Deserialize)]

pub struct MailboxEnvelope {

pub recipient_id: String,

pub ephemeral_pub: String,

pub ciphertext: Vec<u8>,

pub nonce: String,

pub created_at: u64,

pub message_id: String,

pub attempts: u32, // delib. excluded from AAD so retries don't invalidate ciphertext

}

impl Drop for MailboxEnvelope {

fn drop(&mut self) {

self.ciphertext.zeroize();

}

}

I’m working on a small Rust mesh-protocol project (GhostWire: libp2p, ChaCha20-Poly1305, Kademlia offline mailbox delivery). In this sealed type, I bind AAD to immutable fields and exclude attempts so retry writes don’t reseal offline ciphertext.

The thing I’m unsure about is zeroization discipline:

Is manual Drop zeroization enough once Clone creates another allocation?

For Serialize/Deserialize temporary buffers, should I treat the Vec<u8> canonical copy as the only zeroized target?

Would secrecy::SecretBox / zeroize-wrapped types be worth it here, or overkill for an encrypted envelope?

For a retry state mutation in AAD, is excluding attempts the correct tradeoff?

I’m looking for actual production patterns, not just theory.

I'll die on this hill: Result<T, E> beats exceptions. No hidden control flow, errors are values, compiler forces you to handle them. I've written enough Go and Python to never want

implicit throws again. But there's one thing I never see anyone talk about honestly the ? operator at depth.

2-3 levels deep? Beautiful:

fn parse_config(path: &str) -> Result<Config, AppError> {

let content = fs::read_to_string(path)?;

let config = serde_json::from_str(&content)?;

Ok(config)

}

Clean. Explicit. Love it. Now you're 7 functions deep in a real system. You get this:

Error: invalid type: null, expected u64

That's it. No line. No context. Somewhere in your 200 lines of ? chains, something broke. Good luck. With an exception runtime? Stack trace. Immediate.

Yes I know anyhow. I know .context("while doing X"). But now you're manually reconstructing what exception runtimes give for free. And the moment you forget one .context() three

layers down which you will you're back to guessing. thiserror is great at library boundaries. Inside an application you end up with either 40 custom error variants each wrapping

the previous, or anyhow everywhere which is basically dynamic exceptions with extra steps.

Rust made the right tradeoff. The cost is just more real than people admit. How do you actually handle deep error chains in production? What pattern did you settle on?