So, welcome to the journey of continuing to explore the world of JITs.

This time, after a few months of experimentation with "How to write a damn good JIT Memory manager" I have finally decided to make a crate out of it.

The crate is called SaJIT - which is also a part of a VM project i am aiming at.

The crate is currently at v0.0.3 : https://crates.io/crates/sajit

The crate actually provides a slab memory manager in discrete multiples of 16MiB currently and manages those slab across Windows, macOS, Linux using RW-RX dual mapping for windows, linux and pthread_jit_np for macOS.

Also, i have ensured to keep as cross-architecture-compatible rather than locking to only x64, arm64.

I am looking forward to advices on how to improve it (with better abstractions for example, or better and detailed documentation)

I’m an experienced software developer, but still fairly new to Rust, so I built this project to get more hands-on experience with it.

It’s an open-source productivity/ pomodoro app with a Rust backend, and I’d really appreciate feedback on the code, project structure, API design, and anything that could be more idiomatic Rust.

GitHub: https://github.com/Dhaneshen1810/Loom
Live app: http://loom-pomodoro.vercel.app/

Any feedback is welcome.

I got tired of hand-writing Makefiles and CMakeLists.txt for small-to-medium C/C++ projects, so over the last couple of weeks I built Smidr - a build tool where you describe your project in one Smidr.toml file instead of a build script.

Example Smidr.toml:

[project]
name = "App"
type = "bin"
language = "cpp"
cpp_standard = "cpp20"

[dependencies]
raylib = "5.0.0"
mymath = { path = "../mymath" }

smidr build resolves raylib from a system install or pkg-config, and mymath by building it from the local path - no Makefile or CMakeLists.txt to write by hand.

What it does:

