Census of 32 repos finds Rust winning by rewrite, not by migrating incumbent C projects

A census of 32 widely used open-source repositories concludes that the C and C++ to Rust migration is real but far narrower than the surrounding policy debate implies: only two of sixteen flagship C projects contain any Rust at all, and where Rust has won, it has done so through complete reimplementations rather than incremental conversion.

Those figures come from an analysis published on dev.to, which summarizes a study in issue 52 of SILICON SCIENCE – Computer Science, a journal that the post describes as peer-reviewed by autonomous agents, with public review comments and reproducible papers.

What was measured

The study pairs sixteen long-established C or C++ projects with Rust alternatives that occupy the same niche, across four categories: system utilities (coreutils versus uutils, sudo versus sudo-rs, the_silver_searcher versus ripgrep, git versus gitoxide), networking and async code (OpenSSL versus rustls, zlib versus miniz_oxide, libuv versus tokio, ngtcp2 versus quiche), terminal and data tools (vim versus helix, tmux versus zellij, htop versus bottom, jq versus jaq), and security and cryptography (GnuPG versus rpgp, BoringSSL versus ring, OpenSSH versus russh, libsodium versus sodiumoxide).

From pinned snapshots of those 32 trees, the authors classified 252 source components as Rust, C, C++ or mixed. A hand-annotated validation matrix covering 36 cells matched the automated classification exactly, the post reports, and the full census can reportedly be regenerated byte-identically from committed snapshots with a single script.

Incumbent C projects are largely standing still

Only two of the sixteen C/C++ repositories contain any Rust: git, where 10.5 percent of source components relate to its new Rust object store, and Google's BoringSSL, where an in-tree Rust component accounts for 11.1 percent. The other fourteen — including coreutils, sudo, OpenSSL, zlib, libuv, vim, tmux, htop, jq, GnuPG, OpenSSH and libsodium — measure at zero percent Rust.

Mixed-language components are almost nonexistent: one out of 252, or 0.4 percent, and that lone case is git's C core combined with its Rust object-store work. According to the dev.to summary, adoption within a component is effectively all-or-nothing; nobody is sprinkling Rust files into otherwise-C components.

Rust adoption means rewrite, not wrapping

On the Rust side of each pair, fifteen of the sixteen projects are independent reimplementations. The only exception is sodiumoxide, which binds to the original libsodium through the libsodium-sys crate. Expressed as a population-level answer to a recurring engineering question, that works out to 93.75 percent full rewrites versus 6.25 percent FFI bindings.

The practical consequence is that when a project advertises itself as a Rust version of an older tool, it is almost always new code with its own bugs, performance profile and API surface — not a thin memory-safe layer over the battle-tested C library underneath.

Limits worth knowing

The census itself flags one gap: databases and web servers are excluded because PostgreSQL, MySQL and Nginx have no maintained Rust counterpart of comparable standing, so the study covers only the four domains where C-to-Rust pairs actually exist. The validation matrix is also small at 36 cells, and the publishing venue's agent-run review process is unusual enough that independent replication would strengthen the numbers.

Why it matters

Since 2024, regulators and vendors — CISA and the ONCD with their "Back to the Building Blocks" guidance, Google with Rust in the kernel, Microsoft with its own adoption — have pushed memory-safe languages as a priority. This census supplies code-level ground truth for that conversation: where migration is observable, it proceeds component by component rather than file by file, and it concentrates in safety-critical internals such as git's object store and BoringSSL's cryptography. For teams weighing whether to rewrite a C component in Rust, the data suggests the dominant pattern is a parallel, complete reimplementation that must win adoption on its own merits — while the incumbent flagship projects, at least in these domains, have barely begun to convert.