Hey everyone!

My team and I recently published a paper called "Rust Without Shortcuts: What Safety Actually Costs."

We compared 10 programming languages across 14 different workloads to better understand Rust's performance and the cost of memory safety.
I'd really appreciate any feedback! (What you liked, hated and need to be improved for future versions). Thanks!

We run Shieldify, a small European L7 DDoS protection service. Until 18 October our edge ran on OpenResty. Now it's our own reverse proxy in Rust, working together with an XDP program in the network driver. In October it took two HTTP/2 floods, the larger at about a million requests a second from roughly 889,000 addresses. We wrote up where those packets went:

https://shieldify.ee/research/where-a-flood-goes/

Some notes on the Rust side, since that's what this sub cares about:

• Stack: tokio (multi-threaded, work-stealing), hyper 1 and h2, rustls with the aws-lc-rs provider.
• Why we left OpenResty: nginx workers share state through lock-guarded shared-memory dictionaries. Under a flood every request touched that state and the workers waited on each other. One process with its state in thread-safe structures removed that.
• Why not Pingora: we studied it closely and still use it as a reference. But it's pre-1.0 with breaking changes in most releases, its HTTP/1 parsing is permissive by design to tolerate odd origins (at the very front we wanted the strictest parser we could get), and per-handshake certificate selection needs OpenSSL or BoringSSL, while we wanted rustls.
• Edge to XDP: the edge writes its verdicts straight into BPF maps that the XDP program reads, so a decision made on an HTTP/2 stream reaches the driver without a helper process in between.
• The WAF (OWASP CRS through a C library) runs on its own fixed pool of OS threads, so CPU-heavy inspection never blocks the I/O runtime.
• No GC pauses in the middle of a flood, and memory safety in the code that parses everything the internet sends, were the other two reasons for Rust.

Happy to answer questions about the Rust parts. I'll stay away from detection specifics, for obvious reasons.

Yesterday I stumbled over something I had never thought about before although I had that use-case a few times...

I have an option and an expected value and I want to check if the option contains the expected value.

There are several ways to express this.

For example:

if option == Some(expected) {...}

if let Some(actual) = option && actual == expected {...}

if matches!(option, Some(actual) if actual == expected) {...}

if option.is_some_and(|actual| actual == expected) {...}

There are probably even a lot more ways to express that and yesterday I suddenly wondered which is the "best" one, e.g. regarding readability and regarding performance. I also asked an LLM and it hallucinated option.contains(&expected) as the best solution, which would indeed be pretty nice if it existed...

Anyway, in case you wonder, here's the obligatory godbolt link: https://godbolt.org/z/v7odGdWP1

With optimizations enabled, it all boils down to the same assembly, so you can choose whatever you like most. In my case, I chose the first variant.

I have also tried with &str instead of usize and it's the same result: no difference with optimizations.

Any thoughts on this? More insights probably? The LLM generated a lot of blabla regarding certain nuances and cases (references, non-Copy, non-PartialEq) but I am not sure if I'd trust that and too lazy to check it.

Just wondering if I can lower the build times for my rust microservices (currently ~5mins for all of them combined on github actions). I already am using cargo-chef in my docker file. But I wonder if this is the right approach

https://www.redox-os.org/news/nlnet-rb-summary/

Lets say that I have a program that loads 3d models from a "./res" folder.(
src/
res/
Cargo.toml
,..
)
What would be the best way to load them?
Of course I could just use "./res" but then after building the project, the binary in ./target/ won't have access to that folder with the path.
So what is the correct way? Create a build.rs with env, use the target-path in the code or some other way?
I'm kinda new-ish to Rust so there is probably something I'm missing.

Thanks!

Wild version 0.11.0 is out. Wild is a fast linker for Linux and Wasm.

That's right, Wasm is now a supported platform! The Wasm port is working reasonably well and has great performance. The Wasm port was largely done by lapla-cogito during GSoC 2026.There are of course still a few things to be done like debug info.

Linker script support has advanced considerably. This is largely the work of vishruth-thimmaiah during GSoC 2026.

Lots of work has also been done on the Mac port, which is now to the point where at least one of the maintainers is using it as their default linker for Rust on Mac. It's not yet stabilised and there's still plenty to be done.

We've had some performance gains and losses that to some extent cancel each other out. Some performance was lost by adding proper COMDAT support. For Rust code, which is pretty light on COMDAT usage, the impact was around 1.5%. On the up-side, some OS-level tweaks were made that fixed performance issues when the output is on filesystems like EXT4. We also now cap the maximum threads at 32, which fixes scaling issues that we were hitting beyond that point due to contention on a per-inode cache lock in the Linux kernel.

You can read the full release notes here: https://github.com/wild-linker/wild/releases/tag/0.11.0

cargo-auditable embeds the dependency list into compiled binaries. This lets you use tools like cargo audit and many other scanners to check compiled binaries for known vulnerabilities.

Starting with v0.7.7, cargo auditable also works for microcontroller firmware! The audit data is embedded in the firmware image, but is not flashed onto the space-constrained microcontroller. This keeps the image auditable without wasting precious ROM.

