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.
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.
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.
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
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.
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.
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!
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!
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.)
I’m the developer of Arezgit. It started as a desktop Git client, and I’ve been adding other tools to it over time.
You can browse commit history, review diffs, resolve conflicts, edit files, open terminals, test APIs, and query databases in the same window. There are also task boards, notes, and workspaces for multiple repositories.
Some features used to be paid. I’ve now made the whole app free, including private repositories. You don’t need a subscription or an account to use anything.
It’s built with Rust, Tauri, and React, and it’s available for Windows and Linux.
AI integrations are optional. External AI providers have their own costs.
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).
I ported Ghostty (Zig) to Rust with Claude Code agents. The most interesting part for me was how often Zig's "a pointer is just an address" collided with Rust's aliasing model. The write-up has the real code, the Miri findings and the fixes:
The section "Zig pointers in Rust's aliasing model" walks through four cases:
Protectors. A &mut argument is protected for the whole call. Ghostty re-reads the same memory another way inside the call, which is sound in Zig and UB under Miri.
Frees under a live reference.startHyperlink lets its slices point into the hyperlink it is about to free. A &[u8] can't do that.
Provenance. One 8-byte store through a pointer derived from a 1-byte field reaches seven bytes outside its provenance under Stacked Borrows.
Long-lived aliases. In the renderer loop, a sibling reborrow pops the run iterator's tag. I settled the fix with a small Miri proof harness instead of reasoning about it by hand.
You can also try the engine yourself. The page has two live terminals, Rustty's and Ghostty's, both compiled to WebAssembly and fed by the same shell, so you can compare what each one draws. All 898 of my prompts are in a filterable log at the bottom, and every number links to its source.
Caveats: the port is macOS-first, the benchmarks are library micro-benchmarks, and the prose and data pipeline were drafted with Claude and reviewed by me. Corrections on the aliasing analysis are very welcome.
Like many developers, I've had close calls accidentally pasting API keys or bearer tokens into terminal commands, persisting them to .zsh_history or leaking them across screen recordings.
In the newly shipped v0.5.4, I added Secret Guard to handle credential leaks at the shell prompt before execution:
Real-time Sniffing: Detects GitHub PATs, OpenAI/Anthropic keys, AWS IDs, Stripe keys, and Slack tokens right as you enter them.
Inline Interception: Pauses execution and prompts to store the credential directly into a local encrypted vault (~/.bnb/vault.json, locked to 0600 permissions with machine-specific key derivation).
Command Rewriting: Rewrites the command inline (e.g. curl -H "Authorization: Bearer $vault:gh_token"). Only the placeholder hits disk history, and the secret expands in-memory during pipeline execution.
So I've been working on Ferese, a Wayland compositor built in Rust using Smithay. The idea is to make the window manager, shell, launcher and Settings feel like parts of one desktop, with consistent theming and animations throughout instead of the traditional bring your bar, launcher, notification center etc most WM requires.
It supports scrolling and tree tiling alongside floating windows, higly customizable panels, and Live Activities for following running commands and build progress.
I've been daily driving it, and it's getting close to 0.1.0 but there's still plenty I want to work on, so I'd love to hear others thought. ..and it's really memory efficient!
I have been building a free, local-first 3D modeler for people who make furniture: push/pull faces, inference snapping, groups and components, section planes, a cut list, sheet nesting, .skp import, STL/3MF export. Desktop app is Tauri 2 + React + three.js; the whole geometry kernel is a no_std-friendly Rust workspace (boolean ops, planar arrangement, tessellation, inference, exports) compiled to WASM and run in a Web Worker, so the browser demo and the desktop app share one kernel byte for byte.
Things the Rust side does that might interest this sub:
Watertight by construction. Every solid is a closed oriented triangle surface; the exports are checked by Euler characteristic, manifold edges and signed volume on every change.
Section cuts. The cut is done per triangle with one signed distance per vertex, so the kept half's open boundary is exactly the set of chords the cap is laid from. A unit test walks the boundary and matches chords one to one. This replaced five rounds of per-face special cases that each left a sibling bug at about one in 105 random edit sequences.
Testing is most of the work. proptest with hostile generators (corners nudged by nanometres, faces drawn on faces, planes through edges), a kernel fuzzer that replays random edit sequences and checks invariants after each, a 200-file .skp corpus that must hash byte-stable, and goldens cross-checked native vs WASM. Every finding becomes a named repro in the tree.
Plugins run in sandboxed JS workers with declared permissions; the host is Rust-side message passing, three locks (allowlisted globals, CSP, sources parsed before they run).
Hostile input. Zip bombs, count caps, size limits on .skp/.shz/plugin packages, all measured and documented in docs/LIMITS.md.
Honest state: 0.1.0-alpha.2. Installers are unsigned (no signing identity yet). No fillet, chamfer, copy/paste in place, or .skp export yet. A 13.5k-face SketchUp file opens in about 4 s. The comparison table on the site says what the other free options do better.
I would welcome eyes on the kernel crates (crates/kernel, crates/arrangement, crates/tessellate) from anyone who has done computational geometry in Rust, and bug reports from anyone with a real .skp file that does something odd.
Disclosure: Sawhorse is built with AI coding agents, and every feature is checked by a separate agent running its own fuzz tests before a release. All the code and tests are public, so judge it by what's in the repo.
I have been developing keepword, literally makes companies keep their word, it watches pages you want and detects if it has been silently edited which then gives you an alert and a diff. Though keepword is not just a cli tool it’s a network, the network itself is made of witnesses which give you features like detecting cloaking (if a page shows different content to different countries). It’s quite a useful tool I made for myself and I’m trying to find people who find it as helpful as I do. Although the network isn’t that big yet, with hope in the future it’s going to become strong enough.
Anyways if there is any people there which might run a node for themselves and be a part of the network you can find the details on https://keepword.net its fully open source.
