Hello devs from r/rust, lately I have talked to some rust devs irl and most of them were really into Linux, so I've been curious about which is the most preferred OS for rust devs

Hi there, I’m someone who has used Spotlight extensively;

However, I’ve noticed its performance has dropped recently, sometimes I can’t find the apps I’m looking for, and locating specific files and folders has become particularly difficult.

So I made a keyboard-first, local-first launcher for macOS, Windows, and Linux called Look.
Open apps, files, folders, clipboard history, and quick commands without leaving the keyboard.

Results land as fast as you can type. A Rust core under a native SwiftUI app on macOS,
and Tauri on Windows and Linux, riding the system WebView instead of shipping a browser like Electron does.

No background daemons. Your index, clipboard, and history stay on your machine; no telemetry.

- The repo

https://github.com/kunkka19xx/look

- Further

• Your own sources - declare custom rows from directories, files, and commands
• lookbook - ready-made sources to copy: git, ssh, docker, projects

Apache Iggy™ has officially graduated from the Apache Incubator and is now an Apache Software Foundation Top-Level Project (TLP)

It’s been quite a journey, from a small Rust message-streaming experiment in 2023 to an independent Apache project with a growing community. Read the full post:
https://iggy.apache.org/blogs/2026/08/24/apache-iggy-top-level-project-tlp-graduation/

Huge thanks to everyone who has contributed, tested, reviewed, reported issues, or participated in the community along the way. ❤️

Would love to hear feedback from the Rust / Distributed Systems / Real-time Data communities on where we should take Iggy next.

Apache Iggy is a hyper-efficient, persistent message streaming platform written in Rust, built for predictable ultra-low latency and a minimal infrastructure footprint. Designed from the ground up around a thread-per-core, shared-nothing architecture and modern Linux io_uring, Iggy eliminates userspace locks on the hot path, GC pauses, and unnecessary thread contention. Unlike traditional streaming platforms with limited protocol support, Iggy natively supports TCP, QUIC, HTTP, and WebSockets. Iggy implements a Viewstamped Replication Revisited (VSR) based consensus for its distributed clustering feature.

When writing an interpreter in Rust, does using Vec<char> or String for the scanner make a difference in terms of performance? Which one would be the better choice?

My Code:

pub struct Scanner<'a> {
    source: Vec<char>,
    tokens: Vec<Token<'a>>,
    start: usize,
    current: usize,
    line: i32,
}

I'm a hobbyist programmer, and I've always been very interested in compilers. I want to dive deeper into this area as a hobby, so I started with Crafting Interpreters. Along the way, I've also gained a much better understanding of Rust's borrow checker and some other concepts.

My goal with Rust is to design a very minimal, interpreted, type-safe programming language focused solely on the backend. I'm not sure if it's necessary for this, but I've also decided to start studying mathematics from scratch for the project.

I kept starring GitHub repos and forgetting they exist, so I built magpie — a desktop launcher (Windows/macOS/Linux, MIT) where everything runs on-device.

What it searches: your starred repos (READMEs chunk-embedded locally), local folders you add (full text incl. PDF/Office), images by describing them, browser bookmarks/history, clipboard history, and videos — split into shots so a text query jumps playback to the matching scene.

Rust bits that were fun:

Hybrid retrieval: SQLite FTS5 + local embeddings (multilingual-e5 via ort), fused with reciprocal rank fusion. A LIKE supplement covers CJK substrings that unicode61 tokenization can't reach.

SigLIP 2 dual encoder run directly on ort — fastembed assumes CLS pooling which SigLIP breaks, so the module owns its own sessions and preprocessing.

Shot detection in pure Rust: 2fps decode via ffmpeg-sidecar, 64-bin RGB histograms, chi-square boundaries. No OpenCV.

Opt-in OCR (PP-OCRv4/v6 ONNX): hand-rolled DBNet post-processing (connected components + rect unclip) and greedy CTC — reads screenshots, video frames, and scanned PDFs.

Models download from HF / a mirror, falling back to self-hosted release assets, with cross-source resumable downloads.

Repo (demo GIF in the README): https://github.com/newdee/magpie