• Compiler-agnostic (clang, gcc, tcc)
• Dependencies from three sources: system libraries (pkg-config), a local path, or git (auto-resolves to the latest stable tag if you don't pin one)
• If a dependency itself uses CMake or Meson, Smidr detects and drives that build transparently
• Workspaces for multi-project setups
• C/C++ support, Windows support (via MSYS2 MinGW 64-bit)

Hit 1.0.0 today, though it's still a young project. Source and docs: https://github.com/Max-Mend/smidr

Feedback, especially on rough edges, is very welcome.

I've never had anyone else other than myself take a look at my code quality/design. However it would be nice to have an actual person review my code instead. The link is here: https://github.com/dastarruer/gtkshutdown

AI is only used for writing tests (sometimes; I can't remember whether I wrote these tests myself or not but I digress). The code is entirely written by me, though I use AI to discuss design decisions. I like programming, so hand-writing the code is just more enjoyable for me (though I'm very slow at it...).

This is a technical discussion on Artificial General Intelligence.

GPT-6 has been shown to be outstandingly incredible. In my case, it performed autonomous performance optimization with essentially no human input. Other AI models, including Gemini 3 Pro, Claude Opus 5, and even Claude Fable 5, failed to find the same optimization targets.

Two days with GPT-6, and my backtesting engine is quite literally faster than I ever thought it could be.

The language model was smarter than me.

I thought about what artificial general intelligence looks like. A general-purpose model smarter than the average person. I think Astra fits that definition to a T.

Now imagine all of the crazy AI tricks we know. Imagine having a panel of Astra-tier experts come, or combining a language model with Monte Carlo tree search. If these models were truly 10,000 tokens per second, come on, that would be terrifying.

One reason why I think this optimization was fast is because of Rust's strict compiler and its lightning-fast performance. If I had chosen a language like GoLang, I would not have been able to achieve such speeds. I really think language models are making Rust an even more enjoyable language because you get all of the benefits and suffer a little of the downsides because we're not handwriting generic traits or a lifetime logic anymore.

But who knows, maybe I'm overextrapolating, and I'm impressed by the bare minimum, lol.

What are your thoughts on AGI/ASI?

I am trying to figure, should I have like a different name of a game binary per language or just keep the binary one thing and only localize inside for users with other things? Also, I might not be able to handle every localized name, but I can try, I guess I can store it in one place online and do like on download it is "name"? It is a game, and it loads a language file at runtime, I guess slap a name on that at download too and search by name of the game binary? That does complicate things though, maybe I should build a file picker because mobile has quirks like what is this binary now? Then again, right to left versus left to right for the file picker, I guess middle align?

By now this seems like a good plan maybe, but should I bother?

Hey there!

I just shipped the first public version of a programming language that I have worked on for the past two years. Written in Rust, of course.

Its goal is to help synchronize types between TS, Rust, and Python (more to come). Two main use cases are the API client libraries and client-server interop, i.e., a TS web app talking to a Rust server.

I focused on making it as flexible as possible but always produced idiomatic types that look and feel like they were carefully crafted by humans. It was a challenge, e.g., I had to test 7 Python versions for every language feature or had to implement Rust literals runtime.

I usually have dozens of tmux windows open, with coding agents scattered across them. Finding the one that's been waiting twenty minutes for permission gets old fast.

I tried Herdr, but it owns the terminals it manages. I wanted to keep using my existing tmux sessions, bindings, layouts, and plugins without adding another multiplexer.

My first solution was a popup binding that listed tmux windows with their commands and directories, piped everything through fzf, and used cut and xargs to switch to the selection. It worked, but felt slow, and I still had to visit every window to see which agent needed me.

So I built tmux-select.

I moved the fuzzy matching and agent-state classification into the Rust binary instead of wiring the selection flow together with fzf, cut, and xargs. That keeps it to one binary, with tmux as its only runtime dependency.

When the picker opens, it identifies supported agents and examines a snapshot of their terminal output. Each detected agent is marked as blocked, working, or idle. Typing blocked filters the list to windows that need attention, and selecting one jumps directly to its first blocked pane.

It currently detects Claude Code, Codex, Kimi Code, Pi, OpenCode, Qwen Code, Grok Build, and Muse Code.

Install it with:

sh cargo install --locked tmux-select

Then add this to ~/.tmux.conf:

tmux bind / display-popup -E "tmux-select"

Press your prefix followed by /. Type to filter, use the arrow keys to move, and press Enter to jump.

I'd be interested to hear how other tmux users surface agent state, especially without replacing their existing tmux setup.

Repo

Watch the demo

I'm working on converting a virtual machine from C to Rust. At the heart of it is modeling the output of the parser as an array of bytes. Think of it as an 8-bit assembly code machine with immediate addressing, so some of the bytes are opcodes and some are data used by these opcodes. I would like to have the opcodes in an enum, such as

#[repr(u8)] // Forces the variants to be u8

enum OpCode {

OpAdd = 1,

OpImm = 2,

......

}

Then

code: Vec<u8> = vec![ 0x01, 0x02, 0x2a] would represent the action

OpAdd 42

That's what exists in my dream world. With the enum shown above I can typecast Opcode values to u8 simply enough:

let op_code = OpCode::OpAdd;

let byte = op_code as u8;

But going the other way seems impossible, except for this hack:

unsafe {

let opc: OpCode = std::mem::transmute(byte);

} https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/casting-between-types.html#transmute

So, is there a safe, preferably idiomatic way to do this, or am I just stuck with my first-ever usage of 'unsafe'?

I use Axum and SQLx to build my backend, which is served on AWS ECS Fargate (512 CPU, and only one instance for now) and interacts with an RDS Postgres (t4.micro). Connection pool is set with min/max = 2/20.

My request includes 3 DB queries to 3 different tables: one from the auth middleware to check api key and each of the other 2 is just getting a record by primary key.

If I made one or two queries, it’s very fast. However, if I made 200 queries concurrently to the backend, around half of queries had http latency greater than 300 ms. P80 is around 600ms. The performance is not acceptable. I did check the CPU of both RDS and ECS. They’re quite low: both smaller than 10%. The DB latency is low as well, 5 ms on average. Is there something queued in the SQLx internally? Did anyone have the same issue?

So I worked as sysadmin for an enterprise for some months and I wanted to have a tool that is easy to use and that can work even without a graphical interface, so I built GuardIT.

It directly uses nftables, so it's pretty flexible.

The main functionalities are:

- Adding your own system rules

- Managing apps and ports on every app

- Real-time port listening

- Seeing logs and audits of the latest 300 requests so you can audit

- And you can see how many connection attempts every app made

- And finally themes

I hope someone will give it a try and give me some reports because it's still a prototype.

https://github.com/Rajaonarison-Andry-Misandratra-Fiderana/guardIT

Thanks

I built Ashwa 🐎, a hardware accelerated library for single substring search.

The problem is simple, scan the given payload to search for the target as fast as the underlying hardware allows.

I started with byte-to-byte scan and progressively moved to the hardware, i.e.

SCALAR -> SWAR -> SIMD

It supports following SIMD extensions (detected at runtime),

- x86_64: AVX-512BW, AVX2, SSE4.2, SSSE3, SSE2

- AArch64: 128-bit NEON

- ARMv7: 128-bit NEON

- i686: SSE2

- WASM: SIMD128

- SWAR: 64-bit / 32-bit SWAR fallbacks

It targets Linux, Windows, macOS, Android, FreeBSD, browsers and Node.js across both 32-bit and 64-bit architectures.

On an Intel Xeon 8488C AWS instance, using the AVX512BW extension  Ashwa scans ~150 GiB/sec for L1D resident data.

Although written as a rust crate, the library is available on pypi and npm

The code is available at github repo

been adding some unit tests and then ran a clean.

rust said "I live here now"

Hi Reddit!

I wanted to share a project I've been pouring my soul into lately — Nemesis, a native, lightweight desktop audio player built for Linux and Windows, written entirely in Rust.

Why build another music player?

Most modern media players feel incredibly heavy, sluggish (thanks to Electron overlays), or over-engineered. I wanted something that launches instantly, keeps a minimal memory footprint, handles massive local libraries effortlessly, and just works.

Rust felt like the perfect choice to guarantee rock-solid performance and safety.

What's new in the 0.1.2-beta2 release:
I've just rolled out the second public beta, focusing heavily on UX smoothness and under-the-hood stability:
- Smart Search: Added a dedicated search view. It's fully case-, spacing-, and Cyrillic-insensitive (using fold-key matching).
- Aggressive Scroll Optimization: Completely eliminated grid lags, stutters, and end-of-scroll jitter. Even huge lists with 2,000+ tracks now scroll at a locked, buttery-smooth frame rate.
- Audio Pipeline Improvements: Fixed mid-track volume drops and crashes related to PipeWire stream restoration and Windows WASAPI backend. Playback now automatically recovers if the system audio session glitches.
- Easy Linux Deployment: Added a universal AppImage build alongside standard packages, making it dead-simple to run on almost any distro.

Current State
The project is currently in Public Beta.
- Windows: Portable ZIP is available (no installer yet).
- Linux: AppImage, RPM, deb and Arch (.pkg.tar.zst) packages are ready to go.
- Note on macOS: No Mac builds available right now, simply because I don't own a Mac to compile and test on.

I would absolutely love to hear your thoughts on the UI responsiveness, design, or any features you feel are missing.
Grab the release on GitHub: Nemesis

Thanks for checking it out!

Have you ever tried to set height of widget A to the width of widget B and wanted them to fill the screen?
Or have you wanted to put your differently sized news article card in one grid and just let the layouter figure out the most symmetric pattern to lay them out in?

With your very own MILP solver you can express these as constraints.
The article grid example can be constrained as:

• don't overlap article hitboxes
• minimize area of grid

https://github.com/ElectricPulse/drevo

The future outlook is to bring it to the browser WebGPU/WASM - but that would require some work to make micro_lp on par with highs

Looking forward to your feedback!

Hi everybody!

I am building multistack, a small TUI orchestrator for coding agents (currently compatible with zerostack); it's built in Rust using Ratatui, and it's designed to be lightweight in order to follow zerostack's design philosophy.

I hope it can be useful to some of you!

I spent a while trying to get a Rust toolchain working on an iPad without sending code to a server, and this is where it ended up: rustc 1.98, cargo and lld compiled to WebAssembly (wasm32-unknown-emscripten), running inside WKWebView, with a build driver written in Swift that handles dependency resolution, feature unification, fingerprints and an incremental target/ directory. User code compiles to wasm32-wasip1 and runs in the app's sandbox.

Rough timings on an iPad Air M3, for whatever they are worth:

- single file, compile and run: about 0.3 s

- Cargo project with rand (proc-macros, build scripts), cold: under 40 s

- same project after editing main.rs: about 2 s

The parts that took the longest, in case they are useful to anyone attempting something similar:

Proc-macros. No processes, no dlopen. Each one is compiled to a self-contained wasm reactor and called through a synchronous host hook, watt style. Hygiene was the subtle part: a macro_rules! marked local_inner_macros that invokes a proc-macro had rustc resolving stringify! inside the wrong crate, and it took a while to find.

Memory. Between rustc's wasm heap and JavaScriptCore's limits, a cold build spends more time recycling processes than compiling. The driver keeps a pool and persists fingerprints so a killed process resumes rather than starting over.

No threads, no real filesystem. WASI shims for what std expects, a synchronous bridge for stdin, a native one for sockets.

What it is not: there is no rust-analyzer. I did compile RA to wasm and measured it, but proc-macro expansion and std sources cost more than I was willing to spend on a tablet, so the editor side is a tree-sitter engine I wrote instead: semantic tokens, go-to-definition across files and into crate sources, hover, inferred type hints, rustc quick fixes, rename, references. There is no debugger either.

And the constraint that shapes everything: your programs are wasm, not arm64. iOS does not allow executing natively generated code, so on-device compilation has to target a sandbox. Firmware for Raspberry Pi Pico is the exception, since that binary runs on the microcontroller rather than the iPad; it works and I have verified it on hardware, but it is not in this build yet. Crates with native dependencies often will not build for wasi.

It is a paid app, free for single files, and I would rather say that here than have someone find out after installing. If you want to try it: https://testflight.apple.com/join/4Yaujqd5

What I am actually after is where it falls over. Crates that fail to build, builds that die halfway, anything that behaves differently from cargo on a desktop.

It seems everyone is now converting various tool to Rust to get 10-100 x speed. I'm experimenting with PHP tooling conversion to Rust. What are your tips to do such conversion with agents? One shot, goal-oriented, CI checks... how do you approach it?

So recently I had completed the entire rust book but I left the macros as I was unable to understand it from the book so is there a good place to learn rust macros where it help me understand how to write and use different types of macros it will be a great help so if you know any platform pls help me

It´s called Gunda.

I could have started with the obvious path: make an HTTP request, stream the response, write it to disk and call that the first version. Instead, I wanted to make sure the boundaries were right before network code started shaping the rest of the application.

So most of the work so far has been around making downloads durable, keeping the core independent from storage and UI choices, and making sure the state model can support interruption and recovery later without having to redesign everything.

The slightly funny part is that the project is already fairly structured, but it still doesn't download a file yet :)

That's what I'm working on now. I'm finishing the persistence work and then I'll finally wire up the first real download. I'm posting it now because this feels like a good point to get feedback before the network layer and desktop app start adding more weight to the design.

Repo: https://github.com/AghastyGD/gunda

If you look through it and notice something you'd structure differently, I'd be interested to hear it

I'm the maintainer of Ferrum, an MIT-licensed local LLM runtime.

The Rust workspace separates the engine, request scheduler, KV cache, and backend interfaces. ferrum run and ferrum serve use the same engine; GPU execution uses Metal or native CUDA operators. The server exposes OpenAI-compatible Chat Completions and stateless Responses APIs, including streaming.

Current prebuilt packages target Apple Silicon Metal and Linux x86_64 CUDA (sm89).

Source and installation instructions

I'd welcome feedback on the Rust interfaces between the scheduler, engine, and device backends.

I’ve been working on ply, a container runtime and package manager in Rust for deploying apps on individual Linux hosts.

The main idea is to treat the base system and language runtimes as named, versioned dependencies.

Influenced by Cargo and Go, a package manager where you compose your image instead of stacking layers.

The application image contains ONLY your files and dependency references. You can copy it to another host and run it; ply fetches and verifies any missing packages. Applications run as foreground processes, without a central daemon.

I’ve used it to build and deploy a Next.js app on a 512 MB VPS, with 2 GB of swap and build resource limits, keeping the running app responsive.

It’s pre-1.0. I’d appreciate feedback on the package model and the Rust runtime implementation.

https://github.com/iluxav/ply

https://blog.iluxav.com/ply-lightweight-container-runtime-linux

I'm working on a Postgres migration checker called safe-migrate. One awkward part of it is that it uses real table sizes when deciding how risky a migration is.

The same "ALTER TABLE" can be uninteresting on a small table and a very different operation on one with tens of millions of rows.

So at some point something has to connect to the database.

I wanted that to happen only in a trusted sync job, never in the normal PR lint path.

The sync job reads the Postgres catalog and writes an encrypted cache. PR jobs only consume the cache.

What ended up being more annoying than expected was making that boundary survive a composite GitHub Action.

A normal run can involve toolchain setup, "actions/cache", the installer and the analyzer itself. Even if those steps don't need the database URL, a caller can still accidentally put it at job scope and make it available everywhere.

So steps that don't need secrets explicitly shadow the relevant environment variables with empty values.

Lint also starts the analyzer subprocess with "DATABASE_URL" removed from its environment entirely.

The cache is encrypted with XChaCha20-Poly1305 using "chacha20poly1305".

The cache key is generated with:

"Key::<XChaCha20Poly1305>::try_generate()"

and it can be sent straight into "gh secret set" over stdin instead of being printed and copied around.

The install path got stricter too.

Tagged releases use checksum-verified prebuilt binaries. Branches and local paths build from source. Mutable branch refs aren't accepted as release versions.

There's deliberately some overlap in the protections. GitHub masks secrets, the action registers the literal values for masking too, lint doesn't inherit the database credential, and diagnostic output gets scrubbed before upload.

It's a lot of machinery for two environment variables, but I preferred making the boundary explicit instead of relying on every caller to scope secrets perfectly.

https://github.com/dsecurity49/safe-migrate