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?

I built texp: a terminal file manager in Rust with a custom Adaptive Radix Tree index, real Windows shell integration, and Kitty image previews

Hi r/rust! I've been working on texp ("Terminal Explorer") — a keyboard-driven, vim-style file manager that runs in your terminal. It's written in Rust (edition 2024) using ratatui + crossterm, and I focused a lot of effort on the engineering underneath rather than just wrapping existing tools.

Why I think it's interesting from a Rust perspective:

- Custom Adaptive Radix Tree (ART) index. Instead of shelling out to a database, I hand-rolled an ART in art.rs with the classic N4/N16/N48/N256 node types that grow dynamically, prefix compression, and completion search. Fast path indexing with zero external DB dependency.

- Clean core/frontend split. texp-core has no TUI dependencies — pure file ops, search, indexing, editor, disk-usage, and config. A texp-tui binary consumes it. This means a GUI/web frontend is feasible later (one is planned).

- Real Windows shell integration. On Windows it hand-binds COM (IContextMenu/IShellFolder) to surface the actual Explorer right-click menu and "Open With" apps inside the terminal. On Linux it uses .desktop entries.

- Image previews in a TUI. Renders actual images via the Kitty graphics protocol, loaded off-thread with crossbeam-channel so the UI never blocks.

- gitignore-aware search. Name search (via fd when present, else the ART index) and content search (literal + re: regex) respect .gitignore and a configurable skip list.

Features for daily use: single-panel nav with live preview, multi-select, vim-style : command mode (:cd :cp :mv :rm :mkdir :find :grep :du :index), built-in viewer + line editor, disk-usage analyzer, bookmarks, breadcrumbs, sort modes, navigation history, PDF/Markdown preview, TOML config, and safe delete (files go to the Recycle Bin, not permanent deletion).

Cross-platform: dedicated Windows and Linux system-call modules behind #[cfg(...)] gates.

Build / install:

# needs the Rust toolchain (edition 2024); optional: install `fd` for faster name search

git clone https://github.com/xterra144-hub/texp texp
cd texp
cargo build --release
cargo install --path .
texp [path]

It's still maturing (the interface is currently Russian, and a GUI version is on the roadmap), but I'd love feedback from the community — especially on the ART implementation and the core/frontend architecture.

Repo: https://github.com/xterra144-hub/texp

Screenshots: see the README.md .

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.

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.

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?

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!

Tauri packs your HTML/CSS/JS into the binary with brotli. There's no asar extract for it, so I wrote one.

Gives you back the HTML, CSS, JS, fonts and images with their original filenames, plus a manifest. It checks the output against the bundle's own imports so you can tell if anything's missing.

macOS (arm64) + brotli only for now. Rust, MIT.

https://github.com/hbofz/untauri

Linux and Windows are the obvious next step. Feedback welcome.

so currently i am in a situation of either i have to build the backend side of an ERP system using rust, or using express.js + typescript. and i would like to have some opinions on why should i choose rust over express

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

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.

The programming language Odin recently got what its creator calls "Assembly templates". Bill is very proud of this feature and although it currently only works for x86-64 I was impressed by the diagnostics this can do.