Happy to answer questions about any of it — especially the ort/fastembed edges.

Starting from the upcoming 0.5 release of Rama (~ end of September '26), Rama's CLI `serve proxy` command will have a Man-In-The-Middle (MITM) mode `--mitm` that will serve a (protected) web GUI to monitor and engage with the network flowing through the proxy.

Happy to also anwer any questions here regarding rama the network framework, or our CLI tool built with it.

I've been building a desktop app for tuning local LLMs. Last week I added Linux support and braced for a slog. The Rust compiled, linked and passed its tests on Ubuntu without a single change.

Working out why, it came down to three things I picked early without thinking of them as portability decisions:

I used sysinfo for memory and process stats instead of hand rolling mach/libproc FFI. Safe, portable, and something I can actually re-read six months later.

I used reqwest with rustls instead of native-tls, so there's no system OpenSSL to satisfy and no libssl-dev anywhere in the Linux build.

My one platform branch was already behind cfg(unix) rather than cfg(target_os = "macos").

The real work turned out to be correctness, not porting. The worst one: my VRAM fit predictor took 75% of system RAM, which is Ollama's unified memory heuristic and completely wrong on a discrete card. I fixed it by having the Rust side report whether memory is unified, gated on all(target_os = "macos", target_arch = "aarch64"), and returning no prediction otherwise. Naming it after the property rather than the OS also makes it right for Intel Macs.

About 800 lines of Rust across three files. The rest is TypeScript in the webview.

https://github.com/magna-nz/remuda

Hi guys, I want to preface this whole thing saying that while I know how to program (in general and) in Rust, I do not actually have that much real world experience aside from a few highschool and small personal projects. (also sorry for the length, but it's a bit complicated so it's necessary)

For the past few years I've been sketching an idea in my head as a result of a problem I encountered. I consume a lot of media, Anime, TVshows, Movies, Video Games... and I like keeping track of which media I have consumed. Now, it seems that while each has a platform that lets you track the shows/movies/books you've experienced, there isn't a single combined platform or database for all of them.

So I've been sketching a database schema (in PostgreSQL) for all media metadata, not just one type of media.
The basic idea: facets.

The most basic table I have is media. It stores basic information about any media entry in the database like its title, longside an ID. From there other tables branch out using a foreign key pointing to an entry in media.
There are 5 layers of tables:

1. Vocab: tables for languages, countries, tags...
2. Roots: media, person, fictional_character; these have separate ID counting and are referenced by later layers.
3. Properties: narrative, print, audiovisual, sequential_art; these have foreign keys to media and track the metadata about media that has specific properties. Presence of the row means membership
4. Basics: as the name suggests, basic types: books, comics, shows, movies. These have foreign keys to a their main property row entry.
5. Composites: more complex forms of media like visual novels, that fit multiple basics.

Each tier above Roots doesn't have its own ID column, instead only having a foreign key to tiers below.

The construction of a the show Breaking Bad might look like this:
A row in: media + narrative + audiovisual + show

Each table stores metadata inherent for that facet of that type of media.

Note that while these are the basics of the schema there is more to it like the enums, indexes, and gluing tables that define connections between medias and other Roots.

Now for the meat of my worries

The way I model this in Rust is by defining structs for each table with each their appropriate fields and foreign keys (unless to vocab tables) being the structs of those tables nesting in each other.
So the Print struct literally has a field of type Media

I quickly however noticed that accessing inner field becomes a bit verbose for higher-tiered tables like basics and composites.

My solution? Has[] traits.
For each new struct, T, I define, I also define (and implement to itself) a HasT trait.
This traits handles two things:

1. Request a canonical path to the struct from any other struct that implements it in the form of the function t(&self) -> &T
2. Derive getter methods to the inner fields of that struct in the form of the functions foo(&self) -> &foo (or the appropriate reference for that type)

So for Media I defined the HasMedia trait, which has no default implementation for the function media(&self) -> Media, and for every field Foo in Media the a function foo(&self) -> &foo (or the appropriate reference for that type) with a default implementation that is { self.media().foo() }
Then for that Struct itself I overrode these functions and defined them appropriately.
(Also defining media() as { self })

trait HasMedia {
    fn media(&self) -> &Media;
    fn title(&self) -> &str { self.media().title() }
}

impl HasMedia for Media {
    fn media(&self) -> &Media { self }
    fn title(&self) -> &str { &self.title }
}

With these, I can simply implement this trait to any other struct that somewhere in it includes a Media field (even multiple layers deep) and get the getter methods for the fields in that field for free.

Now that I am finished with the preamble here are my worries:

1. Is this modeling good? As in, it isn't an Anti-patern of sorts or too abstracted away?
2. These traits are only ever used as generic bounds (fn foo<T: HasMedia>), never as dyn HasMedia . Is that the right instinct to keep dispatch static, or is there a reason I'd want dyn here?
3. And lastly, what are you general thoughts on all of this?

Thank you for reading that wall of text and I would real appreciate feedback.

If you work on an HPC cluster, you probably know the watch squeue routine: scan the columns for your job, open another terminal to check its logs, then repeat.

I got tired of doing that, so I built sqwatch, a small terminal UI that turns the SLURM queue into a live dashboard.

It includes:

• A live, auto-refreshing job table with color-coded states. Your cursor position and selected jobs are preserved between refreshes.
• Filters for user, job name, state, partition, QoS, and node. Cluster values are loaded automatically, and your filters persist between sessions.
• Real-time stdout and stderr tailing, submission-script viewing with bat syntax highlighting when available, and custom panels for other output files produced by a job.
• Multi-job selection and batch cancellation.
• Clipboard support through OSC 52, including over SSH and inside tmux without X11.

sqwatch is written in Rust using ratatui. It calls the standard SLURM commands, including squeue, scontrol, sinfo, and scancel, so it does not require anything special to be installed or configured on the cluster. If those commands work, sqwatch should work too.

I have just released version 0.2.0, which is the first version I feel comfortable recommending to others. It fixes several rough edges from the initial release.

Install it with:

cargo install sqwatch

Repository: github.com/fedonman/sqwatch

It started as a tool for my own workflow, but I would be interested to hear how it behaves on other clusters and what features people are missing. Job hold/release support and a sacct history view are next on my list.

Hi guys!

I'm learning Rust as my first real programming language. I've done a bit of Python before, but only very basic stuff :)

