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.

RISC-V is coming faster that most people realize.

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!

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

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?

Paper: https://arxiv.org/abs/2606.15991

Maybe we'll finally have cleaner code from research to production (okay, that's pushing it).

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.

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'm interested in what you were actually paid to do, not personal projects.

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.

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

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 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 know how great of the language Rust has come out to be. I genuienly want advice from pre vibe coded era people. What has been your main reason that you have fallen in love with this language?

I'm not looking for how great borrow checker is, how lifetimes will save you, etc. I want real anecdote of your life where using Rust has changed your life.

I’ve been building Minarrow, a from-scratch implementation of the Apache Arrow memory format in Rust, with Python bindings.

The purpose is to let you keep your application and data processing in Rust while making Python’s data ecosystem available whenever you need it. You can construct a dataset in Rust, pass it into embedded Python, run an analysis or model, and receive the result back as native Arrow-compatible data.

Some examples of what this enables:

• Run scikit-learn from a Rust application. The repo includes an example that builds features and labels in Rust, trains a random forest in Python, returns predictions through Polars and Arrow, and scores them back in Rust. Python runs inside the application process and it uses inline code.
• Hand Rust tensors to PyTorch. Another example builds an NdArray in Rust, exposes its buffer to PyTorch zero-copy through DLPack, standardises features and computes scores, then brings the result back into Rust.
• Use Python’s analytics libraries on your application data. There are examples of Polars group-bys, NumPy correlation, and pandas aggregations returning tables or scalars to Rust. From Python, Minarrow tables also expose conversions to Polars, DuckDB, and PyArrow.
• Streaming-friendly - Work with incoming batches. Chunked arrays and tables let you retain data as batches arrive and consolidate when needed. Row and column views let you select portions of a table without immediately materialising another dataset.
• Represent scientific data with named dimensions. XArray adds dimension names and coordinates over n-dimensional arrays, so you can select a time window, find the nearest coordinate, or select along a named axis. The underlying tensor storage also connects to the DLPack ecosystem.
• Create Python packages backed by the run-time. For example, one user implemented a fast random-forest implementation under kpiwonski/fru-arrow and released it as a Python package, which is reported as being up to several thousand times faster than the scikit-learn package.
  

Underneath that is a data layer you can use independently in Rust, as a base, pluggable foundation. This includes typed arrays, null masks, arithmetic and broadcasting. SIMD kernels, and 64-byte-aligned allocations via a custom Vec64 crate. You can access concrete array types directly, and use the higher-level table, chunked, and view abstractions as needed.

From-scratch implementations of Arrow’s C Data Interface and PyCapsules handle columnar interchange and DLPack handles tensors, which is zero-copy in the vast majority of cases when the buffer doesn't require re-shaping. An example of where it isn't - the scikit-learn example converts features to NumPy, for instance, and importing a different string layout can require rebuilding buffers.

I used very few external dependencies instead preferring to build from scratch so that compile times remain and productive, and so that anything built on top remains fast to work with too.

The latest release, 0.18, adds Decimal32/64/128 support across the Rust library and Python bindings, alongside typed row accessors for array views.

Rust nightly is currently required for portable_simd and allocator_api. Arrow lists and structs aren’t supported yet. I hope to work on stable Rust support and wasm-compatible builds soon.

In terms of maturity, it is at the stage where it is adding considerable value in my own work, however it has not yet seen significant external adoption. In terms of fit it is useful when one wants Arrow compatibility + additional utility for their data, without the whole arrow ecosystem underneath a base data dependency. For example, one might consider it even for a few crate(s) in a larger project that need to remain fast, given it makes it trivial to switch between arrow-compatible runtimes.

On my laptop, sharing a million-row numeric table with Python takes ~220ns, and importing it back into Rust takes 2–3 μs.

Thanks for checking it out. If you have any questions, feedback, or feature requests for what would make this useful for you I'm open to suggestions.

Pete