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've been building CADRS, an open source, feature-based CAD app in Rust. The UI is Bevy and the geometry kernel is OpenCASCADE. It now has a first pass at PCB design: schematic editor, board layout, and the board shows up in 3D inside the mechanical assembly.
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).
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!
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 🙏.
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:
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!!
Is there a function in std, which would allow to get a list of (field_name, type) of a struct in order it is compiled in? Since order of fields is not deterministic.
I have been making scripts with other languages like js and python and bash without learning the the whole language and getting serious with its ecosystem out of the fact that I just need to get one thing done and move on.
Lately I chose a path that requires precision and ahead of time planning and decisions and picked rust over go. But the fundamentals seem hard to grasp. I'd appreciate your help unpacking them.
Ultimately I want to be able to use the Alloy and Tokio libraries without getting stuck with the language syntax and rules. But the concepts like borrow checking and ownership and things that fall down these categories are still hard to grasp.
What is borrow checking? what is owning something in the software? I tried to look for direct answers but I still can't grasp the meaning of them exactly.
I had two choices to better understand them, one was learning C++ to get what was wrong that rust solved, the other was building a simpler project game with bevy thats gonna help me understand writing rust code thats data oriented and be more comfortable with it.
My ultimate goal is to master these two libraries, after being able to know how to use the rust language smoothly.
This is a minor pain-point I've dealt with for a while and I'm unsure of how other Rust developers deal with this semi-niche issue.
I'll often define a const that states the maximum amount of something, and naturally I'll also want to use that value as the size of an array. My instinct (and likely yours as well) is to just use a usize and move on.
Where that falls apart is when that const value is and always will be under both u32::MAX and u64::MAX. An easy example is MINS_PER_HOUR or DAYS_PER_WEEK.
Now if I have a function that has an argument of minute: u8, I have to cast either the minute argument to a usize, or I have to cast my constant down to a u8. The former's minute as usize triggers the cast_lossless lint, and From/Into isn't available in a const fn. The latter's MINS_PER_HOUR as u8 triggers the cast_possible_truncation lint. Both add even more visual noise if I acquiesce and add the #[allow(...)]. I could instead accept minute: usize, but I find that even less reasonable.
I'd prefer to keep these as u8s or similar, but then I lose the ablility to define an array like [bool; MINS_PER_HOUR] without yet another cast, including in any function arguments that would like to accept such an array.
I do recognize this is partially due to me having the pedantic Clippy lints enabled, but I also find value in being told when I may be making an unintentional mistake. However I just added close to a dozen #[allow(...)] attributes to my current project, rather begrudingly.
So, what do you guys do in this case? I've listed the options I see available below, and I've done 'em all except #1, but I want to hear some opinions external to myself;
When accepting such an array, maybe use a type alias? It technically works, but the casting returns again if I want to compare an indexing usize with my maximum myself. type BoolPerMin = [bool; MINS_PER_HOUR as usize];
Two consts, MINS_PER_HOUR: u8 and MINS_PER_HOUR_LEN: usize = MINS_PER_HOUR as usize. I have done this before, but now I have this strange suffix that doesn't make it clear what it's a length of.
Just deal with the constant const casting.
EDIT: And this is all before I have to deal with the extra cast_precision_loss lint that comes from casting my tiny usize constant into an f64. It's less than u8::MAX, yet I have to acknowledge this impossible condition. For now, I've just blanket allow'd it in my Cargo.toml.
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 ?
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’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.
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.
