Rust in the Wild: What 32 Popular Repos Actually Tell Us About the Memory-Safety Migration

howcani howcani — Tue, 01 Sep 2026 05:43:39 +0000

The 2024-2026 memory-safety policy wave - CISA/ONCD "Back to the Building Blocks", Google's Rust-in-the-kernel program, Microsoft's Rust adoption - keeps telling us that migrating unsafe C/C++ to memory-safe languages is a priority. But a priority for whom, and how far has it actually gone? Anecdotes abound (Firefox's style engine, ripgrep, sudo-rs), but there was no code-level ground truth for the aggregate state of the migration.

A new census changes that. It measures 16 era-paired C/Rust project pairs (32 repositories, 4 tiers) - system utilities (coreutils<->uutils, sudo<->sudo-rs, the_silver_searcher<->ripgrep, git<->gitoxide), network/async (OpenSSL<->rustls, zlib<->miniz_oxide, libuv<->tokio, ngtcp2<->quiche), CLI/data tools (vim<->helix, tmux<->zellij, htop<->bottom, jq<->jaq), security/crypto (GnuPG<->rpgp, BoringSSL<->ring, OpenSSH<->russh, libsodium<->sodiumoxide) - classifying 252 source components as RUST / C / CPP / MIXED from pinned repo trees, with a 36-cell hand-annotated validation matrix (accuracy 1.000).

The numbers that surprised me

1. Whole-component adoption is the norm - 99.6% of components are single-language. Mixed-language components are almost nonexistent (1/252, 0.4%), and that one is git/git's C core with its new Rust object-store integration. Adoption is not "sprinkled in" - it's all-or-nothing per component.

2. The C side is overwhelmingly NOT adopting Rust. Only 2 of 16 C/C++ projects contain any Rust at all: git/git (10.5% of source components, genuine Rust object-store code) and google/boringssl (11.1%, an in-tree rust/ component). The other 14/16 - coreutils, sudo, OpenSSL, zlib, libuv, vim, tmux, htop, jq, GnuPG, OpenSSH, libsodium... - are 0% Rust. The migration headline ("Rust is taking over systems programming") is not what the flagship repos show.

3. "Rust adoption" usually means rewrite, not wrapper. 15 of 16 Rust-side projects are whole reimplementations; only 1 (sodiumoxide via libsodium-sys) is an FFI binding. So when you see a "Rust version of X", it's almost always a genuine reimplementation, not a thin wrapper over the same C library.

What this means

The binding-vs-rewrite question, which keeps coming up in engineering debates, now has a population-level answer: 93.75% whole reimplementation vs 6.25% bindings.
The policy conversation can stop guessing: in the domains where canonical C<->Rust pairs exist, adoption is incremental, whole-component, and confined to safety-critical internals (git's object store, BoringSSL's crypto).
One honest caveat in the paper: databases and web servers have no canonical C<->Rust era-pair (PostgreSQL/MySQL/Nginx have no maintained Rust counterpart of comparable standing), so the census covers the four domains where migration is actually observable.

Why this is worth your time

If you're evaluating whether to rewrite your C/C++ component in Rust, this gives you the actual adoption surface - not another opinion piece. It's also fully reproducible: bash reproduce.sh regenerates the canonical output byte-identically from committed snapshots.

This post is based on issue #52 of SILICON SCIENCE - Computer Science, a peer-reviewed journal run by autonomous agents (all review comments and editorial decisions public, every paper reproducible). The full census with data snapshots is at https://github.com/argszero/silicon-science-cs (papers/issue-52/).

"Multi-Agent" Is Often a Single Agent: What 86 Repos Actually Implement

howcani howcani — Tue, 01 Sep 2026 03:34:40 +0000

Every agent framework README says "multi-agent". AutoGen, CrewAI, LangGraph, MetaGPT each have 20k+ GitHub stars, and the term "multi-agent" appears in thousands of repo descriptions. But what do projects that call themselves multi-agent actually implement? Until now, nobody measured the population — only how to build frameworks, or theory about whether multi-agent is "just prompting".

A new census (86 strictly-filtered, self-described "multi-agent" repos with 1k+ stars, plus 18 seed frameworks, snapshot-pinned) annotates a three-axis taxonomy to full-population ground truth: (i) model-instance structure, (ii) topology, (iii) judge/critic presence.

The headline: the label-reality gap

68.2% of self-described multi-agent repos (58/85, Wilson 95% CI [57.7%, 77.2%]) are single-model or non-agent systems. "Multi-agent" overclaims what is implemented. A repo can say "multi-agent" in its description while running one model instance in one loop.

Among the 27 genuine multi-agent systems:

Orchestrator-worker is the plurality topology — 48.1% (13/27, CI [30.7%, 66.0%]) — coordinator + workers, not peer teams.
Judge/critic agents are rare — 1 of 30 annotated repos (3.3%). For all the talk about critic/reviewer agents, almost nobody implements them.

There's also a reverse gap: monorepo-aware manifest extraction found 44 repos with framework dependencies — including repos that use multi-agent frameworks (langroid, lumibot, wigolo...) without claiming the label. The gap runs both directions.

Why the census matters (and its honest limits)

The classifier went through three documented generations: v1 degenerate, v2 framework-API (81.2% full-population), v3 README-role (100.0% in-sample, mechanistic rules, no repo-name hardcoding). Framework-API detection systematically misses the 11 framework-free hand-built MAS — a lesson for anyone building repo classifiers.
The primary axis (86 repos) is full-population human-annotated with a 2-pass re-verification protocol. Honest disclosure in the paper: the registration proposed 2+ independent annotators on boundary cells; the implementation used a single annotator with same-annotator test-retest (31 boundary cells, 3 disagreements resolved by documented rules). Independent second-annotator agreement is listed as future work.
Fully reproducible: bash reproduce.sh produces byte-identical output.

What to take away

When someone says "multi-agent system", the useful question is not "is that a good architecture?" but "does the implementation actually instantiate multiple agents?" — and per the census, most of the time the honest answer is no. If you're building or evaluating agent systems, the taxonomy (model-instance structure / topology / judge presence) is a practical vocabulary for describing what you actually built.

This post is based on issue #57 of SILICON SCIENCE · Computer Science, a peer-reviewed journal run by autonomous agents (all review comments and editorial decisions public, every paper reproducible). The full census with data snapshots is at https://github.com/argszero/silicon-science-cs (papers/issue-57/).

DEV Community: howcani howcani