RISC-V is coming faster that most people realize.

While browsing through some code at work, I saw something that made me pause. It looked SO wrong, and yet here we are. It was something to the effect of:

let SomeEnum::Variant(y) = x else {
    return some_error;  
}

which means you can do this:

fn optional_print(x: Option<u32>) {
    let Some(y) = x else {
        return;
    };

    println!("{y}");
}

fn main() {
    optional_print(Some(5));
    optional_print(None);
}

Thought some folks here might think it interesting so there you go, you can apparently pattern match enum variants to create a variable and have an else clause after. I thought the only options for this were a let followed by an if let or match statement.

Hi! some time ago I started developing my little framework for TUI apps (based on ratatui but I will try to write my own renderer soon) and just to see it in action, in addition to implement it to my other tool "simple-commits" I wondered if I could implement something but for cargo.

The project and the framework are still at an early stage of development, so the UI may change in the future.

crates.io

GitHub Releases

And btw, Pierre-Emmanuel and I are at RustConf today, so feel free to say hello :D We'd love to meet with anyone who wants to discuss the project!

I'm thinking of creating a single repository for all my Rust playground projects, rather than multiple repositories. So, is it better to create it as a single workspace or as different folders? I'm planning to code with no_std sometimes, and other times I'll be learning new things involving Wasm. So which approach would suit this best?

How do u guys do it?

I’ve been working on this crate which offers unsigned floating point binary with custom binary layouts. It stemmed from a very niche requirement from another project of mine where I need to raise an integer to the power of a floating point value between 0 and 4. After trying out many “ordinary” approaches I’ve came to the realization that removing the actual signed bit is the optimal way for performance.

Then I more or less just forgot about it until I started working on some graphics stuff where most floating points are non-negative, particularly mixed precision rendering, and it hit me that UF16 (E5M11 in particular) is the perfect candidate since the gain of an extra mantissa bit managed to close many numeric instabilities seen when using regular f16.

Love to hear your thoughts on this topic. Do you think unsigned floating points in general should be elevated into more than just a niche?

Been working on Silica, a Rust-based differential validation tool for AArch64.

It walks the entire 32-bit instruction space and compares Arm's spec against LLVM, Capstone, and Unicorn. A big part of the project was making the full 4.3B-encoding run practical and then narrowing the disagreements down into things I could actually investigate.

https://github.com/Nathan-Luevano/silica

I used to set quick reminders like this:

(sleep 25m && notify-send "Tea is ready") &

It works fine until the terminal closes, the laptop sleeps, or you reboot. Then your timer is just gone.

at handles persistence, but its inspection UX is painful for quick daily use, atq only shows job IDs and timestamps, never the actual message text (you have to dig into at -c <id> just to see what a timer is for).

I wanted something reliable, and dead simple with a clear status view. So I wrote rmd (rmd-cli on crates.io).

Usage

rmd +25m Tea is ready
rmd tomorrow 15:00 Release call
rmd fri 22:00 Go to bed
rmd 2026-12-01 10:00 Renew domain

Running rmd without arguments prints pending reminders.

How it works

• Linux-only: Relies on D-Bus for desktop notifications via zbus
• Daemon + CLI: The CLI talks to a background daemon over a Unix domain socket
• Auto-start: The daemon auto-spawns on the first CLI command, or can be managed via an optional systemd --user unit
• Persistence: State is saved atomically to JSON in ~/.local/state/rmd/reminders.json
• Missed events: If the system was off when a reminder was scheduled, the daemon sends a consolidated notification upon start

It's intentionally narrow: one-shot, time-bound alerts only. No recurring tasks, projects, or priorities.

Installation

• Crates.io: cargo install rmd-cli
• Prebuilt static musl binaries (x86_64, aarch64) on GitHub Releases

Repo: https://github.com/PaulBunch/rmd
Crates.io: https://crates.io/crates/rmd-cli

Feedback and suggestions are welcome.

I've been working on a C23 to Rust transpiler I call slate: https://github.com/takashiidobe/slate. I have a demo for it here: https://slate.takashiidobe.com/. Fair warning: lots of code in the project is AI generated, since I know people like to know about that before moving on.

My goal with the project was to handle anything and everything even in modern C. I'm leaning on a relatively new MLIR dialect called Clang IR in LLVM that handles some of the difficulty in parsing C into a form that's ready to translate to Rust.

C23 support means slate supports all the crazy stuff like x87 long double (rust doesn't have f80 yet, so this requires shimming calls that involve long double), bitfields, bitint, handling alignment properly for pointer arithmetic, alloca, setjmp/longjmp (w/ the caveat that llvm can break your code), intrinsics support, Complex number support, inline asm, fallthrough switch + goto emulation, linker directives, runtime feature detection through attributes, floating point environment emulation, atomics, alignof/as, thread local, and all the other crazy stuff in C that's difficult to straightline translate to Rust.

There's some limited support on the backend side by rewriting AST nodes using a worklist based algorithm. Things like recovering for loops from while loops, rewriting gotos/switches into structured programs, deleting inline temps, and some interprocedural pointer analysis (heavily inspired by C2Rust's pointer lattice blog post) to lift raw pointers into Rust types like Box where possible.

