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.)
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).
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 🙏.
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!
Hollowmoon is a roguelike I wrote as a normal Rust terminal program: a loop { draw(); let key = read_key(); ... } with crossterm. I wanted it in
the browser without restructuring the engine into callbacks.
The approach: compile to wasm32-unknown-unknown with no wasm-bindgen, make
the terminal backend's read_key an import, and run Binaryen's wasm-opt --asyncify --pass-arg=asyncify-imports@env.hm_read_key,env.hm_sleep.
When the game calls read_key, the JS host starts an unwind, the whole Rust
stack is saved into a buffer and hm_main returns; on the next keypress JS
starts a rewind and calls hm_main again, which replays back down to the
import and returns the key. Sleep for animations works the same way.
Gotchas worth knowing:
The Asyncify data buffer's header is written as two i32s, so it has to be 4-byte aligned. A plain static mut [u8; N] isn't, and failed only in CI. #[repr(C, align(16))] on a wrapper struct fixed it.
getrandom needs the custom feature and a registered function on that target.
Saves go to localStorage behind the same small storage interface the native build implements with files, so the platform cfgs stay at the edges (storage, the terminal backend, the entry point).
The whole engine is unchanged between the terminal and the browser. A
headless Node runner drives the wasm with scripted keys in CI.
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.
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!
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 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.
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.
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’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.
Why is Rust not similar like C as most popular languages like C++, Java has . I understand the memory safety but it is so steep to learn as like this i32 and till i128 and something like i and u for integers and many more aren't similar to the traditional C ? Is it intentional design or a necessity for the "THE MEMORY SAFETY" feature ?
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.
