Brenner Cruvinel - benchmark

Validating on disk the benchmark I wrote in the middle of the night

2026-09-12T00:00:00+00:00

I opened a new session, with no context at all, and asked as if I were someone who had just cloned the repo: how do you use Nest, does it have an interface? The first command the answer suggested returned command not found on my own machine. The second one showed a default model I was sure I had swapped out weeks earlier. Two holes no test catches, found in five minutes, and that's when I realized the topic of the week wasn't compression.

The benchmark was just the place where it became visible. So, before publishing any number from the series, I spent a whole day validating: every number against the file on disk.

What was wrong

The first thing that didn't match wasn't even a number. I ran strings on the release file and out came "Spellbook MTG corpus". The file is called mtgdataset. The rename from a week earlier, which swapped Felipe's app name for the generic name in every text file, never made it into the binary. The lock next to the release described a file with the new name while the file had the old name inside, and no tool flagged it, because validation checks the file against itself. I rebuilt both releases with the right name inside, and the media bytes came out identical, which at least proved the encode is reproducible.

The sizes of the three most aggressive builds were in mebibytes labeled as gigabytes. du talks in MiB and I pasted it as GB. The difference is five percent per row, but the ratio inherits the error: the search build I had announced as 7.8 times smaller than the source is 7.5. The AVIF I said was 20% smaller than the recommended build is 13%. No conclusion changes, and it still made me ashamed, because it's the kind of mistake I'd point out in someone else's report.

The strangest one was the manifest of the AVIF build, which records a 21 GB source. The source is 4. I couldn't make sense of it until I divided by the number of cards: it gives the size of an uncompressed image, which is what the encoder receives midway through. The backend counted the intermediate instead of the JPEG. One line to fix, one test to write, and until then the ratio in that manifest was made up.

And there's what can no longer be verified. I deleted the first full build when the disk filled up, so the sentence "the three builds share the same hash" is now two-thirds checkable. The CapCut experiment and the reprint matrix left no artifacts, only text. I told it to delete them myself, to free up space. Disk space is cheaper than trust and I should have known that.

The other times I read the summary and not the file

The 200-card summary. I asked for the whole dataset, got a summary that talked about the corpus as if it were the corpus, and it was a pilot. I noticed with a meeting already scheduled. The agent didn't lie, it summarized the scope without saying so, and I read the summary instead of the disk. Since then every build delivery comes with validation of the real file, and this post exists for the same reason.

My machine's paths. Days after the benchmark I found my home directory path in dozens of files headed for GitHub, inside manifests, locks, specs. The fix was an environment variable and a script that rewrites the sidecars before committing. And before that the agent had wanted to store my preferences in a local memory file. I asked it to delete it. If the workflow depends on what it remembers about my machine, it won't run in the next repo, and it won't run on the machine of whoever clones it.

The five-gig repo. At some point I asked how ML engineers deal with this, because GitHub won't take it. The answer I adopted: not a single image byte goes into git. Each sample is a list of ids with the rule that generated it, and whoever has the SQLite database rebuilds the exact sample. The .nest files go to Hugging Face with a hash alongside, and the repo keeps the lock, the clean manifest and the hash. The whole report is generated from each experiment's JSON, and a CI check fails if the markdown differs from the JSON. I can no longer paste a wrong number into a report without CI complaining, which is the kind of protection I needed against myself.

The commits. The agent prefers one fat commit at the end of the day. I asked for sixteen, separate, with descriptions, because the history has to be readable for whoever comes later. And the plans: I rejected three in a row because they treated the model comparison as a footnote to a build already decided. The model list that exists in Nest today only exists because I insisted that research becomes a feature, never a footnote.

What these episodes have in common is just one thing: in all of them I accepted a layer between me and the file. Summary, manifest, memory, fat commit. And the layer was wrong and didn't say so.

What I'll try next time

Something that put me more at ease, in the middle of the validation, was finding out that the two findings I liked most already had names. The redundancy between images in a collection, which inter exploits, has been called set redundancy since Kosmas Karadimitriou's 1996 doctoral thesis, and the trick of lining images up as a pseudo-video has a decade of literature behind it. And the distinction between visual quality, vector stability and search usefulness, which I thought I had invented, is everyday business in the field the standards call coding for machines: it evaluates with task metrics, like mAP, precisely because feature fidelity and task performance can drift apart. I didn't discover anything. I confirmed two things on a corpus nobody had looked at, and that makes me calmer about publishing than if it were something new.

The 1.3 GB file is already in the pasta.cards repo, waiting for the screen that will use it. What's left of the benchmark fits in a paragraph: measure search with WeMM, build the full reprint corpus, decide whether AVIF becomes the default. None of the three has a date.

What I'll try is the cheapest thing of all: open a clean session as a user before every release and type the first command in the readme. Five minutes, and it found two holes a week of agents didn't. I don't know if I'll remember to do it. But now it's written down, and I trust what's written more than what I remember.

Raising the CRF until search breaks

2026-09-05T00:00:00+00:00

The question from the previous night was simple to ask and I took my time asking it. The app keeps every card's JPEG cached for display. The .nest doesn't need to be pretty, it needs to answer which card it is. So the CRF, the codec's quality setting, can go up until the vector breaks, and the vector breaks well after the eye does. If that were true, it would even be worth thinking about two tiers: a thumbnail inside Nest for search, and the full card on demand when the app needs to show it.

I had a way to measure this, or thought I did. Nest's quality gate has two sides: a visual metric, which compares the decoded frame with the source, and vector drift, which measures how much the CLIP vector moves between the original image and the decoded one. The idea behind drift is that an image can look fine and still have moved in search space. I trusted that metric. It was mine, I had insisted on it in the plan, and for good reason: on dermoscopy it had caught a case where the image passed by eye and search by clinical text dropped by half.

The gate rejected the whole ladder

I took the visual side out of the gate and left only drift, with the floor Nest has used since dermoscopy. I had the CRF climb a ladder from 40 to 60. The gate rejected the whole ladder, including the first rung, and fell back to the most conservative one because it had nowhere else to go. Drift was already below the floor at CRF 40 and only got worse. And the visual metric, which I had taken out of the gate but kept computing, told the same story from another angle: from CRF fifty on it gave negative values on some cards, something I didn't even know it could do.

The file the gate delivered, at CRF 40, the lowest on the ladder, came out close to one gig, four times smaller than the source. It was already smaller than the recommended build, and the gate had rejected it too, it just had nowhere lower to fall.

By the gate's logic, none of these files was usable. I built one at CRF fifty anyway, no gate, just to see the size. Half a gig. Seven and a half times smaller than the source, and the cards turned into a blur, rules text unreadable, the art recognizable only from a distance. A file I wouldn't show anyone.