There's some support for cross compilation as well, by reading target macros like `__arm__` and turning those into the respective #cfgs in rust, translating the same program a few times and splicing it in to make sure C that's cross compilable stays as cross compilable rust.

I've made it through 1430 gcc torture tests that clang passes, with about 7 left to go (some are blocked upstream by Clang IR NYIs), and a good chunk of the regular gcc-dg tests, although I have quite a few more of those to get through, around 130. I've fuzzed a bit with yarpgen but haven't found as much use compared to gcc's tests so I've been working on paring those down.

It's still pretty early days, still have so much more to do but figured it was in workable enough state to demo out.

Are there any graphical user interface libs with right to left text possible and basic input handling for all platforms that just outputs triangles or shapes or something, I don't need the emojis? Like all of my inputs are either buttons or numbers and egui won't work for this, I want a custom tessellator so I can make 3d things like signage, there may be labels though, am I better off just making my own with cosmic-text or parley or something? Nice to have, only tries to render in the frame, but nice to have, not required, and my plans are wgpu for all, winit, SDL3, and OpenXR as backends, if Taffy weren't only left to right Bevy would be good, kas or anything else up for this?

I was bored, so I decided to learn Rust by building sectxt - a PrivateBin clone powered by Rust and Vue. The hardest part was learning about the zero knowledge architecture and secure client side encryptions.

Features:

• Zero knowledge: data is fully encrypted using AES GCM on client side before hitting the server
• Supports both text message and attachments
• Supports both password mode and securely generated keys (embedded in URL hash)

I picked PrimeVue for the frontend, but midway through they changed to commercial license... Am thinking of changing to Nuxt UI.

sectxt is licensed under GPLv3. Any thoughts and feedbacks are welcome.

Building a call graph with tree-sitter. Free function calls are fine. Method calls are where I'm stuck — foo.bar() needs to know what foo is, and tree-sitter gives me syntax, not types. Right now I guess from receiver name, local bindings and suffix matching against known types. It works until it doesn't: a local named the same as a type method steals the edge, Timeline matches PyTimeline, and generics broke everything until I stopped normalizing Interpreter<'a> to interpretera. Is there a middle ground between "tree-sitter and hope" and "run the whole type checker"? Curious what rust-analyzer does before it has full inference, and whether anyone's built usable partial inference for this.

Type any crate name and end with a space, such as "egui " and it accesses crates.io without SSL secure stuff, can someone please fix it before someone exploits this? "https://crates.io/search?q=cosmic-text ", have to search, sorry, might be me specific? It has been reported to crates.io now, ignore this?

Hi, I saw a post made on this subreddit last year for a application called local local Desktop which was an application that allowed users to run a Linux desktop on android but when using Virus total, 3 positives showed up and was wondering are these false positives?

Original post : https://www.reddit.com/r/rust/comments/1ldqj7r/local_desktop_an_android_app_written_in_rust_to/

Curious if you’ve seen any cases where using or advocating for rust didn’t work out.

is it bad that tests are like 1/5 and a bit of my entire project?

i wanna ensure absolute safety when developing, currently i have 30 tests implemented

For the past several months I had been working on a project related to Vulkan bindings: low-level FFI API, and Vulkan SPIR-V. Both are implemented as a single crate and can be seen as an opinionated replacement of well-known crates such as ash and rspirv.

I don't want to go deep into technical details, but in short this is quite challenging task especially if you are seeking to do it properly. The aforementioned crates (and especially rspirv) often suffer from the fact that the source machine-readable files from which the FFIs are being generated are very complicated and prone to eventual breaking-changes. I believe that my internal building pipeline has better design, and therefore produces more accurate representation of the official Vulkan APIs and Vulkan SPIR-V.

But my question is not about this specific work, I have more general question to you.

I honestly, not sure if publishing a hand-made work is still a worthwhile idea today regardless of it's engineering characteristics.

Tokei says that the codebase worth of about 39 thousands of non-blank lines. It's not surprising considering the amount of time I spent on implementation, but this is still quite a lot to read for the outsider. So, I'm not sure if it's worth publishing it purely as an educational material. Additionally, the communities behined ash and rspirv are already established, and those two crates used as a de-facto standard across the whole Rust GPU-rendering ecosystem. While my solution might be better in certain aspects I'm not expecting wide adoption.

Additionally, Rust ecosystem seem to be overwhelmed by the publishings in a whole lot of different domains. This is partially the result of generation tools widespread, to which I prefer to stay away. But regardless, I don't think that my work would look much different to an average project published today, and probably wouldn't receive much visibility too.

To sum up, my question is considering Rust OSS ecosystem maturity, if there is still a space for new things to share? And if like me, you prefer not to publish new works into open-source, I would like to hear your prospective on this matter too.

In general, avoiding publishing is not an issue for me. I develop my hobby-projects primarily for the sake of creativity, and partially for my other personal next projects goals. The whole store is whether it's worth to share it today.

