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.

all 33 comments

sorted by: hot top controversial new old
[–] 1 point 2 hours ago

I want to like rust but it's just so slow to compile and loves to OOM during compilation. Idk maybe it's fine without the dependency creep.

  • source
  • [–] 4 points 8 hours ago* (1 child)

    Is Rust support in GCC ready yet? It's worrying that Linux is now becoming dependent on the massive LLVM project and the Rust reference implementation (also presumably complex?).

  • source
  • hideshow 1 child comment
  • [–] 1 point 5 hours ago

    To not depend on LLVM, you only need a non-LLVM code generator (i.e. replacing the LLVM IR generation step with another representation). A full fledged implementation in GCC is not strictly necessary. The "presumably complex" Rust implementation is actually modular like that. Multiple code generators already exist.

    rustc_codegen_gcc is progressing nicely. Priority is given to targets with no LLVM support whatsoever (architectures you probably never heard of) and x86_64. Using the latter as a target could become fully usable within months (90%+ of the work is already done).

    Another code generator that exists and is even more well supported is cranelift, but that strictly targets fast compilation (at the expense of slower binaries), so it's mostly useful for faster development workflows.

    There are even code generators that generate C code, which manage to turn the full reference rust compiler itself to C 😉

    The implement-Rust-in-GCC project is called gccrs, but that's years away from reaching a fully usable state.

  • source
  • parent
  • [–] -4 points 5 hours ago

    Systemd keeps finding ways to be worse

  • source
  • [–] 27 points 13 hours ago (21 children)

    At this point, I think Rust should be installed and available on most distributions. Its just part of Linux now, like C and Python. Maybe this will be, once GCC can compile Rust too.

  • source
  • hideshow 21 child comments
  • [–] 10 points 11 hours ago (16 children)

    Firefox and Python's cryptography toolchain have a build dependency on Rust, which are two packages that virtually all Linux distributions have packaged. So, some version of the Rust compiler is going to be available on virtually all Linux distributions.

    There's no real reason to have the Rust compiler installed on non-dev systems, as you don't need it for running Rust programs (although I kind of assume you know this).
    But yeah, it seems to be possible to dynamically link the standard library into Rust programs, so Linux distros could try to share that between them, and then it would effectively be installed by default.

  • source
  • parent
  • hideshow 16 child comments
  • [–] 2 points 11 hours ago* (15 children)

    You don't need to be a developer in order to compile little programs. Like in C it is totally normal to do so, without being a programmer. Just use a make command on a Github project and install it manually. I would put Rust at the same level as C, so yes, most people wouldn't have it installed or need it. But the compile rustc should be packaged by all distributions and it should be part of a meta package for basic development tools (also used by non developers).

    In a way that any program could assume everyone on Linux is able to compile with a basic Makefile, like we do this with C in example (if compiler tools are installed). I didn't even think about dynamically linked standard library.

  • source
  • parent
  • hideshow 15 child comments
  • [–] 2 points 5 hours ago (5 children)

    Fair enough, I guess.
    Personally, I don't really see the point, because there's hardly any projects that can be compiled with just rustc.

    I mean, cargo is actually surprisingly useful for normal users, because there's a decent chance you can compile medium-sized Rust projects without having to jump through endless hoops.

    But yeah, at that point, you're adding a nontrivial number of megabytes to user installations for something they might not use. I would guess that even just rustc is larger than gcc and clang, since it implements more sophisticated logic...

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 5 hours ago (4 children)

    Personally, I don’t really see the point, because there’s hardly any projects that can be compiled with just rustc.

    Because having rustc as a standard tool is not there yet. Off course most don't expect someone to have rustc only on their computer. I love Cargo, don't get me wrong. But I think there could be a rise of non Cargo and library dependency projects in future, if the infrastructure (meaning rustc and the standard library can be expected as standard dependency) is available once.

    Just like not every little project of C requires additional dependency trackers. One could download a project from Git and build it with rustc+make and only the dependencies available in your repository. One of the major issues with the public cratesio is, that not everyone wants to depend on it. In example Linux or other projects don't use it (as far as I know). So there might be use cases. Just like we use Python and Haskell without additional libraries, or only install them from our systems repository.

    Maybe it shouldn't be installed by default. But having an infastructure with basic system packages to install only "Rust" (rustc+stdlib), no cargo, no rustfmt, no rustup. Maybe this will be available once gcc-rust is ready.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 0 points 5 hours ago (3 children)

    I think you're clearly clueless and should stop opining on matters you know nothing about.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 4 hours ago (2 children)

    I think you don't know what you are talking about.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 0 points 3 hours ago* (1 child)
    • You're clueless about how cargo itself wraps/calls rustc. And how other build systems are doing the same, including the one literally mentioned in OP. "Because having rustc as a standard tool is not there yet" is a completely meaningless nonsensical sentence. Neither is rustc lacking in any way, nor is cargo imposes any sort of hard requirement on itself.
    • You're clueless about how cargo works. How it natively supports both vendoring (with a single command) and multiple other ways of source replacement.
    • You're clueless about the fact that rust statically links std by default, and the fact that the ABI is not stable between major rust versions which is a deliberate choice. And thus, the attempt to draw parallels with "C repo and make" is yet another indicator of your cluelessness.

    There is more. But I don't have the time untangle the webs of cluelessness in your comments.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 10 hours ago* (last edited 9 hours ago) (8 children)

    Well, like with everything now, rust is much more than the compiler, and will need the entire toolchain, so you’d want rustup or pinned toolchain packages so you had access to cargo and the full ecosystem.

  • source
  • parent
  • hideshow 8 child comments
  • [–] 1 point 5 hours ago

    All major distributions ship their own compiled rustc/cargo packages already, and they've done so for years.

    And putting rust projects using nightly features aside*, stable rust version updates are much less disruptive than major GCC or clang updates. Breakages are rare, known in advance, and communicated to upstreams before hand (look up "crater" if you want to learn more).

    * Not sure if distros package, or need to package any such packages, but I didn't do any surveys on the subject.

  • source
  • parent
  • [–] 1 point 9 hours ago (6 children)

    Rust has a compiler rustc which does not need the entire toolchain like cargo and eco system. It can be used like Python and C with standard libraries only and adding libraries manually without package manager.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 1 point 4 hours ago* (5 children)

    yes, but to manually build packages against libraries yourself would be a nightmare of tooling without cargo.

    It's no different than every base-devel and similar package requiring cmake because sure, you could manually run the c/c++ compilers and linkers yourself against every single file, passing in the flags yourself, but that would take an obscene amount of time to manually build and run every compiler command yourself

    https://wiki.debian.org/Rust

    Debian builds it's own local cargo registry by default. If your distro provides "pinned versions" like I said, you won't need rustup, but you'll still need cargo to do anything beyond a tiny project with no imports, unless you plan on writing async/http/encryption libraries all yourself.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 4 hours ago (4 children)

    It would be similar to how we build C with make or any other language, using a Makefile in example. In example if the project contains all dependencies in the Git repository already and does not need to download extra dependencies. The Makefile and configuration would handle all of that. Or for projects that do not require dependencies, it would be quite simple compiling.

    Debian uses cargo, which is what I would avoid. Cargo is a package manager, that is the exact thing I'm trying to avoid here with the suggestion. I think of dependencies integrated into the system package manager (pacman in example). Debian needs to do this cargo registry, because there is no other infastructure.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 0 points 4 hours ago (3 children)

    Cargo combines the features of a package manager with a build system. You can just used the build system without touching the package manager, which is what Debian and other distros do. But I mean sure, for C there's make cmake automake ninja meson so why not make another for rust

  • source
  • parent
  • hideshow 3 child comments
  • [–] -1 points 4 hours ago (2 children)

    Nobody is talking about making another make tool for Rust.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 hour ago* (1 child)

    ok a makefile is basically a script runner like this. the c/c++ compiler doesn't touch the makefile, that's a separate tool

    edit : main.o kbd.o command.o display.o \
           insert.o search.o files.o utils.o
            cc -o edit main.o kbd.o command.o display.o \
                       insert.o search.o files.o utils.o
    
    main.o : main.c defs.h
            cc -c main.c
    kbd.o : kbd.c defs.h command.h
            cc -c kbd.c
    command.o : command.c defs.h command.h
            cc -c command.c
    display.o : display.c defs.h buffer.h
            cc -c display.c
    insert.o : insert.c defs.h buffer.h
            cc -c insert.c
    search.o : search.c defs.h buffer.h
            cc -c search.c
    files.o : files.c defs.h buffer.h command.h
            cc -c files.c
    utils.o : utils.c defs.h
            cc -c utils.c
    clean :
            rm edit main.o kbd.o command.o display.o \
               insert.o search.o files.o utils.o
    

    for a rust program, you might have a cargo.toml like

    [package]
    name = "jsontool"
    version = "0.1.0"
    edition = "2021"
    
    [dependencies]
    anyhow = "1"
    clap = { version = "4", features = ["derive"] }
    serde = { version = "1", features = ["derive"] }
    serde_json = "1"
    
    [profile.release]
    lto = true```
    
    and .cargo/config.toml like (for the local distro config, no internet packages)
    
    

    [source.crates-io] replace-with = "distro"

    [source.distro] directory = "/usr/share/cargo/registry" # or: registry = "sparse+https://crates.internal.example/index/"

    [net] offline = true

    
    If you wanted that same functionality from a makefile for rust it would be something like
    
    

    Makefile: build jsontool with plain rustc, no cargo.

    RUSTC ?= rustc REG := /usr/share/cargo/registry OUT := $(abspath build) HOST := $(shell $(RUSTC) -vV | sed -n 's/^host: //p') FLAGS := -C opt-level=3 --cap-lints=allow -L dependency=$(OUT) --out-dir $(OUT) ext = $(foreach c,$(1),--extern $(c)=$(OUT)/lib$(c).rlib) extpm = $(foreach c,$(1),--extern $(c)=$(OUT)/lib$(c).so)

    Pinned by hand. Cargo.lock does this for you; here, a distro upgrade

    renames these directories and the build breaks.

    UNICODE_IDENT := $(REG)/unicode-ident-1.0.13 PROC_MACRO2 := $(REG)/proc-macro2-1.0.89 QUOTE := $(REG)/quote-1.0.37 SYN := $(REG)/syn-2.0.85 SERDE_DERIVE := $(REG)/serde_derive-1.0.213

    ... ~20 more ...

    ---- 1. Plain library crate ----

    Edition, crate name (hyphens -> underscores), and features all come from

    reading each crate's Cargo.toml yourself.

    $(OUT)/libunicode_ident.rlib: $(RUSTC) --edition=2018 --crate-type=lib --crate-name unicode_ident
    $(FLAGS) $(UNICODE_IDENT)/src/lib.rs

    ---- 2. Crate with a build.rs: compile it, run it with the env vars cargo

    would set, then scrape its stdout for cfg flags ----

    $(OUT)/proc_macro2.cfg: mkdir -p $(OUT)/bs-pm2 $(RUSTC) --edition=2021 --crate-type=bin $(PROC_MACRO2)/build.rs
    -o $(OUT)/bs-pm2/build-script cd $(PROC_MACRO2) && env OUT_DIR=$(OUT)/bs-pm2 RUSTC=$(RUSTC)
    TARGET=$(HOST) HOST=$(HOST) PROFILE=release OPT_LEVEL=3
    CARGO_MANIFEST_DIR=$(PROC_MACRO2) CARGO_PKG_VERSION=1.0.89
    CARGO_FEATURE_DEFAULT=1 CARGO_FEATURE_PROC_MACRO=1
    CARGO_CFG_TARGET_OS=linux CARGO_CFG_TARGET_ARCH=x86_64
    $(OUT)/bs-pm2/build-script
    | sed -n 's/^cargo::?rustc-cfg=(.*)/--cfg=\1/p' > $@

    $(OUT)/libproc_macro2.rlib: $(OUT)/proc_macro2.cfg $(OUT)/libunicode_ident.rlib $(RUSTC) --edition=2021 --crate-type=lib --crate-name proc_macro2 $(FLAGS)
    --cfg 'feature="default"' --cfg 'feature="proc-macro"'
    $$(cat $<) $(call ext,unicode_ident) $(PROC_MACRO2)/src/lib.rs

    ---- 3. Proc-macro crate: different crate type, must be built for the

    HOST (matters when cross-compiling), linked as a .so ----

    syn's feature list must be the UNION of what serde_derive AND clap_derive

    need. Cargo computes this (feature unification); here you work it out by hand.

    $(OUT)/libserde_derive.so: $(OUT)/libproc_macro2.rlib $(OUT)/libquote.rlib $(OUT)/libsyn.rlib $(RUSTC) --edition=2015 --crate-type=proc-macro --crate-name serde_derive
    $(FLAGS) --cfg 'feature="default"'
    $(call ext,proc_macro2 quote syn) $(SERDE_DERIVE)/src/lib.rs

    ... ~20 more rules like the above (serde, serde_json, anyhow, and

    clap_* each have their own quirks, and several have build.rs) ...

    ---- Finally, your program ----

    clap's derive expands to env!("CARGO_PKG_VERSION"), so you fake cargo's env.

    Source files are listed by hand (or you wire up --emit=dep-info .d files).

    build/jsontool: src/main.rs src/cli.rs src/convert.rs $(ALL_DEPS) CARGO_PKG_NAME=jsontool CARGO_PKG_VERSION=0.1.0
    $(RUSTC) --edition=2021 --crate-type=bin --crate-name jsontool $(FLAGS)
    $(call ext,anyhow clap serde serde_json) src/main.rs

    Still to write: test (rustc --test + every --extern again), doc-tests

    (rustdoc --test), debug vs release flags, clean, install...

    
    So are you proposing GNU style makefiles for rust then? You say not another tool, just use the compiler. Either you type those commands yourself, you type them into a make style build script, or cargo or **another tool** automates them.
    
  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 11 minutes ago

    No, I am not talking about the same functionality and without using cargo. I am talking about using rustc to compile individual Rust programs.

    $ ls -1
    hello.rs
    main.rs
    

    main.rs:

    mod hello;
    
    fn main() {
        hello::print_hello();
    }
    

    hello.rs:

    pub fn print_hello() {
        println!("Hello World!");
    }
    
    $ rustc --target helloworld main.rs
    $ ./helloworld
    Hello World!
    

    No Cargo, no toml, no registry.

  • source
  • parent
  • [–] 3 points 12 hours ago (3 children)

    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.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 5 points 12 hours ago* (1 child)

    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 rustc without 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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 12 hours ago (3 children)

    Uh, why is Systemd stuff dependent on any specific language, except for (C) kernel calls?

  • source
  • hideshow 3 child comments
  • [–] 13 points 11 hours ago (1 child)

    This is about the official systemd repository. They use a mono-repo-approach, where all the official components are in one repository and use the same build system, so adding a second language into that is a bigger hurdle.

    If you develop a third-party tool that somehow hooks into systemd, then you can use whatever language you want.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 12 hours ago (2 children)

    Those are some wild restrictions. You're using the syntax and presumably compiler (rustc), but almost nothing else from Rust...

  • source
  • hideshow 2 child comments
  • [–] 2 points 5 hours ago (1 child)

    You’re using the syntax and presumably compiler (rustc)

    but almost nothing else from Rust

    waat 😲

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 51 minutes ago

    Yeah, in detail, they use or can use:

    • Syntax + tooling for it, like editors, linters, formatters
    • Compiler (rustc, which enforces memory+thread-safety for the parts not implemented in C)

    They've replaced:

    • std library → core library + their own implementation of types that do memory allocations, so in particular dynamically-sized types like lists and strings
    • Cargo → their own Meson definitions

    What they don't use:

    • the library ecosystem of Rust (although apparently they've got own implementations of "logging, command-line argument handling, event processing, and error management")

    It does sound like someone thought about this stuff, but yeah, as a Rust dev, it also sounds like I would struggle...

  • source
  • parent