EEE
The systemd project has officially introduced support for developing programs in Rust, following the merger of a pull request submitted by Linux kernel developer Christian Brauner. The change, merged into the project’s main branch, establishes a new development option for systemd while keeping its existing C-based architecture intact.
And before anyone assumes systemd is preparing a complete rewrite in Rust, that’s not the case. The maintainers agreed on a deliberately limited approach: Rust may be used only for new, standalone components that other parts of systemd do not depend on. Existing C code will remain untouched.
Another important decision concerns the build process. Rather than introducing Cargo, Rust’s standard package manager and build tool, systemd continues to use Meson for all builds. This keeps Rust development integrated into the project’s existing build infrastructure.
The implementation also places strict limits on dependencies. Rust programs use the no_std approach, meaning they do not rely on Rust’s standard library or external third-party crates. Instead, they interact with systemd’s existing C libraries through generated bindings.
For memory management, systemd provides its own Rust implementations of common container types, with allocation failures handled explicitly rather than causing the program to abort. The new infrastructure also includes wrappers for logging, command-line argument handling, event processing, and error management, allowing Rust utilities to behave consistently with their C counterparts.
Rust support is optional and automatically detected during configuration. Developers wishing to enable it need Rust 1.85 or later, bindgen 0.71.1 or later, and Meson 1.4 or later. Systems without the required toolchain can continue building systemd without Rust support.
Interestingly, initial tests show that a stripped Rust command-line utility occupies about 32 KB, compared to 20 KB for its C equivalent built with link-time optimization. This gives an early indication of the additional overhead, though the comparison involves only a small test program.
The first planned real-world application of this infrastructure is systemd-keyring-setup, a new utility intended to help manage certificates in Linux kernel keyrings. Its implementation is being developed separately, alongside additional Rust wrappers for systemd’s shared libraries.
For Linux distributions, the change introduces packaging considerations. Builds that enable all available features will need the appropriate Rust compiler and bindgen dependencies or must disable Rust support to avoid build failures.
Whether Rust becomes widely used within systemd will depend on future development, but the necessary groundwork is now in place.
As I said, there’s only a minority of cases where that’s possible and/or advisable.
Because people still need to write such programs for those minority use cases (and if there was no need, then they should not write them).
And rustc is in fact widely available. Whenever there’s need for no-dependencies “freestanding” software (which has a specific meaning, it’s not the same as your “self-confined”) or rust being on the side (ie. like Linux kernel), people have no problems to use rustc (if it fits their toolchain better). It being packaged together with cargo does not stop rust devs from using rustc when it’s appropriate to do so.
I find it hard to believe that you legitimately do think that the one thing stopping people from using rustc for these usecases is that archlinux happens to include cargo in the same “rust” package that provides rustc.
Did you know that there’s no g++ package in archlinux either? it’s bundled in the gcc package… do you think that means that there’s no widespread availability of g++ in Archlinux?
Debian does have a dedicated rustc package, is writting “rustc only programs” more widespread in Debian?
I’m not saying it stops people from using rustc only. I think there is a huge misunderstanding here. Currently, its just highly specialized use cases where they have to use rustc only without even the standard library (I think the Linux Kernel doesn’t use the stdlib). What I say is, that the current infrastructure and distributions doesn’t treat rustc+stdlib as its own thing, that nobody will target it and everyone assumes Cargo.
In example there is no rustc+stdlib compiler as a package by distributions. This should be a standard package by all distributions in my opinion, just like we have C compilers doing the most basic thing. From packaging standpoint. This would encourage people to do such projects, as if you just require basic tools that are not always installed, but can be assumed to easily install. It also should have less dependencies than Cargo and rustfmt in example, or even rustup.
I think the g++ comparison doesn’t hold here, because it’s not the only way of using the language. Rust on the other hand has only one other way of doing this, it’s the dependency heavy and full package with cargo and the rest, even usually downloading dependencies and and so on. It’s a full package manager. If g++ was the only alternative to such a system, I think it would have more widespread adoption.
Well it needs to be a standard in most common distributions. No one wants to rely on something that is found in one distribution only.
That’s just what you believe, not something you can prove. In fact, if anything, it’s easier to assume rustc is present than it is to assume cargo is present, because cargo needs rustc, but rustc does not need cargo… so if you really were looking for the most universal cross-distro assumption, then it would make more sense to assume rustc (which has to be installed to have cargo anyway) than to assume cargo.
I’m not sure what do you even mean by “use”… are you saying if I find a way to “use” rust without achlinux rust package then it’s ok for it to bundle cargo?
A lot of things aren’t standard across distros. The way the 32bit variants of gcc are packaged between distros is also not a universal standard… do you think nobody wants to rely on it only because you need to check what name for the package corresponds to your distro?
How many distros do you need to follow the same approach to consider it “standard”?
Debian doing this means that essentially all apt-get based distros follow the same approach of separating rust and cargo (Ubuntu, Mint, and all the variations).
Also in Fedora / RHEL / AlmaLinux / Rocky Linux… “rust” contains rustc, cargo is split to its separate “cargo” subpackage.
Also Alpine Linux, cargo is a separate package from rust.
Void Linux, also cargo separate package from rust,
NixOS, has pkgs.rustc and pkgs.cargo as separate derivations.
No. Because if there was rustc+stdlib as a package to install, then we could make the argument. But if Cargo is the only package available with rustc, then there is no point in making this argument. In most distributions there aren’t rustc+stdlib only package.
The point is, not having Cargo and all the other rest of the systems to install when installing rustc. Sorry, but am I talking Chinese? (and yes, I get impatient.)
I explained it following that quote. I’m trying. You bring g++ as an argument why its not widespread adopted. Because g++ is not the only alternative to something like a package manager like Cargo. Nobody “needs” g++. There are many ways of compiling Cpp, even without using a package manager. So nobody has to use g++ to avoid something like Cargo and all the other stuff.
The package is actually called “rust”, not Cargo, “rust” is the only package available with rustc (and cargo): https://archlinux.org/packages/extra/x86_64/rust/files/
I absolutely can make the argument I made. The argument I made was that you need to have rustc to use cargo, because cargo uses rustc, and this means that assuming rustc exists is a lot safer than assuming that cargo exists… because if cargo is installed then it follows that rustc must be installed too. And this is true in all distros, not specific to Archlinux, which is why it’s a more universal distro-wide assumption.
If rustc is not installed, cargo will give an error when trying to compile rust. So one can assume that rustc is there whenever cargo is there. But you can’t say the same thing the other way around, not everywhere.
You can also have rustc without using a package manager. Some places also recommend installing rustup instead of rust through the package manager. Cargo is the officially recommended manager for rust packages, so naturally is very popular. I still don’t think the packaging in archlinux should be attributed the merit of the popularity of cargo for rust development…
It’s not about the popularity…
You also said earlier that it’s not about it stopping anyone from using rustc only.
So honestly, I don’t understand what is the problem. People can (and do) use rustc without cargo, and make projects with zero dependency… so I don’t get why you say that “nobody” would want to do that. There’s people doing it. Like the Linux devs.
The only thing I can think of is that you think that “most” people don’t want to do that… but then that would mean you are talking about popularity (ie. what the mainstream people do, what is the most widespread).
What? I’m actually saying the opposite, not that nobody wants to do it. Otherwise why would I suggest it. I am saying its not widespread adopted, and you cannot expect OTHERS to have rustc+stdlib to be installed on the system, like a standard Linux tool. People use it for their specific use cases, like Linux, but its not something you can expect on other machines.
Imagine rustc+stdlibs were available by default like Python, ideally installed on default. Maybe not installed on default, depending on the system you are, but everyone should expect this package with the stdlib on be available.
You literally said “nobody will target it and everyone assumes Cargo.”.
We know that there’s people who target it… so the only way I can interpret “nobody will target it” is that you are saying that people are generally not interested in using rustc on itself because cargo is there.
And yet, what I’m saying is that there’s people that are actually interested still in doing that, and they actually do it, regardless of whether cargo is there or not. Cargo being there is not an obstacle for them.
Sure, those people might be a minority, but you said that it’s not about popularity… so what is it about?
Even gcc is not preinstalled in most distros. The reason python is preinstalled is because it’s an interpreter, so it’s required at runtime, you need it to run the programs. If python was a compiler then it wouldn’t be preinstalled by default since the end users wouldn’t need it.
And that’s completely unrelated to cargo… one could argue that there’s just as much reason to include cargo preinstalled too if you were to pre-install rustc.
Maybe the problem is that you think that rustc is an interpreter? it’s not, it’s a compiler, you don’t need others to have rustc, they can run programs made with rust without needing to have rust installed in their system (it’s not something you “target” in that sense). That’s not the case for python, so that’s why python comes already installed, specially given that many distros depend on python for some config tools.