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.
I think one of the reasons why this is not done is because Rust deliberately works against using precompiled dependencies.
Unlike traditional C compilers, for the Rust compiler trying to keep ABI compatibility is a non-goal… the Rust compiler retains the freedom to aggressively optimize how data is laid out in memory and how functions are called. Binaries generated by one version (or particular settings) might not work in the next… making it much harder to work the way we work with C libraries.
This means managing dependencies between rust libraries is a lot more involved… since you are essentially recompiling the library along with your project, so you need a way to download, not just the library headers as you would with C, but its entire sourcecode.
So your approach might work if you just want to use a little bit of Rust included in a C project… or if your Rust project is small and does not have many dependencies… but the moment you start relying in more and more components and the dependency tree grows enough, it’ll become hard to manage.
Rust? You mean the developers of Rust? That’s not a decision to make by them. Also the Linux distributions include many precompiled binaries. So I don’t see what this point is.
My suggestion is not to download and use the libraries from third party repositories. The idea is to have all libraries in the repository of the project itself (such as Git) or the standard library in the package manager, matching the rustc compiler that is also packaged there. In example if Debian would include such packages, then this would become quasi industry standard version everyone can target. Basically the same thing that happens with Python in example. So it stays ABI compatible.
I am not suggesting for full cargo replacement, and suggest not to depend on the registry of those. And I actually believe we will get to that point at some point when gccrs is ready (GNU Compiler Collection including Rust).
I’m talking about the compiler. ABI compatibility is a non-goal in the compiler itself. You’d need to make a new version of rustc that somehow manages to handle generics/templates in an ABI-compatible way and handles optimizations with more care.
What distribution includes precompiled libraries (not user programs) in Rust?
If you install a C library like libcurl via apt install, you get a precompiled .so file. If you install a Rust library like librust-serde-dev via Debian’s package manager, you do not get a precompiled binary. If you inspect that package, it is literally just a zip file of raw .rs source code that gets dumped into /usr/share/cargo/registry/.
Putting all libraries into the git repo or using OS package managers to essentially maintain a registry just like cargo’s can work… but it’s duplicated effort in keeping everything well managed, updated, and free of vulnerabilities.
If you use your distro’s package manager, depending on which one you use, it might not offer as much flexibility (like how if you need 2 different versions of the same library in Debian, you’ll need workarounds if the maintainers have not created separate versions for it) or be as build-aware as an integrated build tool would. Some libraries might only need a particular dependency when a particular feature flag is enabled… a package manager most likely would have to download all dependencies of every library you want to use since it does not know what build options you are gonna use when you install the package.
That’s exactly what is to be avoided. I’m not suggesting a dependency heavy program to compile. Someone making a program without Cargo wouldn’t probably make lot of dependencies, and if any, they are all included in its own repository.
I thought you was talking about user programs. About the libraries, that’s what I’m suggesting to include too, alongside with the correct rustc compiler. Maybe even the version which the Linux developers use, so that would be the standard one everyone can target.
ABI-compatibility is only relevant when we talk about binary libraries… if I were talking about user programs then it would be the API what matters, not the ABI.
“a lot” of dependencies is a fuzzy line to cross… most projects start small, then as they grow big they might modularize, attempt to de-duplicate efforts, etc. So I feel for big Rust projects you’d end up essentially duplicating what cargo is already designed to handle.
As I said before: your approach might work if you just want to use some Rust included in a C project (like the kernel is doing)… or if your Rust project is small and does not have many dependencies… but the moment you start relying in more and more components and the dependency tree grows enough, it’ll become hard to manage.
But that is the suggestion here, to not rely on many dependencies. And currently this is an odd thing to do in Rust, because there is no other support or eco system to support this kind of building. Yes, if you want rely on many dependencies and crates io, then it makes no sense to go that route I suggest.
But this would only work widespread if distributions would adopt this kind of packaging and providing a stable environment. Imagine Python wasn’t installed by default on Linux, how would anyone think of relying on it? I know it’s technically not the same thing, but I’m making a comparison for having it in the distributions repository (or installed by default), not how the language works.
Unlike Python or C++, Rust’s standard library is intentionally kept tiny. It does not include regular expressions, random number generation, JSON parsing, or an HTTP client.
To do modern programming tasks the way you can with Python, you will most likely have to use external libraries. Choosing not to rely on dependencies in Rust doesn’t make your project simpler, it just forces you to write more things from scratch.
Exactly and that’s one of the advantages to not rely on dependencies. Not every application need those packages. Otherwise they would be included in the standard library. This would encourage people to build software that is self confined, even if it is harder to do. And not every type of tool needs to be this, this is only meant for projects where it makes sense.
You guys need to stop thinking that I’m suggesting a complete replacement of cargo and crates io. It doesn’t need to be one or the other, we can have both solutions and choose which ever works best for the project or you.
The reason they are not included is not to prevent including them when not needed (the Rust compiler makes a good job at cleaning up dead code, so even if they were part of the standard library, they would not be in the binary anyway), but because it allows iterating, optimizing, and patching security flaws in those libraries much faster than the release cycle of the compiler itself.
And yeah, that’s also what cargo’s goal is, only pull what you need in your dependency graph. But what do you mean by self-confined? I hope you don’t mean writing everything from scratch because not only would that be duplicating efforts but it also can potentially lead to security gaps…
If by “self-confined” you mean “vendoring”, then that does not necessarily mean you have fewer dependencies, it just means you commit the raw source code of your entire dependency tree directly into your own Git repository instead of fetching it from crates.io during the build. I don’t think you get much benefit from doing that manually, and it just adds maintenance burden.