Then I ran the metric that actually matters, which I hadn't run before because I was too lazy to set it up: search by name. A hundred queries like "the art of such-and-such card", on the five files I had of the full corpus, from the 3.6 GB lossless one down to the half-gig blur. The first round gave zero hits on two of the five files, the lossless and the recommended one, and for a minute I thought I had broken search. It was the bench: it matched results by the card's position in the stream, and the two files with similarity sorting have a different order. Nest has a content id per item for exactly this, and once the bench matched on that, all five files answered again.

And accuracy stayed within the noise on all of them. The half-gig file finds the right card as well as the 1.3 GB one, and both stay within the noise of the lossless file.

Search survives far more compression than the eye

I stared at that on screen for a while. Cosine drift measures whether the vector moved. Search measures whether the vector still finds. I was using the first as if it were the second, and it would have vetoed a file that works. The vector does move, and it still stays closer to the right card than to any other. How far it travels doesn't matter if its neighbors don't change. A gate that's any good for this use needs hit@k as its floor, the fraction of queries where the right card shows up in the top k results, not cosine.

That became a profile in Nest, retrieval-only, which writes into the manifest that the file serves search and never display. And AVIF, which in the benchmark had come out about 12% smaller than AV1 at the same quality, held up on the full corpus: 13% smaller than the recommended build. It's the candidate to become the default backend for stills, and I haven't decided yet, because AVIF takes four to ten times longer to build and embed.

There's a third metric I ran alongside that's worth nothing, and it's worth saying why. Identity: give the image itself as the query and see if it finds itself. It gave a hundred percent on every file, even the blur. Looks great and says nothing, because the query is the very image that produced the frame, and the uncompressed control also gives a hundred. It only proves the codec didn't destroy the data. I left it in the bench so nobody confuses pipeline stability with usefulness, which is exactly the confusion I made with drift.

The metric is weak and I know it. It's a hundred queries with a model that does poorly on this corpus, CLIP, which only looks at the art. "Didn't drop" means "I couldn't measure a drop", not "it's the same". And WeMM, which reads the name printed on the card and gets nine in ten right, might suffer far more from the blur than CLIP, because what it reads is exactly what the CRF destroys first. I didn't measure it. That's next, along with the full reprint corpus, which is where inter has something to predict.

What stuck with me that week was less about compression and more about what I choose to measure. I had a metric I designed myself, one that looked rigorous, and it answered a question I wasn't asking. And before publishing any of these numbers, I wanted to validate each one against the disk, because a report written in the middle of the night gets things wrong.

At the end of the day it's the same thing, 1.3 GB

2026-09-03T00:00:00+00:00

I was sure. Sorting the cards by similarity before encoding would multiply the compression, because similar neighboring frames are exactly what video codecs love. I had written it in the bets, I had repeated it to the agent, and the benchmark had handed me back a strange row: the variant with inter came out bigger than the one without. The configuration was wrong, scene cut detection was on, and different card after different card is one scene cut per frame. The encoder was burning cycles looking for a scene that didn't exist. I turned it off and put together a second corpus, almost three thousand real reprints of the same art, grouped together.

That did it. With prediction in groups of sixteen frames, the file came out 29% smaller than without prediction. Groups of sixteen beat a single keyframe for the whole stream, which surprised me, and they still keep any card reachable by decoding at most sixteen frames. And a detail I didn't expect: shuffling the reprints instead of grouping them cost only two points. Part of the gain comes from the frame every card shares, not from the repeated art. The codec was exploiting the chrome, as I had suspected on day one, and that held for any order.

Building the whole corpus at night

With 29% in hand, I built the full corpus with similarity sorting and prediction on, and next to it the same corpus with none of that, to compare. And I built it with the media inside the file, because by then I no longer accepted MP4s sitting next to the database. Before getting there I opened the folder of an intermediate build and found .build, .cache, .forge-state, .tmp, a lock, a manifest, all next to a .nest of a few megabytes. What is all this for? I asked, and the honest answer was that every piece had a reason and none of them needed to be there once the build finished. Media inside the file was half the answer, the other half was cleaning up the output.

A .nest is a container of sections, each with its own hash. The new section is the simplest of all: a table of offsets and the raw bytes of the videos, glued one after another. An MP4 stays an MP4, nothing is re-encoded to fit. Opening the file doesn't touch the media, the system only maps the slice when someone asks for a card, and you can export the original MP4 back out with the hash checked before writing.

That section doesn't count toward Nest's content hash, and this matters more than it seems. The content hash is computed over what's inside the file, not over the packaging, and it's what makes a Nest citation point to a piece of knowledge instead of a place on disk. The same corpus built with the media inside and with the media outside gives the same hash. It cost three percent: the indexes, the card text and the vectors add up to about forty megabytes on top of 1.3 GB of video.

The builds ran overnight, and the night was rough. Two died with a full disk, because macOS was taking system snapshots in waves, eating and releasing gigabytes without warning, and at one point I was down to a hundred and thirty megabytes free. And in the middle of that I read a summary from the agent saying the corpus had 200 cards. I had a client meeting in a few hours.

"Seriously, you used 200 demo cards? I have a client meeting and I still don't have the dataset." I had it run validation on the 1.3 GB file. All 38 thousand blobs checked out, one by one. The corpus was complete, the summary was describing the pilot, and I had read the summary instead of the disk. After the encoder that wasn't using the tune the manifest claimed, it was the second time that week that what I read wasn't what was actually there.

At the end of the day

The sorted build sat next to the plain build. 1.3 GB both, no difference at all. I sent it to the agent at four in the morning: at the end of the day it's the same thing, right, 1.3 GB.

The reason was in the manifest, correct this time. Nest decides per segment whether to use prediction, encoding a sample both ways. On the real corpus, made of unique cards, the probe vetoed prediction in every segment. There's nothing to predict: the next card is another card, with other art, and the shared chrome doesn't pay for the cost. The 29% gain only exists on the reprint corpus, and I haven't built that one in full yet.

There was a worse part, which I only understood later. In an earlier version of the probe, it decided on bytes alone, and in a build of the sample it picked prediction for every segment because it tied on size. Median quality dropped sixteen points. The encoder compresses predicted frames with coarser quantization, and with unique cards a predicted frame is just a worse keyframe in disguise. Equal bytes aren't equal quality. The probe now measures both sides, accepts losing at most two points, and records the reason when it vetoes. The 29% matrix also compares bytes only, so the number is real but it isn't equivalent quality. I'm putting that down here because I forgot it myself for a whole day.

What if the file doesn't need to be pretty

What I take from that night isn't the 1.3 GB. It's that my intuition about codecs was wrong twice, and that I read summaries when I should read files. Now I only turn sorting on when the corpus has near-duplicates, and no build goes in without validation of the real file running alongside it.

And one question was left over that seemed more promising than any sorting. Nest's quality gate locks the codec at a conservative level because the visual metrics never pass on small cards with tiny print. But Felipe's app keeps every card's JPEG cached for display. The .nest only needs to answer which card it is. If the file doesn't need to be pretty, how far can you push the setting before search starts complaining?

