Rust is everywhere, and it’s no surprise it’s also made its way into the lowest levels of certain operating systems and kernels, so it shouldn’t be surprising that various operating system developers have to field questions and inquiries about Rust. NetBSD developer Benny Siegert wrote a blog post about this very subject, and in it, details why it’s unlikely Rust will find its way into the NetBSD base system and/or the kernel
First, NetBSD is famed for its wide architecture and platform support, and Rust would make that a lot more troublesome due to Rust simply not being available on many platforms NetBSD supports. Rust release cycles also aren’t compatible with NetBSD, it would draw a lot of dependency code into the base system, and keeping Rust and its compiler toolchain working is a lot of work that falls on the shoulders of a relatively small group of NetBSD developers.
Note that while NetBSD does tend to take a more cautious approach to these matters than, say, Linux or FreeBSD, the operating system isn’t averse to change on principle. For instance, not only is Lua part of the base system, it’s even used in the NetBSD kernel due to its ability to rapidly develop and prototype kernel drivers. In short, while it doesn’t seem likely Rust will make it into the NetBSD base system, it’s not an impossibility either.
>Rust simply not being available on many platforms NetBSD supports
I think this was also the reason why alternative OS like ArcaOS and AmigaOS had to drop their ports of Firefox, once Firefox started using Rust.
Unopposed0108,
Unfortunately this will become more common as essential software like python, apt, or even git require rust. (or about to)
Either more operating systems (and niche platforms) will drop those rust programs.
Or they will have to drop the hard rust requirements.
It feels like we rolled the clock back. From “we will have Linux on every machine and every screen, even your HDMI cable itself!” to “we will only support a select subset of high end platforms where llvm and rust are stable”
(SPARC, Alpha, m68k, or niche RISC-V platforms are going to be unsupported dinasours. Where did we go wrong?)
This is sad to see as long term Linux (and indirectly BSD) user. Decades of progress is lost.
First, I am not advocating that NetBSD starts to use Rust in their kernel. That said, some of these points are not forever.
> There are many architectures that NetBSD supports where Rust is not available
This is cited as the most important point but the same is true of Linux as well. Linux started by experimenting and using Rust optionally on platforms where Rust is available. NetBSD could do the same.
The rustc_codegen_gcc project allows using the rustc compiler to target any architecture that GCC supports. This project may already be far enough along to do what NetBSD needs.
https://github.com/rust-lang/rustc_codegen_gcc
> getting a Rust compiler running in the first place is hard
> bootstrap relies on a binary package
> the compiler would also have to be part of the base system
The gccrs project aims to make Rust a fully supported language in GCC. It targets all the same platforms as GCC and will build from source whenever you build GCC. Once gccrs is ready, it addresses all the concerns raised above.
https://github.com/Rust-GCC/gccrs
Again, Linux faces the same issues. For Rust to become mandatory in Linux, gccrs is going to be required (for some platforms at least).
> the release cycles of Rust are not compatible with the NetBSD ones
I feel like I do not understand what is being said here. Obviously NetBSD would not need to use any features they cannot compile. And even if they use gccrs for the kernel, they could include both LLVM and rustc in ports. They could include a newer version of gccrs as well. How is Rust any different in this way from other languages, like C++ or even LUA? I am clearly missing something.
And again, I am not telling NetBSD to use Rust. I am just saying that solutions to the issues raised are in development.
LeFantome,
NetBSD may not be the type to do something just because linux did. Many users don’t care about archaic architectures, but for NetBSD it’s a point of pride. I can see it being a show stopper for them.
I understand some of the resistance to projects having to require multiple compiling tools. Making Rust a first class citizen in the GNU suite will open more doors. Adding rust to GCC should help alleviate both support and compatibility concerns over time.
I’d agree it’s possible. I think what’s “missing” is the fact that NetBSD are generally more conservative and less likely to want rust in the first place. Fans of Rust should probably look for it in FreeBSD first, where it’s likely to gain more traction simply because the goals and philosophy are more accepting of it.
@Alfman
> Many users don’t care about archaic architectures, but for NetBSD it’s a point of pride. I can see it being a show stopper
Completely agree.
Again, my point is not that NetBSD should use Rust. “We don’t want to” is a good enough reason for me. Not wanting to mix languages is a pretty strong argument as well though the blog post downplays this objection by implying that Rust would less of an odd choice than LUA.
In fact, the tone of the article comes off feeling as if they would move to Rust if they could but that they just cannot. The author even pushes back a at the suggestion that Rust is a bad choice by saying “I would be interested to learn why you think this is an odd decision”. And they they give reasons blocking a move to Rust where all of those reasons are not so much “not Rust” as “not yet”. But they do not explain that at all.
gccrs aims to successfully compile the Linux kernel (Rust bits) sometime this year and perhaps to be usable for that purpose in 2027. That is not so far away and a project that found Rust attractive could easily start experimenting with the view of gccrs being ready for serious use on that timeline. I am not saying anybody “should” experiment with Rust. But if your only source of information was this blog post, you would come off thinking Rust on non-LLVM architectures was a complete non-starter for technical reasons. And that is not really true.
https://rust-gcc.github.io/2026/01/08/2025-12-monthly-report.html
If the blog post had raised any of the various ways you can use Rust with GCC (there are actually more than the two I mentioned), it would of course have been totally fine for it to conclude that they were too experimental for a conservative project like NetBSD. That would have found no argument from me.
To repeat, I am in no way pushing Rust on NetBSD or any other project.
But NetBSD is not the only project with legacy platform needs . The Linux kernel has the exact same problem. A really big deal was made earlier this year about APT in Debian adopting Rust with even the APT developer suggesting that this would mean the end of some Debian ports. Lots of people expressed a lot of anxiety when Git started talking about Rust. And Ubuntu may not be the only distro looking at Uutils. The fate of these projects is not necessarily limited by LLVM’s platform choices.
My intention is not to advocate for Rust at all but rather simply to educate anybody that is concerned about what Rust proliferation may mean for old or niche hardware that is not currently targeted by LLVM. It is not the show-stopper that I have seen it made out to be. Or, at least, it may not be for long.
I agree with everything you said. I am mostly talking to the cloud here.
LeFantome,
Isn’t that literally the definition of a unproven software?
It is not even ready, not to mention tested.
As people on those “niche” platforms will find out “just replacing the software with a better! version” is not going to work.
They will be on the hook of fixing and maintaining an experimental piece of software…
While C is already working on those platforms for dedaces.
Except for the release cycle issue all of the same problems affect OpenBSD as well.
AFAIK NetBSD focus a lot on simplicity (and being able to compile to a lot of different platforms). Both things that Rust doesn’t really fit into, being complex and still not compiling for that many platforms.