Good.

So the tool YOU chose is NOT:

• standalone at the project level ✅
• standalone at the repo level ✅
• standalone at the source level (trivially shown with the libsystemd-shared.so dep without requiring looking further) ✅
• standalone/fully independent at the runtime level ✅

This and the sibling sub-thread where I mentioned presets show with actual facts how the systemd forced hegemony actually works, where it's not just a simple case of "they just have some stand-alone cli tools under their umbrella bro".

The project itself wouldn't try to (clumsily) dispute this either, since it's at the core of what they consider a selling point; interface unification and deeper integration with the system.

How ironic!

Now post the output:

ls -ld /run/systemd/io.*

First one on the list.

% readelf -d /usr/bin/bootctl | rg -r '$1' '.*NEEDED.*\[(.*)\]'
libsystemd-shared-262-1.so
libgcc_s.so.1
libc.so.6

Share the content of the file 90-systemd.preset from your system.

Let's play a game. Pick a "separate utility" from the list above, and let's see if you know what you're talking about, or just waffling.

Your "separate utilities developed under systemd umbrella" claim was simply false.

Your attempted retort was even more funny, since many coreutils implementations can actually literally be built into a single binary with many symlinks, with dispatch done based on arg0. It's even the preferred packaging option.

There are a lot of interdependencies within those source trees. Nothing is self-contained. So the "itz just monorepo bro" is also false.

they also overreaching and that’s THE point?

You literally just listed multiple projects 🤭, where their collective surface is also nowhere close the the systemd forced hegemony. Maybe they should all unite and join the "umbrella".

No, they aren't. These are the binaries from THE systemd package , built from systemd releases, from THE systemd repo.

A single source tree looking like an "umbrella", and an overreaching one at that, is THE point.

I’m the type of person who wants more systemd in my computer

Hear hear. A couple hundred more should do the trick.

bootctl
busctl
coredumpctl
homectl
hostnamectl
importctl
installkernel -> kernel-install
journalctl
kernel-install
localectl
loginctl
machinectl
mount.ddi -> systemd-dissect
mount.mstack -> systemd-mstack
mount.storage -> storagectl
networkctl
oomctl
portablectl
resolvectl
run0 -> systemd-run
storagectl
systemctl
systemd-ac-power
systemd-analyze
systemd-ask-password
systemd-cat
systemd-cgls
systemd-cgtop
systemd-confext -> systemd-sysext
systemd-creds
systemd-cryptenroll
systemd-cryptsetup
systemd-delta
systemd-detect-virt
systemd-dissect
systemd-escape
systemd-firstboot
systemd-home-fallback-shell -> homectl
systemd-hwdb
systemd-id128
systemd-inhibit
systemd-machine-id-setup
systemd-mount
systemd-mstack
systemd-mute-console
systemd-notify
systemd-nspawn
systemd-path
systemd-pty-forward
systemd-repart
systemd-resolve -> resolvectl
systemd-run
systemd-socket-activate
systemd-stdio-bridge
systemd-sysext
systemd-sysinstall
systemd-sysusers
systemd-tmpfiles
systemd-tty-ask-password-agent
systemd-umount -> systemd-mount
systemd-vmspawn
systemd-vpick
timedatectl
udevadm
updatectl
userdbctl
varlinkctl

A PR fixing the issue has already been submitted (which surfaced another issue, but it doesn't concern stable).

People likening this to the issue behind cve-rs (which is blocked on a major rework) are clueless, which happens to be par for the course regarding anything Rust. So no surprises there.

The language wouldn't have lost much without tuples actually. But they do at least have direct pattern destructuring utility. Anonymous enums don't.

They also don't pose potential future awkwardness if/when variant types become a thing.

A language feature is not needed because macros exist.

I would even argue that perhaps the most important role macros play is blocking adding endless language features 😉

To add to the other answers. Usually, the easiest way to answer such questions is to click on source. Then in this case, you would immediately see this comment:

// SAFETY: A `Vec` always has a non-null pointer.

Remember that this has no runtime cost and is fully type-safe.

For the sake of maximal accuracy, enum size overhead can become relevant sometimes. But a work-around exists (boxing the huge variant), and with or without boxing, the performance would still beat whatever other languages have to offer.

Otherwise, good post (I would have to say that since it mostly rehashes points I made in previous comments 😉).

Who is even the target audience of this post? Beginners (which included all of us once) ask for all sorts of things. But these features didn't happen in Rust for a reason.

Named parameters are not needed in the age of LSP hints, where this exists as an editor feature (including (neo)vim).

But if you really want named parameters AND optionals/defaults, rust always allowed the args struct pattern:

struct Args<'a> {
  a: &'a str,
  b: u64,
  c: Option<u64>,
}

