Self-nomination: sighook
A pure-Rust runtime instrumentation and inline hooking crate that uses signal traps (SIGTRAP/SIGILL) instead of traditional code-cave trampolines. Supports aarch64 and x86_64 across macOS, Linux, iOS, and Android. Features include instrument with register-level callbacks, patchcode/patch_asm with x86 variable-length instruction awareness, and inline_hook with automatic far-jump fallback. CI runs end-to-end smoke tests on 4 native platforms.
Advanced SQLx companion for type-safe query repositories with automatic parameter binding, sophisticated pagination, streaming, and zero-boilerplate trait-based implementations.
I would like to nominate sharded-timing-wheel
It is a production-grade implementation of the Varghese & Lauck (1987) Hierarchical Timing Wheel in Rust. It solves the "C10M" problem for network drivers by providing O(1) timer cancellation.
Why it's cool:
It uses a custom Slab Allocator with intrusive linked lists for cache locality.
Recent benchmarks show it is 1,700x faster at cancellation than the standard BinaryHeap (29μs vs 51ms) for high-churn workloads.
It uses NonZeroU32 handles to pack the struct size down to 24 bytes.
Self nominating my crate: dw2md — command-line utility in Rust // Lib.rs
"Crawl a DeepWiki repository and compile all pages into a single, LLM-friendly markdown file"
I've been finding this really useful for getting decent architecture docs into context to use while I'm exploring a library/framework, or re-implementing ideas from one environment to another (e.g. js/python libs to rust). The text ends up human readable too, so it's nice if you'd rather just have all wiki contents locally in a text file for personal reference.
Thanks!
Welp, i admit i;m ne where and this is more than just a little bit intimidiating, but neverthelesss:
I’d like to nominate Primer: https://github.com/whsprer/primer
Primer is a compact, bit-packed, odd-only Sieve of Eratosthenes implemented in Rust, aimed at being both very fast and extremely memory efficient. It stores 1 bit per odd candidate, uses trailing_zeros-based bit scanning (compiling down to efficient CPU instructions), and Brian Kernighan-style iteration over set bits to avoid unnecessary work.
On a representative benchmark (n = 500_000, 41,538 primes), the README reports roughly 4 KB of memory and around 2 ms runtime for Primer, versus about 500 KB and 15 ms for the primes crate, and about 50 KB and 3 ms for primal. There’s also a scaling table up to 100M showing how the bit-packed approach keeps memory in the tens or hundreds of KB while staying performant.
The design goal is to make prime generation practical on constrained hardware (ESP32-class devices, small SBCs) as well as on desktops, while keeping the implementation understandable and easy to integrate. The repo includes usage examples (e.g., precomputing prime tables at boot, embedded-friendly tables, and iterator wrappers), plus notes on optimizations, testing, and edge cases in the docs.
I think it’s a nice fit for people interested in number theory, embedded Rust, or just seeing how far you can push a simple, well-known algorithm with careful data representation and bit-level tricks.
I get a 404 error -- is your repo private?
Note also that a crate by the name primer already exists, but that looks like a very old placeholder that would be against policy today, so you can probably ask to have that removed, then publish yours.
oop- embarrass... i was typod on my own git D: - i managed to mioss an 'h'...
sould work properly now.
It still 404's. Did you mean https://github.com/whisprer/primer?
Self-nominating my crate: crates.io: Rust Package Registry
This crate is the result of running into "missing" methods on iterator (such as circular_windows) especially when working with nested/2D iterators (transpose, circular_windows_2d). This simple crate lets one a) define anonymous iterators with two closures and b) compose iterator method chains into reusable and testable blocks. Presented at a local rust meetup two weeks ago.
I'd like to self-nominate my create: cachekit.
This crate contains a comprehensive collection of caching policies with a unified api, you can easily swap out different policies to cater different needs. They are highly perfmormant with benchmarks published on the projects githiub page, matching the performance of well-known crates such as moka-rs and quick-cache.
I’d like to self-nominate my crate Banish for Crate of the Week: GitHub - LoganFlaherty/banish: Banish, a declarative DSL embedded in Rust, for defining rule-based state machines..
Banish is a declarative DSL for building rule-driven state machines using a procedural macro. Unlike traditional FSM libraries, Banish re-evaluates rules within a state until no rule fires (a fixed-point execution model) before transitioning to the next state. This allows complex rule-based behavior without manually writing control loops.
I'd like to self-nominate the CLI I built in a weekend called Fuelcheck CLI: GitHub - chasebuild/fuelcheck-cli: ⛽ Lightweight command-line utility designed to monitor and manage token consumption across the modern AI ecosystem..
Lately, there’s been a significant surge in AI agent usage, so I decided to write a lightweight version of CodexBar (created by @steipete, the father of @openclaw) called Fuelcheck CLI.
In short, it works exactly like CodexBar, allowing agent users to track token consumption and real-time costs directly within the terminal.
I hope this proves useful for everyone!
Self nominating web-rpc for which I have just released version 0.0.4!
Define your RPC interface as a Rust trait, and web-rpc generates type-safe clients, services, and serialization - so you get compile-time guarantees across web workers, iframes, and message channels with zero boilerplate. It supports bidirectional communication over a single channel, with async methods, fire-and-forget notifications, streaming RPCs, and direct postMessage transfer of JavaScript objects like OffscreenCanvas. Stop hand-rolling post message handlers and parsing untyped payloads - just write a trait and let web-rpc do the rest!
Self-nominating msgpacker for general purpose serialization/deserialization using MessagePack protocol.
Foo::pack and Foo::unpack via derive)msgpacker::serde::{to_vec, from_slice}MessagePack, as a tag-based binary encoding, produces much smaller network messages when compared to JSON and other formats (4x smaller), reducing communication overhead. It rivals other size-efficient protocols such as protobuf, with the major advantage that no schema is required. In short: improve your overall performance by reducing the network overhead.
Can you please give an overview of the differences with rmp_serde and maybe in what cases you think msgpacker should be prefered ?
Serde uses a visitor pattern that by itself incurs overhead. By using msgpacker natively, we can see a 100x performance boost just by this choice of not using serde. However, if we still need serde (compatibility + performance is not that important?), we can activate the serde feature and still get a ~25-50% performance boost.
MessagePack is a protocol that allows for non-heterogeneous collections. This is not compatible with Rust, and rmp-serde will solve that issue by annotating the structs (i.e. mark a structure to be serialized as serde_bytes). I created msgpacker entirely under the philosophy that you should require changes on your code as little as possible, so if you just derive the macro, all the magic is going to happen for you under the hood.
The main advantage of using rmp-serde is that it is more community tested (77m downloads of rmp-serde vs 66k msgpacker). However, I already used msgpacker in many of my applications, and never had an issue.
because serde (I'm the author of a deserialization crate). We all know that serde brought us a wonderful, innovative, and very flawed solution. But this is out of scope here...
Self nominating gitv, a terminal-based viewer for github issues! Features:
I'd like to nominate anodized which is a fairly new crate that provides a standardized (and ergonomic) way to enforce specs in Rust code.
My suggestion is complex-bessel, a pure Rust implementation of Amos (TOMS 644) algorithm for computing Bessel, Hankel, and Airy functions of complex argument. No Fortran/C FFI dependencies — works on any target Rust supports.