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.



Only if it is packaged like python on arch.
I never had so many problems with anything else on linux but pip, npm, and cargo.
That’s python’s problem. You have no idea how much of a life improvement simply using
uv+ an older python version (uv natively supports this) is.I don’t think that a package manager and cargo should be included by default, if Rust compiler and the standard library was installed. One can use the compiler
rustcwithout Cargo. Also there are works to create a new independent compiler for the GCC framework, but that takes forever it seems.That would off course mean that many projects cannot be compiled without a package manager and all their dependencies. But it would make it like Python (and C compilers) be possible to compile individual files. That could make it to a standard way of distributing simple projects which does not require any external libraries at all. This could encourage such projects too, which isn’t a bad thing at all to me.
And it just occurred to me that probably some Rust libraries could be installed as a separate Archlinux package too, so you don’t need external package manager. Haskell in example does that, and off course Python packages.
Thats what I mean by “like python on arch”