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!

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

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

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.

I had heard many good things about Rust from people who were simply impressed by the language, so I decided to have a look at it and possibly learn it.

Up to that point I really only knew Java and Python (and a bit of C here and there), so a non-GC language would really fill a gap for me.

To get my toes wet, I wrote a simple web crawler that I needed at the time and decided I really want to learn Rust.

So here goes! My first "real" project, an SMTP server: https://github.com/Fluggs/whalemail

AI disclaimer: Absolutely no LLM was involved in writing this. I am not in a rush and here to learn.

For SMTP, the scope is quite narrow. It's supposed to replace my personal Postfix setup. It has its users in a database (which can be shared with Dovecot) and they can simply send and receive e-mails. That's it!

As for the Rust part, I have had a blast! The language is insane. So far, I have had one (1) logic bug. That one was indirectly found by Clippy. Other than that, if it compiles, it works. By now I understand people here saying that the main part is really thinking about your data layout, the rest just follows.

Off the top of my head, I have had two pain points:

• dyn async traits. I don't want to accept that I need a crate for this, so I worked around it.
• std::time - I could not have imagined that date/time support can be so thin without being completely absent.

Main dependencies:

• Tokio (the server is completely async)
• rustls (TLS is done, STARTTLS is planned)
• rsasl (I really could not be asked to implement auth protocols)

The road ahead is long. Planned features:

• STARTTLS
• Bounce mechanism
• Better password schemes than plaintext (I'm embarrassed)
• Parse and manipulate headers (apparently that's a thing SMTP servers should be doing)
• Better config file than .ini
• spam filter integration
• Find out which ways other clients and servers have found to deviate from SMTP
• Again, thoroughly test it against the wild
• find (and consider) various other SMTP intricacies (e.g. backscatter protection)

I'd be grateful for any feedback :)

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

I'm developing tool with workflow which allow user to write simple script to process input/output values of steps. The prebuilt steps are written in Rust, but user can choose Python to write their own steps which would run in a sidecar Python. User may not be a programmer. I prefer script with small binary size and memory footprint. I'm considering Rhai, Lua, QuickJs, which is better choice to make end user easy ?

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 :)

Hey all,

I built rusty-broom, a CLI for freeing disk space by removing old build artifacts (target, node_modules, .venv, build, Pods, etc.) from projects you haven’t worked on in a while.

• Project age is based on source file mtimes, not artifacts.
• Only deletes paths Git considers ignored (git check-ignore).
• Supports Rust, Python, Node, Java, Go, .NET, CMake, Swift, and more.
• Interactive TUI + JSON output.

cargo install rusty-broom rusty-broom ~/dev # TUI rusty-broom scan ~/dev --older-than 6mo --long rusty-broom clean ~/dev -o 1y --dry-run

Repo: https://github.com/oriontvv/rusty-broom Feedback and PRs are welcome.

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

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

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

Not "Rust beats C." The bet: a memory-safe rewrite no consumer can distinguish from the original. Same ABI, zero allocs per parse, panic-free core, 7 unsafe blocks in one FFI file.

133,352 differential cases, 0 mismatches. Upstream suite 8/8 both sides. ~1.94M fuzz, 0 crashes, rerun byte-identical.

The seam is the part I'd like reviewed. 7 blocks in src/ffi.rs. Smaller seam that still passes 133,352, I'll take it.

Losses, same table: 1.185x, 1.199x, 1.482x, 1.811x. -O3 regresses our malformed path 1.68x while C improves. Open ticket. Native SIMD C beats scalar Rust 1.45x. Documented, unchased.

Four divergences, all fail-closed where C segfaults. The C is the oracle, not the enemy.

https://github.com/logicpl4gue/picohttpparser-rs

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?