Critique of Rust's pace, governance and rewrite culture hits Hacker News front page

A critical essay about the Rust programming language climbed to Hacker News' front page this week, reopening an old argument in systems programming: not whether memory safety is worth pursuing, but how fast the migration should run and who should be trusted to steer it.

What the essay argues

The post, published on oxetene.net under the title Problems with the Rust Language, was written by a programmer who mainly works in C. The author opens by endorsing memory safety — debugging memory corruption in C is familiar territory — and even concedes that Rust is a clear technical improvement over C++. The complaint is not the language's grammar but the ecosystem growing around it: its funding, its incentives and the behaviour of parts of its community. According to the author, the speed at which Rust is being adopted is itself the risk.

Corporate stewardship in question

The first target is the Rust Foundation. The essay notes that the organisation presents itself as an independent nonprofit while listing Amazon, Google, Huawei, Microsoft and Mozilla among its founding members, and asks how independent a language can be when its stewardship has been tied to corporate interests from the beginning. The author also cites a figure of $325,000 per year for a dedicated seat on the Foundation's board. Five corporations do not co-manage a project out of charity, the argument goes; they do so because it serves them.

Rewrites as a security strategy

The essay is harsher about the community habit of rewriting established projects in Rust, which the author calls the worst possible route to better security. Replacing reliable, long-tested code with fresh rewrites discards years of accumulated bug fixes, the post argues, and Rust offers no protection against plain logic errors — good programs still require good programmers, and even good programmers are limited when asked to reinvent the wheel.

The post then makes its most contested claim, an argument the author credits to Jody Bruchon: projects rewritten in Rust tend to begin under the GPL and come back under the MIT license, which frees companies to embed the code without reciprocal obligations. The author's example is locked-down Linux distributions, and the essay characterises Rust rewriters as doing unpaid work for corporations that want GPL-licensed code out of their supply chains.

A single compiler to trust

The final concern is bootstrapping. According to the essay, the only practical way to build the Rust compiler today is to start from a binary package of a previous version distributed by the Foundation, meaning a backdoor planted in one release could in theory carry forward into every later build. The author is candid about this point: it is labelled speculative and possibly conspiratorial within the essay itself, and the binaries may well be clean. The deeper problem, as the post frames it, is that with only one fully usable implementation of the compiler, users have no option except to trust the Foundation — and given its ownership and what the author describes as a history of mismanagement, the author declines to.

The proposed alternative

The essay's closing suggestion is simply to slow down. Rather than rewriting other people's software, the community should improve the language itself and support the GCC Front-End for Rust project, an alternative compiler that the author says would ease the single-implementation concern, while acknowledging that it remains in an early phase of development. Readers interested in criticisms of Rust's design itself are pointed toward a separate post by Nimfsoft.

Why it matters

The traction the essay found on Hacker News suggests it touched a nerve well beyond Rust partisanship. As memory-safe languages move from enthusiast preference toward default assumption in systems work, the post is a reminder that the transition raises questions no borrow checker can settle: whether wholesale rewrites beat hardening mature code, whether copyleft licensing survives the shift toward permissive replacements, and how much trust a single compiler implementation distributed by a corporate-funded foundation should command. Even readers who dismiss the backdoor speculation — as its own author invites them to — are left with a governance debate that is now inseparable from the technical one.