The encoder had ignored tune=still since the first build

2026-09-02T00:00:00+00:00

The symptom was a number that didn't add up. I had a battery of encoders running in parallel: nineteen configurations across AV1, AVIF, x264, x265, WebP and lossy JPEG XL. Even VVC got in, more out of curiosity than hope. Each one calibrated to the same visual quality, to find out whether Nest's AV1 was the most compact option or just the one closest to home. One of the agents reproduced the Nest build by hand, with the same parameters, and the file came out a different size. Same card, same CRF, same preset, different bytes. I read that in the morning and my first reaction was that the agent had gotten the command wrong.

The probe failed and nobody said a word

It hadn't. The forge asks the encoder for tune=still, the still-picture mode, which is the right one for a stream where every frame is an independent photo. Before asking, it runs a probe to check whether the encoder accepts that mode. The probe ran without a parameter the mode requires, failed, and the code fell back to a generic mode without telling anyone. The manifest recorded the spec, which said "still", not what the encoder had actually done. Since the first build I had been reading a manifest that didn't match the binary, and the only place that recorded the mode was the wrong place.

The difference measured eleven points of visual quality for ten percent more bytes, at the same CRF. The old build was the worst point on the curve: smaller, but ugly in a way that isn't worth it. And nobody would have caught it by watching the video, because what a frame looks like in the player doesn't tell you which tune was used. Only bytes against the bytes of an independent encode.

And it was by chance. The encoder battery existed to answer a different question, and the manual baseline encode was just its reference point. If I had calibrated the battery against the manifest instead of against an encode done from scratch, the bug would have stayed invisible, and every number in the series would have come out ten percent optimistic on bytes and eleven points pessimistic on quality. Now the manifest records the mode the encoder actually used, and the probe passes the right parameter.

Even after the fix there was a second layer. SVT-AV1 has two modes you could call "still": tune=2, optimized for a structural similarity metric, which is what the fixed probe started picking, and tune=3, called image quality, which the documentation itself marks as still images only. The second one gives one more point of quality for one percent more bytes. Not much, but it's the right mode for still pictures, and the recommended build of the full corpus went out with it. The manifest now says which of the two, by number, because "still" on its own already fooled me once.

Variant on the same 2,048 cards	Size	Visual quality
JPEG XL repack, lossless	1.12x smaller	same as source
AV1 from the first build	3.3x smaller	52
AV1 with tune=still	3.0x smaller	63
AV1 with inter	2.5x smaller	62
AVIF	5.5x smaller	43

The AVIF row looks like the winner and it isn't. It sits at a much lower point on the quality curve, so you can't compare it on the same number. Calibrated to the same quality as AV1, it comes out about 12% smaller, and that left an open question about which backend to use for stills. And inter, my favorite bet, came out bigger than tune=still. I explain that in the next post, because the configuration was wrong and the problem was something else.

I won't table the rest of the nineteen, but three findings stayed with me. x264, the encoder for a 2003 standard, was the fastest inside the quality window by an enormous margin, and VVC, the newest codec on the list, cost a hundred times x264's time to land in the middle of the table.

Two different SVT-AV1 presets spat out byte-for-byte identical streams, because the version I use maps both to the same internal mode when the stream is all keyframes. One more case of a parameter I was passing and the encoder was ignoring, this time documented. And lossy JPEG XL, which I expected to compete, only competes at high quality, well above the window that matters for a deck tile. It's a good codec for a target this corpus doesn't ask for.

CapCut was throwing cards away

I had written in the bets that speeding up the video cut bytes, because I had done it in CapCut and the file came out half the size. I reproduced it programmatically: speed it up sixty times, export at thirty frames per second in H.264, the way the editor does. The file came out with half the bytes. And half the cards.

The export samples the sped-up timeline and drops whatever falls between one frame and the next. Of the 2,048 cards, 993 disappeared. What was left got re-encoded to H.264 on top of AV1 that was already lossy. CapCut didn't compress anything, it threw half the dataset away and called it optimization, and I looked at the file size and believed it. Changing only the fps, without speeding up, doesn't change a single byte. It's a timestamp annotation in the container, as ffprobe had already told me on day one and I hadn't properly written down.

The wrong bet yielded a real bug. With an fps other than one in the manifest, the code that fetches a frame by index asked for an instant that didn't exist, because it assumed ordinal and timestamp were the same thing. Fixed, and tested with the fps I never should have changed. The real gain CapCut was pointing at, redundancy between neighboring frames, does exist. It just has to be measured with inter, without losing cards, and that's the subject of the next late night.

What else is the manifest getting wrong

I closed the day with two things validated by hash and a bigger doubt than when I started. The encoder mode was a constant I thought was on, and it had been off since the beginning. CapCut was a number I thought was compression, and it was data loss. Both lived in a manifest or an export I had read and accepted without checking against anything.

If the encoder wasn't doing what the manifest said, the question left over was what else I was reading as a summary instead of validating on disk. I didn't know yet that the answer would come in the middle of the night, with a meeting on the calendar.

The open source Rust ecosystem: what runs in production

2025-06-30T00:00:00+00:00

I put this survey together with the research templates for agents, to decide what to bet on in my Rust projects. The first version had a good rule, "a benchmark number only goes in with a source", that it did not follow itself: several sources were just a site's home page, with no article, and the stars came rounded from third-party rankings.

All stars below were read from the GitHub API on 13 October 2026.

The core, by stars

Repositories with more than 20 thousand stars where Rust is the main language, according to GitHub. Where a description carries a performance number, it is what the project itself claims in its README.

