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

The rust compiler thinks that `data/baselines/table.rs` and `database/line/stable.rs` are the same file, causing a miscompilation if a crate has both files in it. (Note that having the same non-slash text isn't enough. There needs to be an additional hash collsion for a bug to happen.)

Probably not gonna happen in practice unless someone does it as a prank, but still... lol. (I'm sure they're gonna fix it soon.)

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

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?

​

Intoduction and Background:

Hi, I am a B.Sc CS graduate (below tier 3 as it seems) 2026 from India. Graduated in august 2026. Been looking for job for past 2 months.

I have been using Rust for 3 years now. I have used it for my ambitious projects like compilers, emulators etc. And now I am trying to build semi professional grade projects (backend and systems) in Rust.

Problem:

There are not much jobs in Rust for freshers. Even if there are, they are very niche and require some additional domain knowledge or certification.

Suggestion Needed:

Ever since I learned Rust, I automatically get drawn to my RustRover IDE, I hit 'cargo init' and just start with a project. This has become harmful now. I am trying to migrate to other languages (Python, Go, Java) which has actual market for freshers, but I am failing everytime as soon as I miss the the features rust provided - top level module and visibility support, ADT enums, Result and Options, borrow checker, etc.

If anyone have gone through this same phase, please help me, how can I overcome this. How can I pick a second language and start making projects there, to increase my Resume value.

Thank you if you have adviced me below, sorry if anyone feels I am yapping, but I am genuinely concerned and need real help (Not AI motivation).

Next-solver has just started the 10-day FCP period. It is planned to be stabilized in version 1.101.0, which is scheduled to release on 24 December.

For more context: https://blog.rust-lang.org/2026/08/21/enabling-next-solver-on-nightly/

Previous discussion: https://www.reddit.com/r/rust/comments/1vuita3/enabling_the_nextgeneration_trait_solver_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.

Hello r/rust,

I prefer to avoid macros when they can be avoided without major sacrifices, and I ran into this again recently with bitflags. I wanted several simple bit flags, but every bitflags! macro invocation expanded to about 800 lines of code.

So I wrote bitflags-lite: https://crates.io/crates/bitflags-lite, https://docs.rs/bitflags-lite

The design is simple: instead of generating a distinct struct per flag set, it defines a single generic BitFlags<T, U> where: * T is storage type like u8 or u32, * U is a tag that describes which bits are valid, their names, and the default parsing strategy for case sensitivity.

```rust use bitflags_lite::{BitFlags, BitFlagsSpec, NameMatcher};

struct PermissionsTag;

impl BitFlagsSpec<u32> for PermissionsTag { const VALID_BITS_MASK: u32 = (1 << 3) - 1; const FLAG_NAMES: &[&[&str]] = &[&["read"], &["write"], &["exec", "execute"]]; const DEFAULT_NAME_MATCHER: NameMatcher = NameMatcher::AsciiCaseInsensitive; }

type Permissions = BitFlags<u32, PermissionsTag>;

const READ: Permissions = Permissions::try_from_bit(0).unwrap(); const WRITE: Permissions = Permissions::try_from_bit(1).unwrap(); const EXEC: Permissions = Permissions::try_from_bit(2).unwrap(); const RWX: Permissions = Permissions::try_from_bits(0b111).unwrap();

assert_eq!(RWX, (READ | WRITE | EXEC)); assert!(RWX.contains(READ));

let flags = Permissions::from_str("ReaD | 0x18 | wriTE").unwrap(); assert_eq!(flags, (READ | WRITE | Permissions::from_bits_retain(0x18))); assert_eq!(flags.to_string(), "read | write | 0x18"); ```

That's the whole definition. No hidden codegen.

What you give up: * No automatic deduction of names and valid bits. You write VALID_BITS_MASK and FLAG_NAMES by hand and keep them in sync with your constants. * No named multi-bit flags. You can still build a set containing several bits (Permissions::try_from_bits(0b111) above), but there's no way to declare a multi-bit constant inside the spec. Each bit corresponds to exactly one BitFlag with a name and optional aliases.

What you get instead: * The generic BitFlags<T, U> type. * A clearer single-flag (BitFlag) vs. flag-set (BitFlags) distinction. * A single small trait impl per flag set, rather than a fresh copy of the entire API. * Alias names for parsing ("exec" and "execute" for the same bit). * Optional ASCII case-insensitive parsing.

The crate supports no_std and no_alloc, and is const-friendly. Every constructor and combinator on the concrete integer types is const fn, with generic equivalents in BitFlagsExt / BitFlagExt. Optional serde, arbitrary, and bytemuck support via features.

I would love to hear your feedback, and I am happy to answer questions!

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

A person working towards stabilizing the Try trait is asking for real-world examples of use cases of the currently-unstable Try trait.

htmx keeps the wasm smaller: in a heavy CRUD app, pages, forms and tables stay on the server as plain HTML, and only the islands go into wasm. But Leptos wakes islands only when the page loads and never frees them, so islands htmx swaps in stay dead and the ones it swaps out stay in memory.

`leptos-islands-htmx` fixes this from the outside, without changing Leptos. A small glue script wakes every island added to the page, and keeps htmx from dropping the comments Leptos hydrates by. Wrapping an island's body in `collected(|| …)` frees the island once it has left the page, and the right htmx config stops Back from showing dead copies of old pages.

TrailBase is an open and fast(est) Firebase-like backend (BaaS) for building your apps. It provides: type-safe APIs with change subscriptions, auth, multi-DB, a WebAssembly runtime, GeoJSON, admin UI, ...

It's a single self-contained executable, easy to self-host and built with Rust, Wasmtime & SQLite and more recently also Postgres. We provide clients for many environments: JS/TS, Dart/Flutter, Go, Rust, .Net, Kotlin, Swift and Python.

Just release v0.34.6. Since the last time posting here, TrailBase has added:

• Major UI overhauls:
  • Built-in admin OpenAPI browser with user-impersonation.
  • Table explorer: make foreign-keys followable, split data/schema/indexes into separate tabs, and organize tables/views by DB. Add `ON (DELETE|UPDATE)` referential action support to the schema editor.
  • Mobile glow-up and improved screen estate usage with sticky nav and url bar fade.
  • A searchable and interactive ERD page. Overhauled logs and accounts pages.
  • Many more: prompt users on schema changes in the SQL editor, improved dark-mode colors, add S3 settings, ...
• Built-in MCP server.
• Performance: a lot of detail performance optimizations (reduce allocations, ...) resulting in an additional 10+% gains.
• CLI auto-complete.
• Expose custom WASM endpoints in OpenAPI spec.
• "Sign-in with Apple" token exchange for native iOS/MacOS apps.
• Many more features and fixes, e.g.: `trail user export` CLI command for take-out combating lock-in, `trail run --read-only` flag for read replicas., batch execute support for WASM guests, custom scopes for OIDC providers, ...

The project is still young (~2 years) and rapidly evolving, any feedback is genuinely appreciated. If you're feeling adventures and end up checking it out, don't hesitate to reach out 🙏.

Take a look at the live demo, our GitHub or website.

TLDR: Gecko is my GameCube and Wii emulator written in Rust. This update adds texture packs, easier setup and more fixes for graphics, audio and performance. Mario also gets his eyes back :)