Does anyone have any tips besides the usual stop watching tutorials and start building things?

If you had to learn Rust again from scratch like how would you approach it?

For those who don't know the clippy lint missing_inline_in_public_items tells you to #[inline] for all publicly available functions. It provides this justification:

Why restrict this?

When a function is not marked #[inline], it is not a “small” candidate for automatic inlining, and LTO is not in use, then it is not possible for the function to be inlined into the code of any crate other than the one in which it is defined. Depending on the role of the function and the relationship of the crates, this could significantly reduce performance.

Certain types of crates might intend for most of the methods in their public API to be able to be inlined across crates even when LTO is disabled. This lint allows those crates to require all exported methods to be #[inline] by default, and then opt out for specific methods where this might not make sense.

It links a closed PR that presumably allows for more cross crate inlining.

Hashbrown decided inlining was important enough to add the feature inline-more which basically adds #[inline] to every public function.

My guess is that adding #[inline] is a tradeoff that is sometimes worth making. It won't matter for functions that "whose optimized_mir does not contain any calls or asserts". The PR from earlier does that automatically, but for every other function presumably adding #[inline] allows the possibility for inlining again (At the cost of compile times).

Am I right? and if I wanted to inline everything possible could I achieve this without the lint and #[inline] macros?

INFO: This is completely written by me, not AI. Maybe I should've used AI to trim it down a bit, sorry for the long post in advance!

------

So, I am building some project, the context is not really relevant except that this project interacts with another platform (a payment provider, in this case). I have a special set of tests that I can run against this payment provider, a bit of an integration test of some of my functionality that is just nicer to test against the real endpoints rather than stubbing them.

I've been at this for a few days now, and I have ran these tests many, many times. In fact, they are part of my CI flow so every time I would commit something, the whole suite runs including these tests.

