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.

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++?

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

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)

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 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.

Do you think < as a rust experts and users > I should build my app using tauri - Rust or not.

Can you make me switch.

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.

If you have a personal example of a situation where you wanted to go with rust but went back to js I would appreciate that too.

I wanted a coding agent that felt like Neovim: fast, light, and customizable. So I spent the past 8 months building smelt.

A few Rust bits:

• Its own terminal renderer and layout engine instead of ratatui
• A Lua plugin API (via mlua) for keymaps, tools and the UI
• Crates usable on their own, like smelt-term

https://github.com/leonardcser/smelt

Any feedback is welcome!

Hey everyone, are there any GitHub repos or templates that help set up an offline-first Rust environment? I need to cache all toolchains and vendor dependencies while online so that building and deploying works completely air-gapped, like during a prolonged wartime internet blackout in Iran.

More boot fixes, external display hot-plugging, page fault handling and more JIT support, big performance improvements, rlimit support, uutils 0.11, web fixes, better SDL2 performance, Clang port, i586 dynamic linking, better terminal and debugging, and many more.

https://www.redox-os.org/news/this-month-260930/

Notes, code and benchmark: https://github.com/VAHPEM/rust-deobf

I've been studying how Rust string-obfuscation crates behave once compiled, mostly in the context of malware analysis, and wanted to share a few observations.

- In the tested obfstr and litcrypt cases, the original string literals don't appear as plaintext in the binary, but the decoding logic remains executable. Emulating the relevant routines is enough to recover the strings, even with opt-level = "z", fat LTO, and panic = "abort".

- In my tested binaries, panic::Location information remained available after stripping. When source paths are preserved, paths such as .cargo/registry/src/.../<crate>-<version>/... can reveal exact third-party crate versions. Compiler-related source paths may also provide clues about the Rust toolchain.

- A small litcrypt quirk: lc!(r"...") keeps a leading `"` in the decrypted value, so the program really builds `"C:\...`.

If you maintain a Rust string-obfuscation crate, or have tested one that behaves differently, I'd be interested in comparing results.

Maybe you are just like me a few months ago: not sure about the feasibility of developing apps in Rust.

Now I can tell you: Rust is the perfect programming language for any apps with some actual complexity.

I am not talking about simple TODO apps. I am talking about apps that consume a lot of computation power and memory.

So far I have developed 2 apps with React Native + Rust. React Native is for UI/UX and platform-specific code, while Rust powers the core logic and state. Both iOS and Android are ARM and we know how good the Rust cross-compilation toolchain is.

The motivation for building both is for my daily use. Both are not toy projects. One of them(a Herdr/SSH client) got 200+ installations on Google Play.

It feels so nice to hold your Rust code in hand, knowing that it is using your phone's battery and memory efficiently. I started without Rust and then gradually mitigated Typescript into the Rust code. Profiling with Perfetto shows a significant decrease in latency and memory usage. The app that used to heat up my phone now feels like a breeze.

The major overhead of the mix of React Native + Rust is FFI crossing. However, if the Rust core contains almost all the states, we can minimize the data movement cost.

Therefore, for the sake of battery, memory and memory safety, please use Rust to build your mobile apps!