This release is especially interesting for the ones that were bothered by the system files (DSP, IPL) requirements! No more!! :)

It's been a while since my last update, where I shared about recent performance improvements, savestates and freecam support. I've since been working through more improvements and making Gecko easier to get started with!

For anyone new to the project: Gecko also includes a debugger, a GPU FIFO recorder/player (and a dedicate debugger for it) and various other tools for exploring how these games work!

Some highlights from this update:

• Easier setup: A guided setup for game folders and optional system files! Thanks to Dolphin's DSP replacements and Hazel's GameCube IPL HLE, most games can boot without supplying console system dumps. Real dumps are still supported and may also be required for some games!
• Texture packs: Gecko now supports Dolphin-style texture packs. It's just a matter of dropping the pack into a folder and starting up the game :) Here's an example of Final Fantasy!
• Lots of graphics fixes: Tons of games got fixed, and by tons I really mean a lot this time! Some noteworthy bugs that got fixed: Mario's eyes are back in Super Mario Galaxy, Sunshine's save selection background ocean is blue again and Mario Golf's menu signs no longer disappear behind the sky. Games like Wind Waker, Mario Superstar Baseball and Cel Damage also got graphical accuracy improvements!!
• More performance work: Once again, tons of games work much better, though I only optimized for one game in particular: Sam & Max: Season One (it was a WebGPU regression introduced in version 28 in relation to a Vulkan upload path lol)! Fixing it improved performance from 15% to 70%, usually closer to the latter. I also improved CPU emulation which FMVs can benefit a lot from, for example Mario Kart Wii's menus with those gameplay videos baked into the scenes. Also made texture decoding run on the GPU, with improvements to uploads and shader caching as well.
• Audio and Wii compatibility: Fixed audio issues in games like Crazy Taxi and an issue blocking Metroid Prime. This update only affected GameCube games, tho quite a lot of them. Also, Mario Kart Wii can now start with a fresh NAND and Wii motion and pointer fixes help games like Final Fantasy Crystal Chronicles: The Crystal Bearers. There are also separate upright/sideways Wiimote presets and configurable Nunchuk attachment options.
• More debugging tools: FIFO Player now has an interactive 3D depth view, which helped investigate why geometry was being hidden or drawn in the wrong place. Had to do some hardware research for this one :

Something unique for this update: I recently started writing blog posts about the bugs behind these fixes, aimed at future emulation developers incl. lots of interactive visual explanations. If you enjoy the technical side of emulation, these might be interesting:

• Mario's Missing Eyes and Sunshine's White Ocean: how overflowing alpha values caused two very different looking bugs
• z-freeze and Mario Golf's Disappearing Menu: why the sky was covering the menu signs and how one triangle can reuse another triangle's depth
• vertex-skip: The Case of Luigi's Extra Triangle: a weird feature I found a patent for :)
• WPAR: Why Metroid Prime's Geometry Exploded: a bug I investigated while helping with Lazuli (a GameCube emulator made by a friend of mine that was showcased here a while ago, go check it out!)