Achieving this was both surprisingly easy and surprisingly tricky. Not wasting precious ROM was surprisingly easy: simply don't set SHF_ALLOC flag in ELF files for the audit data, which we were already doing. The tricky part was interacting with the linker.

rustc does technically support passing flags to the linker, but it's very difficult to use in practice: on most platforms the C compiler is used as the linker, so you have to prefix flags intended for the actual linker with -Wl; but certain platforms - mostly embedded ones - use the linker directly, so -Wl would break the build. There is no way to tell which one it is on stable Rust, so I had to resort to a sneaky "pretend you're nightly rustc" flag for running rustc --print target-spec-json (and nothing else).

The alternatives are worse: either extract the data from some rustc version and hardcode it, or try to parse non-machine-readable output of rustc as it compiles and links something, both of which drift even more easily.

I'd love to see a rustc --print linker-flavor command if it's easier to stabilize than the entire target spec format. But the linker flavor key in the target spec doesn't look like it'll change, so the current solution works surprisingly well, and any breakage to the nightly-only flag won't affect the Tier 1 or most of the Tier 2 targets at all.

I feel like ownership and lifetimes are concepts that make a lot more sense once you've had to deal with them in an actual project rather than just working through tutorials.

It's one thing to understand borrowing rules in a small example, but it's another when you're building something with shared state, async tasks, complex data structures, or APIs that need to stay ergonomic.

I'm curious which projects forced you to rethink how you structure your code. Did you end up changing your data model, using Arc or Cow, introducing a different abstraction, or realizing that you were fighting the borrow checker because your original design was wrong?

I'd especially like to hear about situations where the solution wasn't simply adding .clone() everywhere.

What Rust project or debugging experience finally made ownership click for you, and what would you do differently if you built it again?