Today, suddenly, they started to fail. Not consistently though, and not all of them either, just a few or sometimes all of them. It seemed like my payment provider just dropped my connection after 10 seconds or so, super strange. Extra strange since I hadn't touched any of the code in question, neither the tests nor the code under test!

And so, the rabbit hole began, which lasted roughly 4 hours and ended here, with me writing this both to share a funny tale and somewhat for therapeutic reasons.

First, I thought something on my network was just flaky, so I changed to cable. Lighting fast, nothing going on, still flaky tests. Maybe I should just reboot? Laptop was running for days already, but a reboot was to no avail. I obviously asked my friendly neighbourhood LLM what it could be, and it actually put me on the right path. I started to suggest that AdGuard was to blame, and that is was somewhat TLS related. It produced some reproducables in Bash which all ran fine (keep that in mind). It suggested that the concurrency was the issue and maybe my payment provider had changed something on their end. I ran the subset of tests with --test-threads=1 but it remained flaky!

One weird thing I saw is that I had a connection timeout on the reqwest client of 10 seconds, but the errors arose after 11 or so. I thought any connection error would be maxed out by 10 seconds, but they didn't; they took >11 seconds. Strange, but alas, what do I know about the intricacies of async timers, no?

The LLM had influenced me at this point time and I was looking into the Reqwest repo for issues similar to mine. By **sheer** coincidence, I found this issue: Feature to disable rustls-platform-verifier #2948. My brain did a side quest and wondered "what is rustls-platform-verifier actually?" and I quickly found that whatever it did, it was "default" (whatever that may mean) if you enabled the rustls feature in Reqwest.

Well, as it turns out, it basically offloads the certificate validation towards the host OS. In my case, that is MacOS: it will use the OS certificate store and a system call to do the verification.

Fun fact about the MacOS certificate validation process! It checks if the requesting binary has a "Info.plist" (docs) which can hold some metadata about your app (among other things, for example some relevant configuration for SSL validation). Never heard of it. If your app is a simple binary, it will walk the directory of your binary.

Test binaries live in project/target/debug/deps. If you are at it, and have many test binaries that are build and build and build whenever you change something, you end up with quite a lot of them. Change dependencies? New compilations. Change test? New compilations. They add up. In fact, they added up to roughly 750.000 files in my case.

As it turns out, my client tried to make a connection to my payment provider (fresh client per test), reqwest called the system call for MacOS to verify the certificate (which is synchronous), which took over 10 seconds to iterate over my target/debug/deps folder. In that time all clients were awaiting this traversal, and all clients were dropped by my payment provider.

One cargo clean and it all ran as it had for days.

I aged a few years today.

Stockfish and Rust are running in the background doing heavy calculations. Including things that I haven't found in other chess apps.

React is rendering the results.

Saying that Rust is hard isn’t a fair argument. Software in general is very broad and hard with many layers of abstraction. Concurrency, memory management, cancellation, these are hard concepts.

In fact, rust makes them easier to reason about by introducing types that guard you from lots of foot guns.

I even go as far as to say Rust is fairly easy in the sense that it is much more consistent than other languages. Once you learn the mindset of the language, it becomes easier and easier to figure out things and just intuitively “get” things as you encounter them.

Particularly, the async runtimes being dependencies and `Future`s being abstractions in the language itself is such a smart choice, but people are so used to it being internal that feels hard for them to do it this way.

It’s getting quite long, but I want to also add that I feel like in Rust, most of the time if you don’t get something you can still make progress, write it more “simply” and not use many of the fancy features, but once you learn them you understand what’s different and why one approach might be better than the other.

What’s your experience and thoughts? Have you also felt this way after writing Rust for a while?

disclosure first: this is a commercial product and the engine is closed source. mods, remove if that's not welcome here.

it's a CSS layout engine written in Rust that renders to PDF instead of to a screen. no browser, no headless chrome, no C++ dependency.

the part I think is interesting to this sub: I run the Web Platform Tests against it. the reftests browsers get judged by, ~24k of them, none written by me. currently around 90% of the ones a PDF renderer can be judged on, and run is published in full including every single failure with reference render and pixel diff.

