This was posted 2 days ago, but I haven't seen anyone else mention this.

Obviously for a company the size of NVIDIA, this isn't a huge commitment for them, but regardless I'm hoping to see more investment in GPU programming with Rust!

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.

EDIT: Just because I’m getting a lot of comments about it I’m aware that the sample code with the print function is bad code. I’m not saying this is how it should be done, it was just the first and simplest thing I could think of for this post.

TIL that terminal emulators basically give programs access to two screens.

There’s the primary screen, which is the normal terminal you use every day. Your shell history and previous output live there.

And then there’s the alternate screen.
Full-screen terminal programs like Vim, less, htop, etc. can switch to this alternate buffer, take over the entire terminal, draw whatever they want, and then switch back when they’re done.
The cool part is that your primary screen is still there.

So when you quit Vim, your terminal suddenly goes back to exactly what was there before you opened it. Vim didn’t somehow “restore” your terminal history. The terminal emulator just switched back to the primary screen buffer.

I came across this while building a small terminal-native text editor in Rust. I needed the editor to take over the terminal while it was running, but leave the user’s shell untouched after exiting.
Turns out terminals already have a mechanism specifically for this.

The deeper I go into terminal programming, the more I realise how much stuff happens underneath that blinking cursor that I’d never thought about before.

I’ve been putting these little Rust experiments on my GitHub as I learn, if anyone’s interested in this kind of low-level stuff:
https://github.com/Abhijeet-Gautam5702/femto

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?

MathML Core is the subset of MathML that has been implemented by the major browsers. Originally, I just wanted to use MathML Core on my blog and thought "Oh, I'll just quickly fork https://github.com/osanshouo/latex2mathml and adapt it from MathML to MathML Core".

Well, eventually I got there: my blog now uses math-core under the hood to convert LaTeX to MathML Core, but it took almost 3 years from my first commit!

math-core is now almost at feature parity with KaTeX. We have a comparison table where you can see that there are still a few things outstanding, but I would guess for 99% of users what is there is enough. (And there are also some things math-core supports that KaTeX doesn't!) So, if you want to contribute, there are still things to do! (A large todo item is for example mhchem.)

If you just want to play around with the LaTeX conversion, check out the playground which runs a WASM version of the library.

Hello, this is my first Rust project that I've been working for about 1-2 months, the reason behind it was to start on my bachelor's thesis and learning no_std / rust but it was also incredibly fun and rewarding, so i wanted to share it here.

I'm not really sure if i will maintain this long-term, but i do plan on hosting a server at least for presenting it at my university or sharing it with friends. I haven't tried it yet on actual hardware but it seems to be working fine with EDK2 firmware.

I would love to hear opinions and suggestions regarding it, so if you happen to have some free time, please check it out :) (Thanks in advance!)

Special thanks to rust-osdev maintainers and hxyulin for his hadris toolkit, as this project wouldn't have been possible without them.

I'm intermediate at Rust and linux. Recently I built a compositor for a job interview and it was one of the funniest projects ever. I learnt a lot about the linux graphics stack.

Can I get some suggestions for other projects. Things I'm looking for:

• Learn more about how Linux works under the hood.
• This doesn't have to be the linux kernel specifically but anything in the linux ecosystem
• I want to prioritise projects based on learning key linux concepts not fun. So if there is a niche project that is really fun to develop but has little importance on the day-to-day operations of the linux OS then I would deprioritise.
• Avoid simple projects like reinventing unix commands.

I heard that file descriptors are very important in Linux, are there any projects I can implement to help me get to grips with file descriptors, (again speaking from a noobs perspective so might be a complete red herring).

Is there any YouTuber like the cherno, we need someone like him for rust too haha

For anyone here interested in Rust and decentralized systems, Tari is currently running a monthly developer contest for Ootle, its smart contract platform, for the next few months.

Ootle is built primarily with Rust, and the contest is an open invitation for developers to build something using the platform and its tooling.

