Why I'm a Rustacean
The fall and winter of 2025 turned up the volume on the debates around Rust adoption. There have been some high profile successes, some equally high profile missteps, and now technologists who were not opining on the language a year ago are joining the conversation. Within those discussions is the assumption that programming language choice is always pure dogma and Rustaceans are particularly susceptible to this. Having myself been a semi-professional Rust evangelist I've been self-reflective about why I care about this language and how I speak about it.
After some introspection and soul-searching I feel confident that I come by my motivation honestly. I may be a Rustacean in the way that a sports fan defines themselves by their team allegiance - there is a skin-deep and often self-deprecating aesthetic performance in the moniker. Yet beneath the team spirit my motivations remain as valid as ever. The language itself continues to have promise but after a few years of participating in the Rust community it's what I've found there that keeps me coming back.
The Rust Ethos is Unique
The core ethos of the Rust language is that deterministic correctness has an intrinsic value that is tautologically different from best practices, cultural norms, or developer experience. Maybe correctness is not always universally superior but you cannot pull a Moneyball and build it in the aggregate with a collection of cultural and statistical methods. I cut my engineering teeth in the automotive industry; a highly regulated safety-critical field where the question of "how do you know it's safe" was always at the tip of the tongue. The possibility that a provably correct answer to this question could exist has long held self-evident value and will always be on a different plane than "it's probably safe".
It's this ethos that sustains my faith in the Rust community and even the Project itself (the organization that builds the actual language, compiler, and core tooling). Not because they're infallible or even because they have a perfect track record. But because that pillar (and a few other corollaries like robustness in space and time) is truly a guiding principle shared by everyone deeply involved in the language. There have been Rust features implemented poorly or not implemented at all because of these values and there have been features fixed or eventually implemented very well because of them. These values have been simplified and codified by Niko Matsakis into the idea of "foundational software", adding backwards compatibility, efficiency, portability, and other corollaries to correctness. These values are still omnipresent among Rustaceans and as long as that culture steers the ship my confidence in the language perseveres.
This is a novel philosophy within the most vocal sections of the software industry. I spent much of my career in automotive feeling strongly that there must be a better and more innovative way to engineer. I looked to the tech industry because of their inventiveness and velocity over the last few decades but what I found was a culture of fast approximation. Implicit in agile methodology, CI/CD, and even recent business practices is the underlying philosophy that software need not be initially correct or even particularly useful provided that the mechanisms for rapid feedback and change are in place. This is an appropriate fit for many of their applications and industry but it is not a generalizable solution (though it's my opinion that it's increasingly not fit-for-purpose even within tech). My rapid infatuation with Rust was because it was the first and most significant outcome of the tech industry I've found that is applicable to the class of problems I'm motivated to solve.
What a Community of Robustness Builds
Once the flag of robustness was hoisted over the Rust encampment the technologists who came far and wide built on that philosophy. There are now scads of interesting projects entirely separate from Rust's technical abilities yet well aligned with its mission. I've found about a dozen formal verification tools, like kani and miri, as well as more fundamental projects like stable-mir. There are testing projects like cargo-fuzz and cargo-proptest which extend cargo's already formidable built-in unit testing capabilities with fuzz and property based testing. The embedded tool probe-rs integrates a microcontroller into the cargo testing framework, tightening the feedback loop even in bare-metal development. Software supply chain tools like cargo-audit and cargo-machete are concerned with dependency resolution. Requirements-code-test tracing is deeply integrated with mantra. Even semver can be made rigorous with cargo-semver-checks, which lints your code for breaking changes. None of these particularly require Rust to exist (Cargo is a convenient platform but other languages have similar tools) and other languages have their share of interesting correctness tools. But there is an outsized correctness proliferation in Rust and I believe it's the culture that attracts and encourages these exciting projects.
These values give Rust a sort of customer-obsessed mindset. I enjoy working on vintage cars and their fiddly carburetors but it wouldn't be a sound engineering decision if I recommended the technical result of a product based on the engineering process that I enjoyed. Yet developer experience is invoked in nearly every discussion about language selection. While DX is a valid point regarding IDE choice or Git platform it's irrelevant as soon as you're shipping your DX to the customer. I don't think the theory that language choice is irrelevant to customer experience is defensible any longer. Though the Rust community has gregariously built delightful tooling it may be in compensation for the underlying trade-off: Rust prioritizes the experience of the people running the software more than that of those writing it.
What Foundational Software Can We Build?
We need to build a lot of really good software quite quickly. The GNU core-utils Rust rewrite has polarized discussion boards and a valid critique is "why are we replacing some of the oldest and most proven software tools with scratch rewrites?" The answer to the "why" part of that question is complicated (and comes with an 'it depends' asterisk) but it begs the much more interesting question: why can't we build new reliable and robust software?
Shifting tides in the tech industry are changing the constraints of mainstream software development. After a decade of SaaS software running on the cloud the local-first movement is envisioning a return to software that runs on user devices. Environments without a managed cloud-instance and a team of on-call SREs ready to leap into action and fix the bugs and interruptions that are considered unavoidable. But even if the tech industry remains as cloud-obsessed as ever we need robust software for a fleet of new machines; automotive software, robots, rockets, and satellites. These are not environments where CI/CD can apologize for inevitable bugs. If the most engaged software engineers aren't confident that we can write robust and reliable applications as comparatively simple as GNU core-utils then what chance do we have to send software to the moon? Or build a modern and software-defined energy grid? Is the tech software industry content to abdicate their role in building the future because they lack the confidence or motivation to do real engineering and accept more challenging constraints?
The answer to that provocative yet facetious question is no, obviously they are not. Or not all of them. It's in enclaves like - but not exclusively - the Rust community where I find the engineering culture attempting to build software tools for these strict requirements. Perhaps they're not relevant to you or your industry's project constraints but nearly the entire class of technical problems most important to the human race need a lot of unprecedented yet high-quality software. As long as the Rust language and culture are building a tool for that purpose I'll find a home there and call myself a Rustacean.