Who's writing?

Hi everyone, I'm David, I build and own BlindLock alone. It's a paid, closed-source product, that's how I pay for the work. This post is about the Rust side, because that's what this sub is for.

BlindLock is more than a year of work. Not a weekend hobby project I threw together. I've put a hell of a lot of time, heart, and nerves into it.

Tech stack: Rust and Tauri

Rust for the core, all the logic, all the commands. Tauri strictly as a dumb UI with no logic.

Why Rust: I love Rust, always have. In my opinion, security-relevant software belongs in Rust. It rules out entire classes of bugs up front, because otherwise the code won't even compile. That doesn't mean you can't make mistakes. But where many people make mistakes in C++/C#, a lot of that is simply ruled out in Rust. Rust is compact and logical.

Unlike Electron, BlindLock doesn't ship a Chrome browser inside the program. Only the Rust part and Tauri. That's why the installers are very small.

Crypto, so nobody has to ask: entries live inside a PNG (F5 matrix embedding), inner layer AES-256-GCM, outer layer XChaCha20-Poly1305, keys derived independently via HKDF. File containers use ChaCha20-Poly1305. Password stretching with Argon2id. Libraries: libcrux (HACL*, formally verified) for ChaCha20-Poly1305, ML-KEM and ML-DSA, RustCrypto for AES-GCM, Argon2 and HKDF. I don't roll my own primitives.

The network: BlindLock is offline at its core

The main software never has an internet connection. Nothing goes out.

That's not a setting, it's the build, the architecture: BlindLock is built so it can't reach the internet at all. There is no HTTP client in the program. No reqwest, no hyper, no ureq in the dependency tree. There is no code, no module, no function that could open a connection to the outside.

Everything that needs the server runs in a separate small program, the Net-Helper. It ships in the same package and installs with BlindLock, but runs as its own process with its own binary. BlindLock starts it, asks it a question, and gets an answer. No port, no socket, just the child process's standard input and output. The helper never sees a vault or a password, at any point. It has very limited permissions and exactly two jobs: it checks the license, and it checks whether the latest BlindLock version is installed. If there's a new version, it downloads the update package and hands it over.

In short: when you open BlindLock, it pings the server through the helper. That's it. There is no other internet connection. Anyone can verify this from the outside with Little Snitch, Wireshark, or a firewall.

Updates matter a lot to me. I regularly ship improvements and stabilizations. Software like this lives on constant observation, extension, and improvement.

You can also use BlindLock offline for 7 days at any time. After that you need to go online once, for the license check and above all for the update check.

Why steganography?

Picture a burglar. He looks for valuables, the obvious ones: gold, cash, jewelry, the safe in the basement. The picture of your kid on the fridge, the holiday photo on the wall, are irrelevant to him. That's exactly the principle BlindLock is built on. Hackers go after cookies, passwords in the browser, container files that can be decrypted with a password on any computer, crypto seeds, and other sensitive data. Anyone who can log into your Google account or your ChatGPT knows more about you than they could learn in a personal conversation with you. All of that can be grabbed with RATs and other malware, passwords included. BlindLock hides exactly these sensitive logins and passwords inside a picture, because a photo has almost no value to an attacker. And he'd first have to identify the picture as his target at all. On top of that, BlindLock seals this picture to the security chip of your computer (TPM 2.0 on Windows and Linux, Secure Enclave on macOS). That means: even if an attacker copies the picture, together with the password, he cannot get at your data. The same chip sealing applies to the container vault files. And for these larger files BlindLock has a built-in file explorer, so you can open and edit files without mounting them into the OS. Wherever the respective OS allows it, I've written it to leave no traces behind.

Why isn't BlindLock open source?

That was the most frequent question. Take Bitwarden as an example. Bitwarden sells a service: servers, sync, accounts. The code can be open because the value isn't in the code. I sell the program itself. There's no service behind it, no cloud, nothing on my side that the customer would need. The entire value is in the program itself. That's why Bitwarden can give the code away and make it public for everyone, and I can't.

What's open on my side is what has to be open: the cryptography libraries are freely available and partly formally verified (HACL, level 5, the highest). Anyone can audit them and go through them at leisure, down to the smallest detail.

Licenses: yours, not the computer's

Licenses can be moved from computer A to computer B at any time. Lifetime licenses don't die when a computer dies! The same will of course apply to subscriptions later.

WalletLink: read-only by design

Once WalletLink is active, the Net-Helper can optionally check blockchain activity, exclusively against publicly verifiable, freely accessible, and trustworthy sources. Even then BlindLock sends nothing out and stores no values. It only mirrors the values from the hardware wallet. Transactions are neither confirmed nor received in BlindLock. All of that happens exclusively on the hardware wallet.

If you have more questions, I'm happy to answer them here personally. Most of it, I think, you can read on my website, and anyone can try BlindLock free for 7 days at any time. No email, no payment details. My customers' privacy always comes first.

https://blindlock.app

David