[defanor]

With C, I comfortably rely on the distribution's package management, even though it is not a rolling release or anything of that sort (Debian stable). Actually not sure how that would be the case with C, if one does not try to make things incompatible intentionally: the language and the major libraries' APIs are pretty stable there.

With Haskell (used for most tasks at work) I get the tools (GHC and Cabal) and most of the dependencies from Debian stable repositories, though loading missing ones from Hackage (but slowly moving towards not relying on Hackage at all). And keeping sources compatible with package versions from Debian repositories from version 9 to 12 (4 major versions, 6 years apart). With shell scripts, sticking to POSIX; with SQL ones, avoiding extensions and also doing fine.

[duped]

We have very different experiences, I haven't worked on a production C/C++ project in the last decade that didn't vendor dependencies somehow. Debian stable is especially unreliable. In fact I can't think of a time I haven't had issues when working on a team greater than 1 or shipping builds because distro packaged libraries aren't reliable.

Also, why is it immature for Rust to ship a toolchain and package manager through a sidechannel, but not Haskell?

[defanor]

> why is it immature for Rust to ship a toolchain and package manager through a sidechannel, but not Haskell?

Haskell also feels less mature to me than C, with fewer POSIX functions being readily available, but as mentioned above, with Haskell (in my experience; the experiences indeed seem to differ) it is "one or two dependencies have to be pulled from Hackage across multiple projects and system versions", while in Rust it is rather "I failed to pull common logging and argument parsing dependencies on a single up-to-date stable system, and apparently one is supposed to install and update its compiler, package manager, and libraries separately from the rest of the system". Though some use ghcup or Stack, which also aim working without a system package manager, but at least a system package manager is a viable option.

[duped]

You didn't have an up to date system if you use Debian stable. They do not keep their packages up to date.

It just seems weird to blame Rust for a problem you had with your package manager, when every modern ecosystem I can think of eschews distro package managers because of these problems.

[defanor]

This appears to highlight differences in our perspectives: while working with (and supporting software for) 4 most recent major Debian releases, the latest stable one feels like a fresh one to me, especially if it is updated to the latest available package versions (and minor release). The packages are not supposed to be cutting edge there, but "stable".

I also don't mean to blame Rust's ecosystem (let alone the language itself) in the sense of complaining about it, though talking about this feels that way, and I thought it might be useful to clarify: it appears to aim less "stable" and more "cutting edge" (or "experimental") versions and practices than "stable" system distributions do, and than more mature ecosystems tend to do. Likewise, I wouldn't call having a slightly older compiler version in system repositories a problem with package manager: this is a useful approach for getting a stable system, relatively well-tested and with predictable changes. Not every system has to be this way, but in some cases it is useful, some people (myself included) generally prefer those. And unfortunately those fail to play together smoothly at the moment, but I view it as an issue arising between those and their approaches, not as a problem of one of those.

[duped]

Let me ask a more foundational question then, what is the virtue of a "stable" system?

In my mind, it's that updating a dependency doesn't break existing installations, or knowing that an existing install isn't going to get borked by an update.

And this is not something that is applicable to ecosystems like Rust, where it's not really possible to break a Rust program because another Rust program needs a newer version of the same dependency that happens to be incompatible with the older version. In fact, you can compile one Rust program that links against multiple versions of the same dependency at incompatible versions without issue.

So the entire notion of the Debian model of package management doesn't really apply to Rust, and there's not any benefit to keeping an older version of the toolchain around. There are only negatives.

And Rust has strong stability guarantees. A newer toolchain will not break compiles of older code. Nor will Cargo's cache break compiles with an existing lockfile because another package needed different incompatible versions of the same dependency. It's designed to be stable from first principles, in a way that C and C++ builds are not.

This is kind of why you're only going to have a bad time if you want to use the system package manager to manage your Rust packages. It's not built for the same problem domain, and over constrained for the design space.

[defanor]

> Let me ask a more foundational question then, what is the virtue of a "stable" system?

Not introducing breaking changes too often (so that you have to adjust configuration and custom software relatively infrequently), while applying security patches and other bugfixes, and being well-tested to work together are the first ones I think of. With "breaking changes" including changes to configuration, file formats, command-line interfaces, notable behavior, as well as library interfaces. Well, I think it mostly amounts to "knowing that an existing install isn't going to get borked by an update".

Supporting multiple dependency versions and stability guarantees indeed must help with avoidance of breaking changes in libraries, assuming the latest compiler version (or a dependency restriction: either compatible packages in system repositories or if there was such dependency resolution in Cargo), though probably not so much with fixes (I imagine there is less motivation to maintain stable branches and apply fixes to those then) and with integration testing. Besides, not all software is written in Rust: other packages and ecosystems must be taken into account as well. Likely more varied ecosystems can be handled more smoothly with NixOS or GuixSD, but I am not risking to use them on anything that should be reliable yet (maybe it is the time to look into those again though). But this kind of poor compatibility with stable systems does not seem necessary, especially for a language that is supposedly a safer alternative to C, while C is about as well-integrated into--and compatible with--common (POSIX) systems as it gets. Though then again, above it was noted that our experiences with C differ, but this is how I see it.