Repository	Stars	What it is
openai/codex	129,042	OpenAI's coding agent that runs in the terminal
rustdesk/rustdesk	125,720	Self-hosted remote desktop, client and server
rust-lang/rust	119,904	The language's compiler and standard library
tauri-apps/tauri	111,870	Desktop apps with a web front end and a Rust back end, smaller binaries than Electron
denoland/deno	108,774	JavaScript and TypeScript runtime, secure by default, with explicit permissions
oven-sh/bun	96,222	JavaScript runtime, bundler and test runner in one binary
zed-industries/zed	91,688	Native editor with collaborative editing
astral-sh/uv	90,720	Python package and project manager; the README says 10 to 100 times faster than pip
BurntSushi/ripgrep	69,112	Recursive regex search that respects .gitignore
dani-garcia/vaultwarden	68,985	Lightweight Bitwarden-compatible server, popular for self-hosting
alacritty/alacritty	65,955	OpenGL-accelerated terminal
warpdotdev/warp	65,452	Terminal with built-in AI
rust-lang/rustlings	64,339	Short exercises to learn Rust
tw93/Pake	62,056	Turns a web page into a desktop app with one command
FuelLabs/sway	61,391	Smart contract language for the Fuel network
sharkdp/bat	60,789	cat with syntax highlighting and git integration
starship/starship	60,251	One shell prompt for bash, zsh, fish and others
meilisearch/meilisearch	59,558	HTTP search engine with relevance out of the box
typst/typst	56,601	Markup-based typesetting, a modern alternative to LaTeX
aaif-goose/goose	55,248	Extensible AI agent for software development
astral-sh/ruff	50,053	Python linter and formatter; the README says 10 to 100 times faster than Flake8 and Black
bevyengine/bevy	48,973	Data-driven game engine with ECS
helix-editor/helix	46,576	Modal terminal editor with built-in LSP and tree-sitter
juspay/hyperswitch	45,313	Payments platform with routing across processors
sharkdp/fd	44,781	A simple, fast alternative to find
sxyazi/yazi	42,808	Terminal file manager with async I/O
GyulyVGC/sniffnet	41,503	Network traffic monitor with a graphical interface
nushell/nushell	40,657	Shell with structured data pipelines
pola-rs/polars	40,120	Columnar DataFrames with Python bindings
ajeetdsouza/zoxide	40,087	A cd that learns your most-used directories
DioxusLabs/dioxus	39,383	App framework for web, desktop and mobile, with a React-like API
spacedriveapp/spacedrive	39,158	Cross-platform file explorer
lapce/lapce	38,917	Lightweight native editor with remote mode
servo/servo	38,145	Embeddable browser engine, born at Mozilla
firecracker-microvm/firecracker	37,349	AWS microVMs; the README says it runs Lambda and Fargate
pnpm/pnpm	36,803	JavaScript package manager with shared storage
casey/just	36,256	Task runner with simple syntax, in the spirit of make
zellij-org/zellij	35,723	Terminal multiplexer with WebAssembly plugins
qdrant/qdrant	35,065	Vector database with HNSW, filters and replication, common in RAG
jdx/mise	34,971	Tool version, environment variable and task manager
rustfs/rustfs	34,870	S3-compatible object storage
fish-shell/fish-shell	34,296	Interactive shell, rewritten in Rust from version 4
swc-project/swc	34,204	JavaScript and TypeScript compiler and bundler
TabbyML/tabby	33,911	Self-hosted coding assistant
tokio-rs/tokio	33,440	Async runtime underlying most Rust servers
surrealdb/surrealdb	33,128	Multi-model database, document and graph, with real-time queries
yewstack/yew	32,821	WebAssembly front-end framework inspired by React and Elm
dandavison/delta	32,487	Syntax-highlighting pager for git diff
jj-vcs/jj	32,023	Git-compatible version control with a simpler model
ankitects/anki	31,988	Spaced-repetition flashcards, core in Rust
atuinsh/atuin	31,986	Shell history with search and encrypted sync
influxdata/influxdb	31,763	Time-series database; version 3 is in Rust
iced-rs/iced	31,755	Cross-platform GUI library inspired by Elm
emilk/egui	31,400	Immediate-mode GUI, native and on the web
vercel/turborepo	31,198	Incremental build for many packages in one repository, moved from Go to Rust
nautechsystems/nautilus_trader	29,938	Event-driven trading platform, backtest and production in the same code
chroma-core/chroma	29,495	Vector database for LLM applications
wezterm/wezterm	29,220	GPU-accelerated terminal with a multiplexer
sharkdp/hyperfine	29,084	Command-line benchmarking tool with statistics
niri-wm/niri	28,390	Wayland compositor with scrollable tiling
cloudflare/pingora	27,614	Cloudflare's HTTP proxy framework, open-sourced in February 2024
GraphiteEditor/Graphite	27,572	2D graphics editor with a node-based procedural engine
tokio-rs/axum	27,465	Web framework on tokio and tower
tree-sitter/tree-sitter	27,177	Incremental parser generator used in editors
Schniz/fnm	27,093	Node version manager
Wilfred/difftastic	26,007	Structural diff that understands language syntax
biomejs/biome	25,945	Formatter and linter for web projects
rwf2/Rocket	25,780	Web framework focused on type safety and ergonomics
clockworklabs/SpacetimeDB	25,288	Database with built-in server logic, for real-time apps
actix/actix-web	24,858	Performance-focused web framework
ogham/exa	24,450	ls replacement, unmaintained; the README points to the eza fork
uutils/coreutils	24,233	Cross-platform rewrite of GNU coreutils
slint-ui/slint	24,168	Declarative GUI toolkit for Rust, C++, JavaScript and Python
eza-community/eza	23,548	Maintained fork of exa

By domain

Command-line tools

The ripgrep, fd, bat, delta and just tools are already in the core. Below them:

Repository	Stars	What it is
rust-lang/mdBook	22,213	Books in Markdown, used for the official Rust book
getzola/zola	17,511	Static site generator, the one behind this blog
XAMPPRocky/tokei	14,994	Counts lines of code by language
ClementTsang/bottom	14,101	Terminal system monitor
bootandy/dust	12,497	Disk usage, in the spirit of du
imsnif/bandwhich	12,001	Bandwidth use per process
sharkdp/hexyl	10,291	Hex viewer
pemistahl/grex	8,219	Generates regex from examples
svenstaro/miniserve	7,898	HTTP file server
tealdeer-rs/tealdeer	6,590	tldr client
sharkdp/pastel	6,516	Color manipulation in the terminal
dalance/procs	6,193	Modern ps replacement
ouch-org/ouch	3,786	Compresses and decompresses many formats
cgag/loc	2,456	Lines-of-code counter

Git, build and binary size

Repository	Stars	What it is
gitbutlerapp/gitbutler	21,806	Visual Git client
rui314/mold	17,633	Fast linker, works with Rust
GitoxideLabs/gitoxide	12,012	Pure Rust implementation of Git
johnthagen/min-sized-rust	9,857	Techniques to shrink Rust binaries
mozilla/sccache	7,778	Distributed compilation cache
flamegraph-rs/flamegraph	6,047	Generates flamegraphs from perf and dtrace
RazrFalcon/cargo-bloat	2,774	Shows what takes up space in an executable
rust-lang/git2-rs	2,114	libgit2 bindings
AlexEne/twiggy	1,427	Shows what takes up space in a .wasm binary
matklad/cargo-xtask	1,338	Build automation pattern with cargo
nnethercote/dhat-rs	1,010	Heap profiling

Runtimes and platforms

Deno, Bun, Tauri, pnpm and tokio are in the core. The smaller async runtimes and the WebAssembly platforms:

Repository	Stars	What it is
vercel/turborepo	31,198	Incremental build for many packages in one repository
shuttle-hq/shuttle	6,916	Deployment platform for Rust
spinframework/spin	6,525	Serverless microservices in WebAssembly
extism/extism	5,794	WebAssembly plugin system
monoio-rs/monoio	5,126	Thread-per-core async runtime on io_uring, from ByteDance
smol-rs/smol	5,082	Small async runtime
async-rs/async-std	4,062	Async runtime with a std-like API
DataDog/glommio	3,663	Thread-per-core runtime on io_uring
compio-rs/compio	1,916	Completion-based I/O runtime