fn player_turn(hand: &mut Vec<Card>, dealer_hand: &Vec<Card>){
    let mut done: bool = false;
    while !done{  //cannot apply unary operator `!` to type `bool`
        display_hand(hand, false);
        display_hand(&dealer_hand, true,);
        let choice = get_input();


        if choice == "h" {
            deal_card(hand);
        } else if choice == "s" {
            done = true;
        }


        if hand_value(hand) > 21{
            done = true;
        }
    }

I'm pretty new to computer science and this is baffling me

I've read that in C++ you have many ways of shooting your own foot or something but there aren't any good game engines designed for Rust. I've heard of Bevy but I've heard that it's better to stick with Unity or Unreal as Bevy needs time to be at a good enough level. So the question boils down to should I learn Rust or C++?

I have a `HashMap<Coord, Box<dyn BlockEntity>>`. During a tick I need to iterate over entities and, for each one, get a mutable reference to it while also getting immutable references to other entities in the same map.

Performance is critical here, so I want to avoid Mutex, RwLock, RefCell. Right now I use UnsafeCell. I'm rebuilding something like Minecraft's block-entity tick loop (you've probably heard of it).

I've also considered a smarter iterator that marks an entry as "taken" and returns `Option` on conflicting access — something like `(&mut elem, &mut NonGrowingHashMap)` from `HashMap::smart_values_mut()` — but I'm not sure whether such a pattern exists in the ecosystem or whether it's worth building. Are there other known patterns or approaches in Rust for dealing with this kind of access?

Trying to write something useful as a means to get to know Rust I went for an GUI app.

Based on my research I started with egui and muda to provide a basic menu. However I already fail (on MacOS) as the menu is not triggered before I enter the application area, which would trigger a repaint and by that execute evaluation of menu events. My menu contains only a "Quit" entry as of now and the app doesn't even display anything yet, it's just the main window.

I looked at other apps but they often look non-native e.g in regards of context menus.

Is there a stack which alllows to write native looking apps and ideally are there apps which use this libraries in a good way? Most examples are so minimalistic that it's not clear how to get more complex scenrios running from there.

To be clear, that's not a rant but rather me being lost in all the possibilities and how they fit together (I saw winit, tao, muda, ...endless possibilities)

I’m developing epicenter using only features Cargo already provides to cut compile times and disk usage. The main one is a shared build-dir plus a store of already-compiled dependencies, so rustc doesn’t rebuild the same deps for every new project. On top of that I switched the linker to rust-lld and enabled incremental compilation for all profiles.

These three together already cut build times and disk usage significantly, but my goal is to push both as low as possible, so I’m willing to accept trade-offs (e.g. less debuginfo, slightly slower runtime in dev builds) as long as the defaults stay safe for most users. Is there anything else I’m missing? I’m thinking of things like split-debuginfo, reduced debug levels, per-package opt-level overrides for dependencies, or other Cargo/rustc settings that are not enabled by default but would pay off in this setup.

Ochre is a Rust voxel project I've been working on since 2021.

Open source on GitHub: https://github.com/rornic/ochre

It started as a simple Minecraft clone using Amethyst's ECS library and plain OpenGL bindings through glium, but I migrated it to Bevy a while back to make the most of the ecosystem.

Some cool features:

• Terrain streams in around the player and falls back to coarser LOD meshes with a cross-fade, so the curved horizon reaches 16km at the default render distance, increasing to 32km with altitude.
• 64 km x 64 km deterministic world. Droplet erosion carves valleys, hydrology routes rivers to lakes and the sea, and a climate pass sets temperature and moisture.
• A day and night cycle with sun, moon and stars, atmospheric scattering, volumetric clouds and weather including rain.

Built and tested on an aging RTX 2060 which currently begs for mercy at 1440p on 32km render distances. Ryzen 7 9800X3D crunches through chunk generation and meshing in an instant. Would love to see how this melts more modern GPUs!

I've found using a pure Rust engine like Bevy to be a great accelerator for AI coding harnesses too, really easy to do performance A/B tests on new engine features.

I'm the author of a set of Rust crates that implement EtherNet/IP and CIP Safety on tokio.

Most existing EtherNet/IP libraries, like the excellent rust-ethernet-ip, focus on reading and writing tags. I set out to cover all of EtherNet/IP. You can read and write tags, and you can connect as a Class 1 scanner to read regular and safety I/O. You can also act as a regular or safety I/O device, as a Class 1 adapter. There's a simulated controller stack that serves tags, so you can connect an HMI to it, and you can send and process any custom Class 3 message.

Sibling implementations with the same wire behavior exist in C#, Python and C++. They don't share types with rust-ethernet-ip today, but I'd be open to adding conversions with its types crate if there's interest.

Everything is free and open source on GitHub, with nothing for sale: https://github.com/CristianMori/EthernetIpRust

Feedback is very welcome, especially from anyone doing industrial or embedded Rust.

Two months ago I posted here about running rustc, cargo and lld as WebAssembly on an iPad. I said I had no rust-analyzer: I had compiled it to wasm and measured it, and the proc-macro and std source costs looked too high for a tablet. It's in the app now, with a catch: it only runs when the device has the memory for it. The editor is also native now; it was Monaco in a web view then.

The screenshot is the editor with the debugger paused at a breakpoint.

What I use rust-analyzer for first is color.

Before rust-analyzer is warm, the editor is colored by a tree-sitter highlighter, and the status line says "basic colours". When rust-analyzer finishes indexing, its semantic tokens replace those colors. Both servers are translated into one vocabulary, so a word whose category doesn't change keeps its color. What rust-analyzer adds is the distinctions a grammar can't make: a trait versus a struct versus an enum versus a type alias, a method versus a free function, a macro_rules macro versus a proc-macro, value parameters, lifetimes, Self, the mutable modifier, items from a dependency crate, and unresolved references.

The memory rule, since that's the interesting part. The default is "Auto":

- device with 6 GB or more: full rust-analyzer when there is headroom, otherwise a reduced mode

- device with 4 to 6 GB: the reduced mode when there is headroom, otherwise off

- device with under 4 GB: off

"Headroom" means no memory-pressure warning and more than 2000 MB available. Pressure steps the level down one notch, and a warning expires after 45 seconds of quiet. During a build, if available memory drops below 2000 MB, rust-analyzer is released so rustc has the memory, and in Auto it comes back when the build ends (it retries every 5 seconds for about two minutes). If rust-analyzer fails to start, it is retried after 5, 20 and 60 seconds. You can also force it on, off, or to the reduced mode in settings.

The reduced mode drops the Cargo dependency graph, the crate index and code lens, the chaining, closure and borrow hints (type and parameter hints stay), and files over 200 KB. The cost is real: without the graph, crates show up as "missing reference". The graph itself needs a device with at least 7000 MB and at least 3000 MB available, and the editor doesn't attempt one for projects over 120 crates. Proc-macros only expand when a compiled reactor for that crate is already cached, otherwise the crate stays unexpanded for that graph load.

Numbers, with a caveat: I don't have an on-device warm-up time I trust yet. These are from running the same wasm under Node on a Mac:

- warm-up in a single-file project: 1.3 to 2.7 s, heap about 220 MB

- a small project with a couple of crates: about 300 MB, 1.9 to 2.2 s

- a project with 93 crates: about 500 MB, 3.4 s (about 3 MB per crate)

- semantic tokens for a 3,100-line file: 128 to 213 ms cold, 36 to 53 ms warm

- the rust-analyzer wasm is about 16 MB, built from the 2026-08-31 tag with Rust 1.98.0 for wasm32-wasip1, optimized with wasm-opt -O3

I also added GitHub Copilot after people asked for it in that thread. It uses your own subscription.

Same disclosure as before: it's a paid, closed-source app with a free tier for single files, I'm the author, and it's in TestFlight beta: https://testflight.apple.com/join/4Yaujqd5

I'd like to know where it falls over: crates that fail to build, rust-analyzer colors or diagnostics that differ from a desktop, and any device where the memory rule picks the wrong level. I'll be traveling for most of November, so replies may be slow.