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

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

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

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

Can you make me switch.

AI agents can search the web, inspect code, and call external tools. But searching the contents of a user's local files especially screenshots, documents, and logs presents a different problem: the index needs to be fast, lightweight, private, and accessible to agents without uploading the files to a remote service.

I've been building Kensaku, an open-source desktop search engine written in Rust, to explore this problem.

The central idea is to maintain one local index that serves both the desktop application and compatible AI agents through MCP.

Hybrid retrieval. Kensaku combines fuzzy filename matching, BM25 full-text retrieval, and local semantic search. The goal is to handle both exact queries and cases where the user remembers the meaning of a document but not its wording or filename.

OCR and document extraction. The index can include extracted text from supported document formats and OCR-enabled image workflows, making screenshots and scanned content searchable alongside code and logs.

Lightweight semantic search. The project uses a static quantized embedding table of approximately 7.7 MB. Semantic queries do not require a GPU, and the default query path avoids running an ONNX model for every query.

An agent-facing search interface. The MCP server exposes the same index used by the application. Compatible clients can search, read snippets, perform regex searches, inspect index state, and find symbols. Access is read-only by default.

Performance and safety. The repository includes benchmark harnesses and tests. In the 100,000-file benchmark, fuzzy filename search has approximately 2.8 ms median latency. That figure applies to the benchmarked filename-search path, not every retrieval operation.

The project is MIT-licensed and designed to work locally without an account, telemetry, or cloud search.

There are still limitations: builds are unsigned, the auto-updater isn't wired up yet, and visual search remains experimental.

Repository: https://github.com/yjid/kensaku

I'd appreciate constructive feedback from Rust developers on the retrieval architecture, memory/performance trade-offs, indexing correctness, and the design of the MCP interface. In particular, I'm interested in how you'd approach benchmarking and evaluating search relevance across a large, heterogeneous local corpus.

EDIT ? WHY SO MANY DOWNVOTES ?

A .nvault volume is one file: two header copies, then a SQLCipher database holding the files, names, tags and passwords. Each password goes through Argon2id and wraps a random master key with XChaCha20-Poly1305; up to 8 passwords per volume, plus a duress one that destroys the keys.

Most of the work went into crash safety. Writes go through a journal, and the tests kill the process mid-write and simulate a power cut that drops unsynced writes, then check the volume still opens. The format is append-only: every release has to open a set of volumes written by earlier builds.

It mounts as a drive through FUSE or NFS on Linux and macOS and WinFsp on Windows, cross-compiled from Linux. The app around it is Tauri 2 + Svelte 5.

GPL-3.0. Linux and Windows work; macOS isn't fully tested yet.

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.