Infrastructure, databases and search

Meilisearch, Qdrant, InfluxDB, SurrealDB, Polars and SpacetimeDB are in the core.

Repository	Stars	What it is
neondatabase/neon	23,197	Serverless Postgres with storage separated from compute
vectordotdev/vector	22,697	Logs and metrics pipeline, maintained by Datadog
valeriansaliou/sonic	21,358	Lightweight search back end
tikv/tikv	16,908	Distributed key-value store, the base of TiDB
quickwit-oss/tantivy	16,211	Full-text search library inspired by Lucene
microsoft/windows-rs	12,817	Bindings for the Windows APIs
quickwit-oss/quickwit	11,713	Cloud-native search and observability
bottlerocket-os/bottlerocket	9,678	Operating system for containers, from AWS
databendlabs/databend	9,466	Cloud data warehouse
apache/datafusion	9,444	Analytical SQL query engine
risingwavelabs/risingwave	9,369	Streaming database with SQL
spacejam/sled	9,095	Embedded database
youki-dev/youki	7,629	OCI container runtime
GreptimeTeam/greptimedb	6,734	Cloud-native time-series database
MaterializeInc/materialize	6,382	SQL over data streams
apache/opendal	5,412	Unified access to storage services
fluvio-community/fluvio	5,256	Streaming platform
cberner/redb	4,847	Embedded key-value database in pure Rust
kube-rs/kube	3,844	Kubernetes client
apache/arrow-rs	3,641	Official Apache Arrow implementation in Rust
delta-io/delta-rs	3,341	Native Delta Lake
eclipse-zenoh/zenoh	3,256	Pub/sub and query for IoT and robotics
fjall-rs/fjall	2,377	Embedded LSM tree
apache/datafusion-ballista	2,146	Distributed DataFusion
databendlabs/openraft	2,089	Raft implementation
lnx-search/lnx	1,456	Search server built on tantivy
GlareDB/glaredb	1,024	Analytical SQL over many sources
meilisearch/heed	921	Typed LMDB wrapper

Web and APIs

Axum, Actix Web and Rocket are in the core.

Repository	Stars	What it is
leptos-rs/leptos	21,388	Full-stack framework with fine-grained reactivity
transact-rs/sqlx	17,563	Async SQL with compile-time checked queries
diesel-rs/diesel	14,202	ORM and query builder
grpc/grpc-rust	12,491	gRPC implementation
seanmonstar/warp	10,378	Web framework built from filters
SeaQL/sea-orm	9,924	Async ORM
loco-rs/loco	9,439	Rails-style framework
poem-web/poem	4,448	Web framework with OpenAPI generation
salvo-rs/salvo	4,447	Web framework
tower-rs/tower	4,320	Middleware and service abstractions
ntex-rs/ntex	2,541	Network and web framework

Security and cryptography

Vaultwarden is in the core.

Repository	Stars	What it is
firezone/firezone	9,113	Zero-trust access over WireGuard; the repository's main language is Elixir
rustls/rustls	7,672	TLS in pure Rust
mullvad/mullvadvpn-app	7,665	Mullvad VPN app, daemon in Rust
cloudflare/boringtun	7,218	Userspace WireGuard
briansmith/ring	4,107	Cryptographic primitives focused on TLS
str4d/rage	3,682	File encryption in the age format
EmbarkStudios/cargo-deny	2,452	Checks licenses, advisories and dependencies
Keats/jsonwebtoken	2,100	JWT
rustsec/rustsec	1,966	Security advisory database for crates
ramosbugs/oauth2-rs	1,211	OAuth2 client
RustCrypto/password-hashes	914	Argon2, bcrypt, scrypt and the like
rust-bitcoin/rust-secp256k1	430	libsecp256k1 bindings

AI, ML and LLM infrastructure

Qdrant, Chroma, Polars and Tabby are in the core.

Repository	Stars	What it is
huggingface/candle	21,168	Minimalist ML framework
tracel-ai/burn	16,107	Deep learning portable across back ends
lancedb/lancedb	11,665	Serverless vector database on the Lance format
huggingface/tokenizers	11,168	Fast tokenizers
0xPlaygrounds/rig	8,870	Framework for LLM agents
EricLBuehler/mistral.rs	7,743	LLM inference with quantization
rustformers/llm	6,153	LLM inference
LaurentMazare/tch-rs	5,503	libtorch bindings
Rust-GPU/rust-cuda	5,407	Rust compiled for NVIDIA GPUs
rust-ml/linfa	4,759	Classic ML algorithms, in the spirit of scikit-learn
safetensors/safetensors	3,917	Safe tensor format
sonos/tract	3,087	ONNX and TensorFlow inference
pykeio/ort	2,559	ONNX Runtime bindings
64bit/async-openai	2,017	Async client for the OpenAI API
sobelio/llm-chain	1,603	Chaining LLM calls
chelsea0x3b/cudarc	1,231	CUDA bindings
srush/llama2.rs	1,063	Llama 2 in Rust, for teaching
pepperoni21/ollama-rs	1,061	Ollama client
smartcorelib/smartcore	964	ML library
utilityai/llama-cpp-rs	657	llama.cpp bindings

Embedded and low-level systems

Repository	Stars	What it is
redox-os/redox	16,620	Unix-like operating system written in Rust
embassy-rs/embassy	9,957	Async embedded
tock/tock	6,464	Secure operating system for microcontrollers
oxidecomputer/hubris	3,631	Oxide's embedded operating system
theseus-os/Theseus	3,212	Research operating system that uses Rust's type system
nix-rust/nix	3,079	POSIX bindings
probe-rs/probe-rs	2,975	Debugging and flashing microcontrollers
rust-lang/libc	2,628	libc bindings
rtic-rs/rtic	2,420	Real-time concurrency for microcontrollers
seL4/rust-sel4	216	Rust support for the verified seL4 microkernel

Outside GitHub, Ferrocene is a Rust compiler qualified for safety-critical software, such as automotive.

Graphics, GUI, games and audio

Bevy, egui, iced and Slint are in the core. The physics in rapier is the same idea of simulation that shows up, at another scale, in the Z machine.