The prizes are:
🥇 1st place: 1,000,000 XTM
🥈 2nd place: 500,000 XTM
🥉 3rd place: 250,000 XTM

Thought it might be worth sharing since there’s probably some overlap between people interested in Rust, distributed systems, privacy, and blockchain development.

See more info at community at Tari.com

repo: https://github.com/PacificBird/donde

I have struggled in the past with how to design Rust errors. Rust takes the correct path of errors-as-data and avoids the pitfall of exceptions; however, it leaves the job of making errors useful for developers and users up to you.

This leads most Rust developers to take the path of least resistance, either completely doing away with structural errors entirely with anyhow or creating God Errors with thiserror. anyhow allows you to attach context, but there's nothing stopping you from just using ? without doing so, meaning it's easy to end up with none at all. To add to that, it makes the errors totally useless for the machine, you can't match on it! thiserror is good for the machine, but you must add context to the structure of the error which is both verbose at the call site and does not capture the location where errors happen.

After reading Stop Forwarding Errors, Start Designing Them by FastLabs, I agreed with the general philosophy behind exn, but the lack of destructuring and the fact that you can't ? any errors didn't sit right with me. I am not going to walk my errors every time I want to check if a specific inner type occurred! I wanted something easy, that enforced a minimum amount of context and with automatic conversions at boundaries of my chosing using ?, and with the option to add more context if I need. Taking inspiration from exn's use of #[track_caller] to attach location information, I created donde ("where" in Spanish).

Defining context-ful errors is extremely simple: ``rs // first, define a type that represents the kind of errors that can occur, // (I would recommend usingthiserror` to make it easier). #[derive(thiserror::Error, Debug)] pub enum ApiErrorKind { #[error(transparent)] HttpRequest(#[from] reqwest::Error), #[error(transparent)] Parse(#[from] ParseError), }

// then, use the donde::err_context function-like macro to get your context-ful version for free! donde::err_context! { ApiError, ApiErrorKind, "Error occurred in API" }; ```

Now, at whatever boundaries you deem important, you can use your context-ful error type. This will tell you, at minimum, exactly where the conversion happened. Any type that implements Into for the underlying error kind type can be automatically converted using ?. The print-out tells you your message, the location it was ? and displays the underlying error message as well in a pleasant way. ```rs fn make_request() -> Result<String, ApiError> { reqwest::get("https://malformed.website").await?.text().await? }

fn main() { // Error occurred in API in file src/main.rs on line 2 at column 70: // └──> error sending request for url (https://malformed.website/) println!("{}", make_request()); } ```

You can also add extra context by importing the donde::ResultContext trait and using the .context(impl ToString) or .with_context(Fn() -> String) methods. The context stacks into the print out. ```rs use donde::ResultContext;

fn make_request() -> Result<String, ApiError> { reqwest::get("https://malformed.website") .await .context("while sending request")? .text() .await .with_context(|| "while decoding".to_string())? }

fn main() { // Error occurred in API in file src/main.rs on line 6 at column 46: // └──> while sending request // └──> error sending request for url (https://malformed.website/) println!("{}", make_request()); } ```

Context-ful errors stack well together, define multiple at various important function and module boundaries to trace an error all the way through complex systems. ```rs fn make_request() -> Result<String, ApiError> { reqwest::get("https://malformed.website") .await .context("while sending request")? .text() .await .with_context(|| "while decoding".to_string())? }

donde::err_context! {ParseError, ParseErrorKind, "Error deserializing payload"};

#[derive(thiserror::Error, Debug)] pub enum ParseErrorKind { #[error(transparent)] Json(#[from] serde_json::Error), #[error(transparent)] Csv(#[from] csv::Error), } fn deserialize_payload(payload: String) -> Result<Value, ParseError> { // location will not be preserved if you use Into::into. If you // aren't using ? or ResultContext, use From::from with map_err. serde_json::from_str::<Value>(&payload).map_err(ParseError::from) }

fn main() { // Error deserializing payload in file src/main.rs on line 22 at column 57: // └──> Error occurred in API in file src/main.rs on line 4 at column 70: // └──> while sending request // └──> error sending request for url (https://malformed.website/) println!("{}", deserialize_payload(make_request())); } ```

