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
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.
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};
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!
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.
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
Internal perf benchmark we made before each release, followed by Jepsen test.
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!
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.
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.
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?
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.
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.
I've been thinking about starting a hybrid organization built around Rust. It would combine software and physical hardware, with the goal of making useful products and tools that have real-world impact. Before going further, I'd like to hear what the community thinks.
The principles I'm considering:
- No work for military or surveillance use. This should be a firm rule.
- Hardware and software designed together to use less electricity while delivering strong performance, for both consumer and enterprise use.
- Accessible to everyone, with simple, human-friendly tools and products.
- Open-source software and documented hardware designs where possible, so others can build on the work.
- Physical products and real-world impact, such as projects aimed at making the world healthier.
A few questions I'm curious about:
- Where is the gap in the Rust ecosystem for embedded, low-power, or hardware-software work that isn't well served yet?
- What structure makes the most sense for a hybrid organization: nonprofit, company, volunteer collective, foundation, or a combination?
- How should digital and physical work be balanced so neither side gets neglected?
- What would make you want to get involved, and what would make you skeptical?
- What pitfalls have you seen in similar open-source hardware or community projects?
- What are the critical problems when you face on open-source software alone or maintaining a large popular repository (except financial)?
I'm open to blunt criticism, especially from people who have run open-source projects or organizations before. Thanks for reading.