Repository	Stars	What it is
ratatui/ratatui	22,965	Text user interfaces in the terminal
gfx-rs/wgpu	18,278	Cross-platform WebGPU, native and on the web
linebender/druid	9,702	UI toolkit, predecessor of xilem
veloren/veloren	7,621	Open-world voxel RPG
makepad/makepad	7,170	UI framework and creative environment
rust-windowing/winit	6,204	Cross-platform window creation
fschutt/azul	6,129	GUI on WebRender
dimforge/rapier	5,853	2D and 3D physics, with JavaScript and WebAssembly bindings
linebender/xilem	5,570	Experimental UI framework
dimforge/nalgebra	4,801	Linear algebra
ggez/ggez	4,703	2D game framework
not-fl3/macroquad	4,662	Simple 2D games, including on the web
linebender/vello	4,417	2D renderer on the GPU
lapce/floem	4,296	GUI with fine-grained reactivity
crossterm-rs/crossterm	4,242	Cross-platform terminal manipulation
RustAudio/cpal	3,966	Audio input and output
pdeljanov/Symphonia	3,434	Pure Rust audio decoder
imgui-rs/imgui-rs	3,058	Dear ImGui bindings
Rust-SDL2/rust-sdl2	2,952	SDL2 bindings
RustAudio/rodio	2,488	Audio playback
bitshifter/glam-rs	2,077	SIMD vector math for games and graphics
gfx-rs/naga	1,565	Shader translator, now inside the wgpu repository
tesselode/kira	1,071	Audio for games
dimforge/parry	880	Collision detection

Blockchain and zero-knowledge proofs

Sway is in the core.

Repository	Stars	What it is
solana-labs/solana	14,950	Solana blockchain; the old repository was archived
paritytech/substrate	8,386	Polkadot's blockchain framework; archived
paradigmxyz/reth	5,825	Ethereum execution client
sigp/lighthouse	3,484	Ethereum consensus client
rust-bitcoin/rust-bitcoin	2,684	Bitcoin types and serialization
near/nearcore	2,620	NEAR network node
namada-net/namada	2,517	Privacy-focused blockchain
risc0/risc0	2,203	zk virtual machine
succinctlabs/sp1	1,747	zk virtual machine on RISC-V
noir-lang/noir	1,410	Language for zk circuits
alloy-rs/alloy	1,337	Ethereum tooling, successor to ethers-rs
zcash/halo2	920	Proof system
0xPolygonZero/plonky2	859	Recursive proof system
ZcashFoundation/zebra	622	Zcash node

Benchmarks with a source

