The NetBSD project has drawn a clear line in the sand regarding the use of Rust programming language in its kernel, establishing itself as a notable holdout in an era where memory-safe languages are increasingly viewed as essential for systems programming. While Linux, Windows, and other major operating systems embrace Rust for critical components, NetBSD’s leadership has articulated a firm position that the language will not find a home in their kernel codebase—a decision that reveals deeper philosophical divides within the open-source community about language evolution, project governance, and technical pragmatism.

According to Phoronix, NetBSD developer and core team member Taylor Campbell made the project’s position unequivocal in recent discussions. The stance reflects not merely technical considerations but fundamental concerns about build infrastructure complexity, toolchain stability, and the project’s longstanding commitment to portability across dozens of hardware architectures. For NetBSD, which prides itself on running on everything from vintage VAX systems to modern ARM processors, the introduction of Rust represents challenges that extend far beyond the language’s technical merits.

The decision stands in stark contrast to movements within other operating system projects. The Linux kernel has been actively integrating Rust since 2022, with kernel maintainer Linus Torvalds expressing cautious optimism about the language’s potential to reduce memory safety vulnerabilities. Microsoft has publicly committed to rewriting portions of Windows in Rust, while Google’s Android team has incorporated Rust into the operating system’s core components. These high-profile adoptions have created an industry narrative that Rust represents the inevitable future of systems programming.

Technical Debt Versus Technical Investment

NetBSD’s resistance centers on practical concerns about compiler availability and maintenance burden. The Rust compiler itself is written in Rust—a bootstrapping approach that creates what some developers view as a circular dependency problem. For a project like NetBSD that supports architectures where modern compiler toolchains may be limited or nonexistent, this presents a genuine obstacle. Campbell and other NetBSD developers have emphasized that requiring Rust would effectively limit the operating system’s portability, potentially abandoning platforms that remain important to their user base.

The build infrastructure implications extend beyond simple compiler availability. Rust’s rapid release cycle, with new stable versions every six weeks, creates maintenance challenges for projects that prioritize long-term stability. NetBSD releases operate on multi-year cycles, and the prospect of tracking Rust language evolution while maintaining backward compatibility across numerous hardware platforms represents a resource commitment the project appears unwilling to make. This calculation differs markedly from Linux, where corporate backing from companies like Google, Microsoft, and others provides resources to manage such complexity.

Memory Safety Arguments Face Scrutiny

Proponents of Rust adoption frequently cite memory safety as the paramount justification, pointing to research showing that approximately 70% of security vulnerabilities in systems software stem from memory management errors. The language’s ownership system and borrow checker theoretically eliminate entire classes of bugs that plague C and C++ codebases. However, NetBSD developers have questioned whether these benefits justify the costs for their particular project, especially given their existing code quality practices and security track record.

The NetBSD team’s perspective reflects a broader debate about whether memory safety requires wholesale language replacement or can be achieved through improved tooling, coding practices, and verification methods for existing languages. Static analysis tools, fuzzing infrastructure, and formal verification techniques have advanced significantly, offering alternative paths to enhanced security without the disruption of introducing new languages into mature codebases. For a project with limited developer resources, investing in these approaches may represent a more pragmatic strategy than undertaking a multi-year language migration.

Philosophical Differences in Project Governance

Beyond technical considerations, NetBSD’s stance reveals philosophical commitments about project independence and decision-making autonomy. The project has historically emphasized technical conservatism and careful evaluation of new technologies rather than following industry trends. This approach has sometimes left NetBSD appearing behind the curve compared to Linux or FreeBSD, but it has also contributed to the system’s reputation for stability and reliability in production environments where change carries significant risk.

The governance model matters because language choices have profound implications for contributor communities. Requiring Rust knowledge for kernel development would fundamentally alter who can contribute to NetBSD, potentially excluding experienced systems programmers who have invested decades in C expertise. While advocates argue this transition is necessary and that new contributors will bring Rust skills, NetBSD appears to prioritize continuity with its existing developer community over attracting a different demographic of contributors.

The Portability Imperative

NetBSD’s commitment to portability represents perhaps the most compelling technical justification for its position. The project officially supports over 50 different system architectures, from common platforms like x86-64 and ARM to exotic systems like the DEC Alpha, Motorola 68000-based machines, and various RISC processors. This extraordinary breadth of hardware support constitutes a core element of NetBSD’s identity and value proposition—the operating system’s motto is literally “Of course it runs NetBSD.”

Rust compiler support remains uneven across this diverse architectural spectrum. While the language supports major modern platforms well, tier-2 and tier-3 targets receive less attention, and some architectures important to NetBSD lack reliable Rust toolchains entirely. Adopting Rust for kernel components would force difficult decisions about which platforms to continue supporting, potentially fragmenting the codebase or abandoning systems that still serve important niches in industrial, embedded, and legacy computing environments.

Industry Pressure and Independent Paths

The broader industry momentum toward Rust creates subtle pressure on projects like NetBSD to conform or risk appearing outdated. Major technology companies, security researchers, and funding organizations increasingly view memory-safe languages as essential for critical infrastructure. This creates potential challenges for projects that chart different courses, particularly regarding security certifications, corporate adoption, and access to development resources that may preferentially flow toward Rust-adopting projects.

However, NetBSD’s position also demonstrates that the open-source ecosystem retains space for diverse technical approaches. Not every project must follow identical paths, and maintaining alternatives provides valuable diversity for the computing ecosystem. If Rust adoption later reveals unexpected drawbacks or limitations, projects like NetBSD that preserved C-based approaches will offer important reference points and potential fallback options.

Resource Constraints and Realistic Assessment

The NetBSD project operates with significantly fewer resources than Linux or commercial operating systems. The core team consists of volunteers and a small number of sponsored developers, contrasting sharply with the thousands of paid engineers working on Linux kernel development. This resource reality makes ambitious technical transitions particularly challenging, as the project lacks the capacity to maintain parallel implementations or dedicate teams specifically to language migration efforts.

This constraint forces NetBSD to make hard choices about where to invest limited development resources. Rather than pursuing Rust adoption, the project may calculate that efforts are better spent on improving existing code, supporting new hardware, fixing bugs, or enhancing features that directly benefit users. From this perspective, the Rust decision reflects not technological conservatism but realistic assessment of what a small team can accomplish effectively.

Future Implications for BSD Systems

NetBSD’s stance distinguishes it from other BSD projects that have shown more openness to Rust. FreeBSD has experimented with Rust in userland utilities and discussed potential kernel uses, while OpenBSD has characteristically taken a cautious wait-and-see approach. These diverging paths may lead to interesting differentiation among BSD systems, with each project optimizing for different priorities and use cases based on their Rust decisions.

The long-term consequences of NetBSD’s position remain uncertain. If Rust proves transformative for systems programming and becomes truly unavoidable for modern software development, NetBSD may face increasing difficulty attracting contributors and maintaining relevance. Alternatively, if Rust adoption proves more complex or problematic than current enthusiasm suggests, NetBSD’s conservative approach may be vindicated. The project’s decision essentially represents a bet that C-based systems programming retains viability and that portability and stability outweigh the theoretical benefits of memory safety guarantees.

What remains clear is that NetBSD’s firm rejection of Rust in its kernel represents more than a simple technical decision. It reflects deep commitments to portability, project independence, and careful evaluation of technology adoption that have defined NetBSD’s character throughout its history. Whether this proves prescient or problematic will likely take years to determine, but the decision ensures that the open-source ecosystem retains genuine diversity in approaches to systems programming—a diversity that may ultimately benefit the entire computing community regardless of which technical path proves optimal.