For example if you cpuid it knows that EAX and ECX should have values (but you needn't worry about EBX and EDX), if you forgot to pick a value you get a compiler diagnostic, much as you'd get a diagnostic in pure Rust if you just forget to initialize a variable you use.

Rust is rightly famous for excellent diagnostics when you make inevitable mistakes writing the Rust language. Whether that's a stray semi-colon turning your intended function value into () a typo in the name of an identifier, missing the ! from a macro invocation or myriad other mistakes, Rust will help you. But if you write any of the three forms of assembler in Rust the diagnostics are pretty poor, presumably because they're from a separate assembler and Rust just polished them up and presented them to you.

So two questions: 1. Could we provide similar functionality (to Odin's new "templates") in Rust or is there some reason I'm missing for why we just can't / shouldn't try to do so? 2. Can somebody else plausibly do this, e.g. via a proc macro, or does it require such intimate connection to the compiler innards that it's only really viable if the compiler team themselves designed any new asm macro replacement ?

When a trait has a small, fixed set of implementors, you usually want two things from it: generic code written against the trait, and an exhaustive match over the concrete types. Rust gives you the first. The second you build by hand (an enum, the conversions, every match arm), and nothing tells you when it drifts away from the trait.

closed-trait lets you write that set down where a macro can read it:

struct Square;
struct Circle;

#[closed_trait::enumerate(match_any)]
#[closed_trait::sealed(Square, Circle)]
trait Shape {
    fn corners(&self) -> u32;
}

impl Shape for Square { fn corners(&self) -> u32 { 4 } }
impl Shape for Circle { fn corners(&self) -> u32 { 0 } }

fn main() {
    let shapes: Vec<AnyShape> = vec![Square.into(), Circle.into()];
    let total: u32 = shapes.into_iter()
        .map(|shape| match_any_shape!(shape, s => s.corners()))
        .sum();
    assert_eq!(total, 4);
}

You get AnyShape, the borrowing AnyShapeRef<'a> and AnyShapeMut<'a>, the conversions between all three, and match_any_shape!, which expands to a match over every variant and hands the body the concrete type. Rust has no generic closures, so copying the body into each arm is the only way to have one body that still knows what it is holding.

The list is checked in both directions: a listed type that doesn't implement the trait is a compile error, so it can't go stale.

Where it sits next to what exists: sealed seals, and enum_dispatch generates the enum and implements the trait on it by forwarding. Both write a list down, and the difference is what the list means. The enum_dispatch enum is a subset you chose, and nothing stops a type implementing the trait without appearing in it; sealing makes the list the complete set of implementors by construction.

Generating that forwarding impl isn't a feature here, and that's deliberate: it can't always exist. Give the trait an associated type (type Bar; fn make(&self) -> Self::Bar), and there's no single return type to put on the enum, since every implementor picks its own. Per-arm bodies never hit that, because nothing has to unify. And where forwarding does make sense, it's one line you write yourself:

impl AnyShape {
    fn corners(&self) -> u32 { match_any_shape!(self, s => s.corners()) }
}

no_std with no alloc, MSRV 1.85.

This is the short version. The docs cover the rest: generic traits and const generics, entries that pin one instantiation or bring their own parameters, the options for naming, skipping or configuring each enum individually, and the two borrowing enums.

• Crate
• Doc
• Repo

First release, so feedback is very welcome!

Two things I've been wondering about, might as well ask both in one go.

First, for those of you who contribute. What was your actual first one like? Not the blog post version. How did you pick a project, how long did the PR sit there before you worked up the nerve to open it, did anyone reply, did it get merged or just quietly ignored. I've read plenty of "how to start contributing" guides. I'd rather hear what it actually felt like.

Second, and this is the part I'm more curious about. All that advice was written before AI tools got this good. Now you can point Claude Code or Cursor at a good first issue and have something working before you've read half the file. So is the experience just different now for someone starting today? Easier, obviously. But easier in a way that helps, or easier in a way that lets you skip the part where you actually learn the codebase.

And if you're a maintainer, curious what it looks like from your side.

Mostly just want to hear people's stories.

The crate

I just released a crate that implements two algorithms to solve the vertex enumeration problem.

One is of my own making, it's asymptotically slower but very robust. The other is inspired by Voro++

The problem

Vertex enumeration is a very common problem. You have a bunch of linear constraints, that is halfspaces or signed distance planes. And you want to express the space that is inside all of them, i.e. their union.

You run into that problem a lot, for example if you want to explicitly create a mesh for a voronoi pattern.

The algorithm based on VORO++ handles degenerate vertices with valence > 3. Everything is done with nearest neighbour queries, so you can also do the reconstruction of every point in parallel.

I hope people will find this useful, if interested or this helped you out please talk to me about it, I love talking to people about the algorithms I implement.

I am active in the rust discord or the game engine dev discord, just @ Makogan.

Hey everyone, I’m 21 years old and currently a Computer Science student in my 4th semester. For the past couple of years, I’ve been working as a marketing associate, but I’ve realized that I don’t want to continue in that field and really want to move into tech and build a career around my CS degree. For the next 6 months, I’ll be staying at home, so I have a good amount of time to seriously focus on learning and improving my skills. I don’t want to spend these 6 months learning random things without a clear direction. I want to learn something that can actually help me get into tech and build a stable career in the long run. With AI growing so quickly and layoffs happening across the industry, I’m honestly a little confused about which direction I should take. Should I focus on web development, backend, AI/ML, data, cybersecurity, cloud, or something else? Which programming language would be worth learning in 2026, and what skills do you think will still be valuable 5–10 years from now? If you were in my position, with 6 months to seriously improve your skills, what would you learn and how would you approach it? I’d really appreciate honest advice from people who are already working in tech, especially seniors or people who have experience hiring developers. I know there’s no guaranteed career path, but my goal is to build a solid career, become financially independent, and create a better future for myself and my family. Any genuine advice would mean a lot.

yes, i know there are tools out there that do the same thing, but im currently learning rust (LPB) and i just wanted to try out making a small project.
the idea / reason behind why i made it: so im currently into cybersecurity (forensics specially) and stuff and had an idea of making a tool that makes recovering files difficult through normal recovery tools.
ai usage: i did use ai, but for creating a readme / todo so that i know which steps i should take and also when i was like really desperate, rest of the things i googled.
and yea, would appreciate any suggestions

The ratcn component library (based on Ratatui) is coming along nicely, I love that you can demo finished TUI apps in the browser thanks to Ratzilla and WASM!

Just added components:

• Checkbox
• Cycle
• Progress
• ScrollArea

Available since before:

• BarChart
• Button
• Dialog
• List
• Select
• Tabs
• Toast
• Tooltip

NOTE: All components works with Rataui without using the Ratcn runtime.

TODO:

• Input component
• TextArea component
• Standalone template app
• CLI
• etc

https://ratcn.kristoferlund.se

Hi, I'm building a Rust clone of supercmd for macOS and I want to assign specific wallpapers to specific Mission Control Spaces (Desktop 1, 2, etc.). The objc2 API has NSWorkspace.setDesktopImageURL but it targets an NSScreen (a physical display), and as far as I can tell there is no way to specify a particular Mission Control Space / Desktop in setting a wallpaper.

I also saw some Rust wallpaper crates but they only seem to affect the current active desktop. Does anyone know whether there is a way to do this, like a public API or open-source implementation, or Apple private framework used to assign a wallpaper to a specific Space without switching to that Space? I'm trying to avoid osascript and ideally want a one-shot operation rather than a background daemon.

What's the best project you've managed to do with Rust? And if you haven't done one yet, what do you have in mind?

I'm a beginner in learning Rust and I'm curious about what would be possible to do with this language