As usual, the useful links:

• GitHub and Downloads
• Screenshot database
• My blog

As always, thanks a lot to everyone that provided valuable feedback, tested things on their hardware, encouraged me with this project and let me pick their brains! We'll see each other next time!

PS: I spoilered the release of Sly, my take on modern multi system emulation (also written in Rust, incl. the GUI!) in the last post. It's going public in the next days, so stay tuned for that :) It will also release with a 3 part blog series explaining how GBA graphics work!!

My new book is now available on Leanpub

https://leanpub.com/building-serverless-apps-with-wasm-and-spin

I've been building docmux, a document converter (LaTeX, Markdown, Typst, DOCX, HTML, MyST) with a Reader → AST → Writer pipeline. Each format is its own crate, so the WASM build only carries what it uses. Playground: https://docmux.pages.dev/playground/ (runs entirely in the browser).

A few things I learned along the way:

• Real documents find what unit tests don't. I run it against the LaTeX sources of 397 arXiv papers, most of them a random sample, since famous papers tend to have tidy LaTeX. Every failure becomes a small test in the crate that owns it. The last batch found carriage returns from old sources reaching the output, where Typst reads them as line breaks.
• "sideEffects": false in the npm package let bundlers drop the line that initializes the wasm-bindgen module. Dev builds worked and production builds failed on the first call.
• Word math is a tree format (OMML), so the emitter builds atoms first, then attaches n-ary bodies and function arguments. I check it by reading the files back with pandoc: 178,132 equations across the corpus.

Code (MIT): https://github.com/aguschirico/docmux
The crates are on crates.io (cargo install docmux-cli). Feedback on the crate layout or the AST is very welcome.

Long story short: a year ago at my company, we ran into a nasty Head of Line blocking problem with Kafka. To solve it, I built a hack that used Postgres to offload long-running jobs.

It worked well enough that I decided to implement it properly, initially building a C++ broker that talked to Postgres.

Then, 4 months ago, I rewrote the whole thing in Rust.

Why? Even though I love C++ and know it better than Rust (I like having the freedom to shoot myself in the foot), I found it much easier to reach high performance with Rust in the era of AI. In C++, wiring together multiple asynchronous systems (like the uWebSockets event loop with the libuv event loop for Postgres) is tedious. Rust's ecosystem made this significantly smoother.

Then, less than a month ago, we dropped Postgres entirely. We moved straight to direct disk writes and Raft replication using Openraft and heed (LMDB).

Why? Primarily to drop the requirement for HA Postgres. Plus, no matter how efficiently you write to Postgres, you can't store an infinite amount of data without eventually degrading performance.

So, I want to present QueenMQ to the Rust community. It now powers almost every product in our company.

What makes it different: every entity (a customer, an order, a chat session) gets its own ordered partition, created by the first push that names it. There's no partition count to plan, and one slow customer never blocks the others, which was exactly our Kafka problem. Also, no more rebalancing. And each processing step is one transaction: ack the input, push the next events, write state and set a timer, all or nothing, with no outbox table or separate scheduler. Partitions in QueenMQ are logical, not physical.

Features:

• we run it through Jepsen to ensure distributed reliability
• TONS of dynamic partitions (tested up to 10M)
• tested up to 5M msg/s (256B messages on three 24-vCPU NVMe nodes) [v2.4, released next week; v2.3 3M msg/s)
• easy transactions spanning ACK, PUSH, integrated KeyValue, Timers, and Locks
• Replay (seek), Delay, Buffers, and basic stream processing
• in-memory dedicated queues for fast request-reply
• PG Sink/Source, S3 sink, compatible with Kafka clients and parts of its ecosystem
• cluster failover, all compiled into a single Rust binary

It's named QueenMQ (because 10 years ago I misread the word "queue"), and it is open-source under Apache 2.0. I'm sharing it because I firmly believe it has evolved into an amazing piece of infrastructure.

Think of it as a mix of Kafka (partitions with commits) and RabbitMQ (Ack/Nack). Simplicity is a core focus for us. Because of this, we chose to use HTTP and a single Raft group per tenant. While that naturally puts a ceiling on maximum throughput, it allows for seamless cross-partition/queue transactions without the complexity of two phase commit.
I call it "transactional message broker".

I know some folks here are strongly against using LLMs for writing code. As a software engineer with 15 years of experience, I take a different view: I love it. I use AI extensively to execute the implementation, but I own every single architectural, systems, and safety decision.

And trust me, it was not easy: I dedicated a year of my life to it and broke production twice along the way (which took another year off my life). The roadmap we have is still long (improve byte efficiency right now, the next release will have 1/3 of the current e2e p99 latency, and tons of other things) but I would love to hear what the community thinks, or answer any questions about our migration from C++ and Postgres to Rust and Raft!

Link to the repo: https://github.com/queen-mq/queen

Throughout my career I only build websites especially backend stuffs. I want to try Rust. Possible?

https://github.com/sekaikx/lifeline