impl<'a> Default for Args<'a> {
  fn default() -> Self {
    Self {
       a: "hi", // default
       b: 3, // default
       c: None, // optional default
    }
  }
}

takes_args(Args{a: "not hi", ..Args::default()})

The builder pattern is more about valid initialization, but does interact with the arg struct pattern when you have non-default (forced) arguments, although even then, you can not use it by having:

struct Args<'a> {
  forced_arg1: &'a str,
  forced_arg2: u8,
  defaults: DefaultArgs, // implements Default
}

So mentioning the builder pattern is out of place.

Overloading is not used because we have traits (and the sound subset of specialization for when that's needed).

So all in all, those "features" didn't make it to Rust not because of the backlog, or for simplicity's sake, but because idiomatic Rust (and even modern tooling in general, a la LSP) have alternatives that give you what you want and more.

Everything mentioned above should be known by anyone who knew Rust for more than a month.

The +nightly syntax is a rustup proxy feature, so a distro-packaged cargo won’t even parse it. Nightly is a different compiler every day.

export RUSTC_BOOTSTRAP=1 and you wouldn't need rustup or nightly. It will work with your stable distro package.

clap = "4" and anyhow = "1" are ranges, and there’s no Cargo.lock.

you can do clap = "=4.x.x", ditto for all deps, direct and indirect.

Nightly is a different compiler every day.

Nothing about that script is fixed except its text.

Is nix finished free-standing software?

but maybe “safe enough”.

It won't be. Bjarne doesn't want any real workable safety to be added. And that's for the best because it's a shit language. And falling out of favor, especially for new projects, is the best outcome.

Getting ahead of the curve regarding potential future legislations/regulations around unsafe languages, which may introduce contract conditions, liabilities...etc (See 2:30-4:30 of this talk for an overview).

If they listened to the calls describing this move as premature, and it arguably was, they could have gotten strapped for time later.

An implementation in a good safe fast modern language that developers actually enjoy has other tangible benefits of course. But if people want the "corpo reason", the above should provide an answer.

Thank you for your detailed reply.

Focusing on x86_64 (and linux), can you expand on what's missing to reach ABI parity?

And somewhat relatedly, are you leaning towards publishing an std component built with the backend or not?

I've been watching the number of failing UI tests shrinking fast with excitement.

Would you expect the backend to be fully ready by the end of the year? Or are there big/complicated blockers that remain, or LLVM-isms that make full or nearly full parity impossible?

Relatedly, cranelift cg early struggles had to do, in part, with intrinsics support. I remember talk of somehow solving the problem systemically and not having to implement all of them in the backends directly? Where did things end up regarding that, and how does this backend deal with this problem?

And finally, using evcxr with :timing enabled, and switching between backends with :codegen_backend, I notice that gcc is the slowest when it comes to compile time. Is that because more IR is given to gcc to generate from, or is gcc/libgccjit itself slower now?

Regarding the rust-glancer announcement itself, I hope the author is aware that lspmux (formerly ra-multiplex) exists, and zram. If lspmux didn't exist, then yes, editor restarts would have been annoying, but that has been a solved problem for a few years already.

Also, I'm not sure hitting SSD storage too much is good strategy in general, but maybe that's an overstated concern.

Otherwise, yes, RA could do better in memory consumption and some other aspects. And yes, the LSP protocol itself is not ideal.

In any case, introducing new ideas and approaches is always good, especially when there is no "fragmentation" concerns, which I think is the case here.