I kept only the benchmarks with a primary source, code or methodology. Out went the async runtime ones (a post with no code or raw data), the WebAssembly runtime ones (the repository itself marked the numbers as placeholders), and the gitoxide and Redis-style server ones (the sources were only a site's home page, or a site that is down).

Ripgrep versus grep and friends

The ripgrep README has tables measured by the author on an Intel i9-12900K. Searching for [A-Z]+_SUSPEND as a word in the Linux kernel source:

Tool	Time	Ratio
ripgrep	0.082 s	1.00x
git grep	0.273 s	3.34x
The Silver Searcher	0.443 s	5.43x
ugrep	0.639 s	7.82x

Ignoring .gitignore and filtering by file type, ripgrep takes 0.063 s and GNU grep 0.674 s. On a single file of about 13 GB already cached, the search Sherlock [A-Z]\w+ takes 1.042 s in ripgrep, 1.339 s in ugrep and 6.577 s in GNU grep. The same README shows the limits: on a pattern with no literal, like [A-Za-z]{30}, the lead over GNU grep drops to about 2x, and there are patterns where another tool falls off a cliff and ripgrep does not. The first version of this post cited these numbers from ripgrep.dev, which is an unofficial site.

Web frameworks

Sharkbench measures concurrent requests with I/O and JSON on an Intel Core Ultra 5 325 running Linux. The page was updated on 5 October 2026:

Framework	Req/s	Median latency	Memory
Hyper	27,372	1.2 ms	4.6 MB
Axum	26,909	1.2 ms	5.7 MB
Actix	23,833	1.3 ms	6.9 MB
Rocket	21,365	1.5 ms	7.1 MB
ASP.NET Core	17,561	1.5 ms	46.6 MB
Express	7,670	3.7 ms	84.8 MB
Gin	1,652	3.3 ms	13.5 MB

Two caveats. The order changes between updates: in the first version of this post, with numbers from another run, Actix was first. And the page does not describe the load generator or concurrency, so Gin behind Express is a result I would not take as a rule without reading the test code.

JavaScript runtimes

I removed the Bun, Deno and Node numbers: the sources were author profile pages, with no article. What stays is the warning that applies to any comparison of this kind. In a discussion in the Deno repository, Luca Casonato, from the Deno team, answers that you cannot compare two systems with a single HTTP benchmark, because that test does no routing, serves no static files and ignores the rest of what a server does.

Pingora versus NGINX, in production

In Cloudflare's September 2022 post, Pingora serves more than a trillion requests a day and, under the same load, uses about 70% less CPU and 67% less memory than the previous NGINX-based service. Median TTFB dropped by 5 ms and p95 by 80 ms. For one large customer, the connection reuse ratio went from 87.1% to 99.92%, which cut new connections to the origin by 160 times. Much of the gain comes from sharing the connection pool across threads, which NGINX's process model does not allow.

Polars, pandas and plain Rust

Haixuan Tao compared the three on a 4.2 GB dataset from Stack Overflow, on an Intel i7-8750H with 12 threads, with open code:

Implementation	Total time	Versus pandas
pandas	80 s	1x
Polars, single thread	30 s	2.6x
Polars, multithreaded	17 s	4.7x
Polars, lazy and multithreaded	16.5 s	4.8x
Plain Rust, single thread	24 s	3.3x
Plain Rust, multithreaded	13.7 s	5.8x

Leaving out reading the file, multithreaded Rust takes 1.7 s against 40 s for pandas, about 23x. His advice: Polars for the API and for merges and group-bys, pandas when performance and memory do not matter.

WebAssembly runtimes

I found no reproducible, current comparison. If you want to go through the literature, Hockley and Williamson measured scripting performance in Wasmer at the ICPE 2022 conference.

Who uses it in production

Only the cases with a source from the company itself stayed:

VS Code search switched to ripgrep in version 1.11, in 2017
Cloudflare replaced NGINX with Pingora in the proxy that connects its network to the internet
Firecracker runs AWS Lambda and AWS Fargate, according to its README
Discord moved its Read States service from Go to Rust in 2020, because of latency spikes from Go's garbage collector
Vercel finished porting Turborepo from Go to Rust

The first version had more cases and a list of market statistics, such as "45% of the Fortune 500 run Rust", taken from blogs with no source. I removed everything I could not tie to a primary source, including "Discord cut memory by 8 times", which Discord's post does not say.

What I take from it

Most of the top is developer tooling: search, terminals, shells, editors, package managers. It makes sense, because the first Rust adopters were developers writing tools for themselves, where speed, resource use and the command-line experience decide. Right behind come infrastructure and data: proxies, vector databases, search, time series, DataFrames.

The technical patterns repeat. Servers are async on tokio. The most common shape is a single binary configured by file or command line. WebAssembly plugins show up where cheap runtime extension is wanted, as in Zellij. And the foundation is almost always the same: serde, clap, anyhow and thiserror, rayon, reqwest, hyper.

Where there is a serious benchmark, the advantage holds, but with limits. On the Linux kernel, ripgrep is 3 to 11 times ahead of the other tools, and loses its margin on patterns with no literal. Pingora shows a production gain, with CPU and memory measured by the operator itself. Outside those cases, the gain over optimized C or Go is often small, and what weighs in the choice is memory safety, the type system and tooling.

The gaps I see: a full-stack web framework with a plugin ecosystem at the level of Django or Rails, a complete data engineering stack at the level of Spark and Airflow, GUI that competes with Electron and Qt, and native ML that competes with PyTorch. Burn and Candle exist, but are still smaller.

Rust and WebAssembly books and resources

The starting point changed in 2025: the rustwasm organization on GitHub was sunset, and "The Rust and WebAssembly Book" was frozen. wasm-bindgen and wasm-pack moved to a new organization, wasm-bindgen. The old book is still good as an introduction, it just stopped in time.

Rust foundations

WebAssembly demands ownership and borrowing (there is no garbage collector in the browser), interop with JavaScript, async and no_std, because many environments do not have the full standard library.

Book	Authors	Edition	What for
The Rust Programming Language, 3rd edition	Steve Klabnik, Carol Nichols, Chris Krycho	No Starch, March 2026	The starting point; covers the 2024 edition and has a new async chapter
Programming Rust, 3rd edition	Jim Blandy, Jason Orendorff, Leonora Tindall	O'Reilly, due October to November 2026, 748 pages	Intermediate to advanced; the FFI part helps you understand WebAssembly underneath
Rust for Rustaceans	Jon Gjengset	No Starch, 2021	The step after the official book: unsafe, traits, reusable crates
Rust in Action	Tim McNamara	Manning, 2021	Practical systems cases
Zero to Production in Rust	Luca Palmieri	Self-published	Back-end architecture for production
Rust Atomics and Locks	Mara Bos	O'Reilly, 2023, with a free online version	Concurrency, useful for WebAssembly with threads
The Rustonomicon	The Rust team	Online, ongoing	Unsafe, aliasing, FFI
Command-Line Rust	Ken Youens-Clark	O'Reilly, 2022	Command-line tools
Asynchronous Programming in Rust	Carl Fredrik Samson	Packt, February 2024	Futures, executors, epoll, kqueue and IOCP
Hands-On Concurrency with Rust	Brian L. Troutwine	Packt, 2018	Concurrency

Rust and WebAssembly

Book	Authors	Edition	Scope
The Rust and WebAssembly Book	Rust and WebAssembly Working Group	Online, archived in 2025	Browser: Game of Life, wasm-bindgen, wasm-pack
Programming WebAssembly with Rust	Kevin Hoffman	PragProg, 2019	Browser and custom hosts; does not cover the component model or WASI 0.2
Practical WebAssembly	Sendil Kumar Nellaiyapen	Packt, 2022	Rust and WebAssembly in the browser
Practical WebAssembly	Kassian Wren	O'Reilly, 2024	WebAssembly for web developers; same title, different book
WebAssembly with Rust	sendilkumarn	Leanpub	WAT, wabt, binaryen and toolchain
Game Development with Rust and WebAssembly	Eric Smith	Packt, 2022	A 2D game in the browser
Creative Projects for Rust Programmers	Carlo Milanesi	Packt, 2020	Yew, WebAssembly games, REST
Building and Deploying WebAssembly Apps	Peter Salomonsen	BPB, 2025	AssemblyScript, C, C++, Rust and Kubernetes

Watch out for the flood of AI-generated self-published books since 2023, with titles like "Rust for WebAssembly" and authors with dozens of books a year. Before buying, it is worth checking the publisher and whether the author has public code.

WebAssembly in general

Book	Authors	Edition	Relevance for Rust users
WebAssembly: The Definitive Guide	Brian Sletten	O'Reilly, 2021	High: language-independent fundamentals, WASI
The Art of WebAssembly	Rick Battagline	No Starch, 2021	High: WAT in depth, to read what Rust generates
Server-Side WebAssembly	Danilo Chiarlone	Manning	High: WASI on the server, Spin, edge
WebAssembly in Action	Gerard Gallant	Manning, 2019	Medium: focus on C and C++ with Emscripten
Learn WebAssembly	Mike Rourke	Packt, 2018	Low: C and C++
What Is WebAssembly?	Colin Eberhardt	O'Reilly	Medium: overview
WebAssembly System Interface入門	Asuka Yagi	Impress NextPublishing, 2024	Medium: WASI 0.1 and 0.2, with examples in Go

In Portuguese

The only Brazilian book on WebAssembly with Rust I found is Desmistificando WebAssembly, by Raphael Amorim, from Casa do Código, with examples on GitHub. For Rust in general, there is the translation of the 2nd edition of Programming Rust, from Novatec in 2023, and Primeiros Passos com a Linguagem Rust, by José Augusto Manzano, also from Novatec, from 2018. The community maintains a translation of the official book. The rest depends on English.

Documentation with the depth of a book

Resource	Organization	Topics
wasm-bindgen Guide	wasm-bindgen	Interop between Rust and JavaScript
wasm-pack	wasm-bindgen	Build, test and publish to npm
Leptos Book	Leptos	Reactive UI, signals, SSR
Dioxus	Dioxus Labs	UI for web, desktop and mobile
Yew	Yew	Components, hooks, routing
Sycamore	Sycamore	Reactive framework with SSR
Trunk	Trunk	Build and bundling with hot reload
Wasmtime	Bytecode Alliance	WASI, embedding, fuel
Component Model	Bytecode Alliance	Component model, WIT, WASI 0.2
Spin	Fermyon	Serverless WebAssembly
Extism	Extism	WebAssembly plugins
Wasmer	Wasmer	Runtime, WASI, embedding
Compiling Rust to WebAssembly	MDN	First steps in the browser
Embedded WebAssembly Book	Community	IoT and embedded

There is still no book on WASI 0.2 and the component model (only the Bytecode Alliance documentation), on the new frameworks like Leptos and Dioxus, or on security and fuzzing of WebAssembly modules, which today lives in academic papers, like this one from 2024.

People and visualization projects in Rust and WebAssembly

People

The first version had each person's country and role, and errors: it attributed wgpu to two people as if they were one, gave another the wrong name, and listed two profiles that do not exist. I removed the country, which is personal data and which the source itself contradicted. I also removed the role, because what can be checked without depending on anyone's word is the contribution. In the table, each project was checked against the GitHub contributor list. Anyone with no confirmed link was left out.

Person	Projects where they appear as a contributor
Alex Crichton	wasmtime, wasm-bindgen, cargo
Nick Fitzgerald	wasmtime, wasm-bindgen, walrus, wasm-tools
Ashley Williams	wasm-pack
Till Schneidereit	wasmtime, WASI
Luke Wagner	component-model
Dan Gohman	WASI, wasi-libc, wasmtime
Chris Fallin	wasmtime
Pat Hickey	wasmtime, wit-bindgen
Peter Huene	wasm-tools, wit-bindgen
daxpedda	wasm-bindgen
Guy Bedford	wasm-bindgen, workers-rs
Jesper Håkansson	wasm-pack
Syrus Akbary	wasmer
withoutboats	fehler
Aaron Turon	tokio, rfcs
Niko Matsakis	rust, polonius, chalk
Steve Klabnik	book
Carol Nichols	book, crates.io
Jake Goulding	rust-playground
Manish Goregaokar	rust-clippy, unicode-segmentation, servo
Felix S Klock II	rust
Andrew Brown	wasmtime, wasi-nn
Sven Sauleau	workers-rs
Ingvar Stepanyan	wasm-bindgen
Jason Williams	boa
Benjamin Bouvier	matrix-rust-sdk
Henri Sivonen	encoding_rs
Eduard-Mihai Burtescu	rust, rust-gpu
Surma	comlink, squoosh
Greg Johnston	leptos
Jonathan Kelley	dioxus
Kaede Hoshikawa	yew
Emil Ernerfeldt	egui, rerun
Jon Gjengset	haphazard
Luca Palmieri	zero-to-production, cargo-chef
Yosh Wuyts	async-std, http-types, surf
Pascal Hertleif	rust-cli book, diesel
Carter Anderson	bevy
François Mockers	bevy
Frizi	bevy
Dzmitry Malyshau	wgpu
Raph Levien	xilem, druid, kurbo, piet, vello
Hao Hou	plotters
blitzarx1	egui_graphs
Grant Handy	fdg
Yevhenii Reizner	resvg, tiny-skia, rustybuzz
Jorge Aparicio	cross, cortex-m
David Tolnay	serde, syn, cxx, thiserror
Sean McArthur	hyper, reqwest
Mattias Buelens	wasm-streams
Aaron Turner	assemblyscript, wasm-by-example
Michael Sproul	lighthouse
Simon Sapin	servo
Andrew Gallant	ripgrep, regex
Félix Saparelli	watchexec
Jan-Erik Rediger	glean
Ivan Petkov	crane

Graph, chart and visualization projects

The projects on GitHub, with stars from the API. Renamed ones already show their new name.

Repository	Stars	What it is
GoogleChromeLabs/squoosh	26,021	In-browser image optimization with WebAssembly codecs
wasmerio/wasmer	21,152	WebAssembly runtime
bytecodealliance/wasmtime	18,718	The Bytecode Alliance's WebAssembly runtime
jacomyal/sigma.js	12,187	WebGL rendering of large graphs
rerun-io/rerun	11,590	Multimodal visualization for scientific and robotics data
perspective-dev/perspective	11,295	Interactive analytics and visualization with a WebAssembly core
cytoscape/cytoscape.js	11,237	Graph visualization in JavaScript
apache/datafusion	9,444	Analytical query engine
wasm-bindgen/wasm-bindgen	9,187	Interop between Rust, WebAssembly and JavaScript
EmbarkStudios/rust-gpu	7,559	Rust compiled to SPIR-V; Embark's repository was archived
wasm-bindgen/wasm-pack	7,286	Packages Rust as an npm package
nannou-org/nannou	6,766	Creative coding
observablehq/plot	5,403	Statistical charts from Observable
plotters-rs/plotters	4,631	Charts with canvas, SVG and bitmap back ends
mdaines/viz-js	4,353	Graphviz compiled to WebAssembly
linebender/resvg	4,123	SVG renderer in pure Rust
petgraph/petgraph	4,029	Graph data structures, the base of egui_graphs and fdg
silvia-odwyer/photon	3,909	Image processing in WebAssembly
servo/pathfinder	3,895	GPU font and vector rendering
yuankunzhang/charming	2,601	Rust charts on Apache ECharts
tgdwyer/WebCola	2,099	Constraint-based graph layout
thx/resvg-js	1,998	resvg bindings for Node and the browser
dimforge/kiss3d	1,784	Simple 3D library
asny/three-d	1,678	3D renderer that compiles to WebAssembly
linebender/tiny-skia	1,657	Skia port in pure Rust
plotly/plotly.rs	1,457	Plotly for Rust
linebender/piet	1,376	2D rendering abstraction with several back ends
cosmosgl/graph	1,296	GPU visualization of large graphs
chartshq/muze	1,184	Composable data visualization; archived
tremor-rs/tremor-runtime	933	Event stream processing
blitzarx1/egui_graphs	708	Interactive graph widget for egui, on petgraph
alceal/plotlars	671	Bridges Polars and Plotly
rosslh/Mandelbrot.site	330	Mandelbrot set explorer in the browser
rustwasm/wasm_game_of_life	288	Game of Life tutorial in Rust and WebAssembly; archived
grantshandy/fdg	232	Force-directed graph layout
Joylei/plotters-iced	205	plotters back end for iced apps
mazznoer/colorgrad-js	172	Color gradients in Rust and WebAssembly
feral-dot-io/leptos-chartistry	147	Charts for Leptos
brson/wasm-opt-rs	100	Bindings for the wasm-opt optimizer
angular-rust/ux-charts	39	Responsive canvas charts
plotters-rs/plotters-canvas	38	HTML5 canvas back end for plotters
Billy-Sheppard/chart-js-rs	28	Chart.js bindings

Outside GitHub, as crates: forge-charts makes interactive SVG charts for Leptos without JavaScript; mermaid-rs-renderer renders Mermaid diagrams in pure Rust and claims to be 100 to 1,400 times faster than mermaid-cli; dagre ports dagre's Sugiyama layout; and web-sys and js-sys are the bindings for web APIs and JavaScript objects, maintained inside wasm-bindgen. On the commercial side, Ogma, from Linkurious, is a WebGL graph engine.

What I take from it

Visualization in Rust and WebAssembly splits into four groups. GPU rendering: wgpu, vello, three-d, bevy. Charts and dashboards tied to web frameworks: plotters, plotlars, charming, leptos-chartistry. Graphs: petgraph, egui_graphs, fdg, dagre. And scientific visualization: rerun, resvg, tiny-skia.

Graphs are the weakest group. There is no mature equivalent of networkx or d3-force in Rust with WebAssembly, and advanced layout, hierarchical or Sugiyama, is still rare. For large, dynamic graphs in the browser, JavaScript is still ahead with sigma.js and cytoscape.js. And there is little material in Portuguese linking Rust and WebAssembly to data visualization. A Portuguese-speaking community exists, like the Rust Brasil group on Telegram, but I found no Brazilian visualization project with international traction.