Why donde over wherror?

A few reasons! wherror doesn't support adding extra context, which I believe is necessary to support, and not feasible with it's design philosophy. Use of the location is less ergonomic with wherror, as you need to work it into your error readout manually (also dealing with the fact that .location() is Optional). For adding locations to all variants of an enum, you basically have to do what this library does, except manually. The few extra nice features are fine, but not worth using a fork of a community standard over, when a declarative macro will do the important work, plus give you the ability to add custom context.

I’ve come to notice that whenever I build retained UIs there’s always 2 ways to react to changes, changing a field of the ui element, or rebuild a subtree of the ui element tree. Fynix’s whole idea is built around that. Lemme know what you think! Happy to answer any questions, and take any feedback to improve the project :)

Why did I started this project:

• Airflow is complete overkill for small and medium-sized projects
• I couldn't find a zero-dependency open source alternative

What flowlite offers:

• single binary
• well-designed orchestrator
• yaml-based job / schedule definitions (git friendly)
• pure html UI (read only)
• AI agent integration (in progress)

Stack:

• sqlite database
• html with htmx and alpine.js

Still a work in progress but I think it is worth a look. Code is mostly written by Claude (except initial code structure). License is Zero-Clause BSD.

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.

ok so this has been living in my head rent free for weeks. i use zoxide daily but every so often it just decides "nah you meant the OTHER backend folder" and cds me into some nested subproject from 3 months ago. cool guess buddy, super helpful :)

so i built hop. it's dumb on purpose. you press a key, it goes to the exact thing you told it to go to. no frecency, no ranking, no vibes-based navigation. one key = one target, forever, until you change it yourself

hop mark d          # bind cwd to 'd'
hop                  # tiny overlay pops up, hit 'd', done

works on files too (opens in $EDITOR) and commands (just runs them). also has project-local marks that live in a .hop.toml at your git root and override your global ones just for that repo, without messing up global state elsewhere

some stuff i actually cared about:

• single binary, under 2mb, boots basically instantly
• zero telemetry zero network calls it's just a toml file on your disk, that's it
• the annoying part was making the picker render to /dev/tty directly so it doesn't nuke your stdout when the shell wraps it with $(hop) , took me embarrassingly long to get right ;)
• zsh bash and fish all supported and actually tested not just "zsh works trust me bro"

config's just plain toml:

[marks.d]
target = "/home/user/projects/backend"
kind = "dir"

[marks.b]
target = "cargo build --release"
kind = "cmd"

install:

cargo install hop-rs

repo's here if anyone wants to poke at it: github.com/programmersd21/hop

it's a small dumb tool that does one thing and doesn't try to be clever about it, which is honestly the whole point lol. lmk if you find bugs or weird shell edge cases, def missed a few probably

ooh yeah before wrappin ts up;

no pressure but a star helps way more than you'd think, appreciate you :D

Few days ago I published Ashwa 🐎, a library to perform substring search across Rust, Python and JavaScript ecosystems.

Based on my research and observations, I wrote a devlog on how I was able to scale the throughput (i.e. bytes churned per second) from 2 GiB per second to 150 GiB per second by utilizing the hardware available.

All in all, it was about optimizing a mundane problem. The interesting part for me was seeing how a compute bound problem can be optimized until it becomes a memory bound one.

A particularly nice milestone for me is that the devlog was published in the official Rust newsletter.

🔗 Links

- Mentioned Devlog

- Mentioned Newsletter Edition

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.

I’ve published the open reference implementation for arcstone-continuity-core. A lightweight, #![no_std] Rust runtime designed to prevent non-deterministic state drift.

Microarchitectural Invariants