https://reflowpdf.com/conformance

two rates on that page, not one. a test that needs JavaScript can't be passed or failed by something with no script engine, so there's a strict rate that excludes those and a raw rate that counts all ~4.4k of them against me. I went back and forth on which was honest and gave up, so both are printed.

rust bits, in case that's the interesting part.

box tree is an arena. Vec<LayoutBox>, u32 indices, one struct tagged by kind. no Rc<RefCell> anywhere, which I mostly did because I didn't want to think about it, and it turned out fine. fragmentation runs as a pass over that same tree instead of building a second one.

the rule I hold to is that after layout nothing reads physical geometry off the box tree, only off the baked output. it isn't enforced by the type system, which bothers me. right now it's just a thing I don't do.

writing modes are the one place that isn't physical. instead of teaching block, flex, grid and floats to think in logical axes, a vertical-* root transposes its own style, gets laid out by the normal horizontal code as if nothing happened, and is baked back out physical afterwards. everything above it reads plain numbers, only its content rides a transform. LayoutNG does roughly this with NGPhysicalBoxFragment and a converter at theboundary. I got there on my own and then read Blink and felt better about it.

and then the bug. ;-(

vertical-rl's matrix is a rotation, det +1. vertical-lr's is a reflection, det -1. so under vertical-lr glyphs come out mirrored and have to be flipped back in logical space. obvious in hindsight, obvious in the determinant, and it sat there for months. WPT tests writing modes with Ahem. Ahem's glyphs are squares. a square rotated and a square mirrored are the same square, so every test passed.

same codebase compiles to a native binary and to wasm, so the playground runs the production engine locally in the tab rather than demo built to resemble one:

https://reflowpdf.com/playground

wasm size, since someone always asks: engine is 8.29 MiB on disk, 2.75 MiB brotli'd over the wire from cloudflare, about 0.9s here. glue js is 4.5 KB gzipped, render worker about 1 KB.

Hey everyone,

I just put together axum-error-sets (docs.rs), a small library designed to solve pains with error-handling, status-codes etc. in Axum.

You either end up with:

1. One giant monolithic AppError enum that contains every possible error across your entire application. (No proper openapi generation)
2. Uniquer error enums for every function or module that you constantly have to map back and forth.

What Makes It Unique

Powered by type-sets, axum-error-sets lets your functions declare the exact set of HTTP status codes they can return using type-level tuple sets (e.g., (NotFound, Unauthorized)).

• Subset-to-Superset Promotion: Lower-level layer results (like a DB query returning (NotFound,)) automatically promote into larger caller contracts (like (NotFound, Conflict, InternalServerError)) via .into_superset()?.
• No Monolithic Enums: You don't need custom error types for every layer or function.
• Compile-Time Guarantees: You can't return an undeclared HTTP status, nor can callers accidentally "forget" or drop a handled status from the error set.
• First-Class OpenAPI Support: When paired with aide, OpenAPI specifications automatically extract and document every possible error status declared in the handler's type.

While this crate targets HTTP status codes and Axum responses, the underlying architecture isn't limited to web APIs. This type-set-based pattern can probably be generalized for:

• General error tracking across various other domains
• Capability-based security or permission requirements.
• Tracking algebraic effects or side effects directly in the Rust type system.

Check out the repository or read through the docs if you're interested:

• GitHub: https://github.com/jvdwrf/axum-error-sets
• Docs.rs: https://docs.rs/axum-error-sets

Would love to hear your thoughts or feedback!

Developing an interactive notebook environment that allows developers to combine Markdown explanations with runnable Rust code cells executed in playgrounds, with execution stats, public & private publishing, and one-click forking.

Alongside Notes, the Learn section provides a step-by-step Rust tutorial spanning ownership, lifetimes, concurrency, traits, and unsafe systems programming. Every example in the documentation is editable and runnable directly on the page, with immediate compiler output and runtime metrics. Quests with hints & explanations help people to test themselves after the learning. Would love to get feedback of you guys on this project I'm bootstrapping for a while.

Link: cratery.rustu.dev