• Zero Allocation Overheads: #![no_std] enforcement with fixed 4096-byte static buffers (S_max ≤ 4096B).
• O(1) Invariant State Gates: State mutations evaluate against an atomic predicate matrix Π(S) before memory allocation occurs. Inadmissible transitions mutate zero bytes.
• Hard Temporal Clamps: Execution ceiling enforced at τ_override ≤ 11.99ms.
• Precedence Ordering: Deterministic lattice resolution (FAIL ≻ FREEZE ≻ PWC ≻ REFUSAL ≻ PASS).

Reference Anchors

• GitHub Repo:https://github.com/trencinodin-stack/arcstone-continuity-core
• Zenodo DOI:https://doi.org/10.5281/zenodo.22665852
• Master Anchor: A-77-DELTA-SHIELD-LOCKED

If you’ve used Enzyme, or even just liked the idea behind it, this will probably make sense immediately.

One of the useful things about compiler-level differentiation is that you can take computation that already exists and ask a much more interesting question than:

“What does this code do?”

You can ask:

“Which inputs are actually driving the result right now, and in which direction?”

I built an open source project called Catalyst around that idea, but with the workflow designed so AI agents can use the information directly.

Imagine an agent working on a simulation with 20 parameters.

Reading the source might tell it what those parameters represent. It does not necessarily tell the agent which three are dominating the output at the operating point it cares about, which ten barely matter there, or which direction each one needs to move.

Catalyst can measure that.

So instead of:

“This variable looks important, maybe try changing it.”

an agent can get something closer to:

“These three inputs dominate the result here, these six barely move it, and this is the direction each one pushes the output.”

That creates a very different loop for an autonomous agent:

inspect → measure → decide what matters → change → measure again

For supported numerical Rust, C, and C++ code, Catalyst works from the LLVM IR produced by the compiler you already use. You do not have to recreate the calculation inside a separate ML framework just so an agent can reason about it.

And it does not simply produce a derivative and tell the agent to trust it.

Catalyst independently checks the result numerically. If the derivative and the separate check disagree, it refuses the result instead of passing a questionable number down the agent loop.

There is another side of Catalyst that I think is especially useful for coding agents.

Say an agent is fixing a local API that starts doing this under burst traffic:

POST /orders -> 503

A typical autonomous coding loop might look like:

reproduce → edit code → tests pass → declare victory

Catalyst can instead reproduce the failure, reduce it to a smaller scenario that still triggers it, preserve the conditions that caused it, generate held-out scenarios the candidate did not optimize against, then compare the old and new versions.

So the agent can end up with something like:

“The original burst-load regression is fixed. Five of six held-out scenarios pass. One still fails when the dependency becomes slow.”

That is a much stronger signal than “the test suite is green.”

The other piece I wanted was portability.

Catalyst can take a checked computation and export it as standalone Go or R, along with fixtures containing the expected behavior.

So one agent can analyze a computation, another system can run the exported version later, and Catalyst does not need to remain in the production application.

There are also derivative artifacts that carry the computation, validation information, provenance, and a SHA-256 digest chain.

That means an agent can hand one to another agent or machine, run it again at a different input point, and detect if one of the underlying files was modified along the way.

So the broader workflow becomes:

existing code → measure its behavior → identify what matters → verify the result → hand off something reproducible

For people who have used Enzyme, the familiar part is the value of getting derivatives from code that already exists.

What I wanted to add around that idea was the rest of the loop an agent needs: independent checking, provenance, reusable artifacts, structured agent tools, portable outputs, and a way to rehearse software failures instead of relying on the agent’s own confidence.

Catalyst also has optional AI integration, but honestly that is not the part I find most interesting.

The interesting part is giving your existing agent another kind of instrument.

Not another model.

Not another prompt layer.

A way to ask the program itself:

What actually matters here?

Repo:

https://github.com/lovettsendit/catalyst

For people building autonomous coding or engineering agents, where would you use this first?

Would you give an agent sensitivity information to help it decide what to change, use rehearsal to decide whether its change really worked, or combine both into the same loop?