Some additions to what your post and the other comments listed:

• Systemd (including init system and service management)
• Freedesktop software (including Wayland and Xorg)
• Freedesktop specifications or Freedesktop specification repository (including filesystem hierarchy and D-Bus)
• Python (as an addition to C and Bash, as this is standard in Linux)
• Git (including git command and Github)

Depends on what exactly we talk about. I don’t need to wait years for the new updates of specific programs, where I need or want to have the new features and improvements. RetroArch is such a case. I even compile it from source nowadays, because they don’t update it in over a year. And imagine this was part in the distributions stable repository, which would take even longer to get the new version. The Linux Kernel is also updated frequently and contains improvements for performance or compatibility. I used Ubuntu for 13 years straight, starting as my first main distribution. And I was sick of this “stable” thing, where in example GIMP wasn’t updated in the repository. I used PPAs to mitigate this, and it was a horror. In example when GIMP released to support long standing requests for features, it was painful not able to use them, because it would have helped me a lot back then.

These are just a few things, not a list of all reasons. With AppImages and Flatpak (or Snap), there is less reason to use Rolling Releases than ever, but its not a full replacement for distributions repository.

I assume that’s because Archlinux is designed to be minimal and you to add and change things. You are expected to understand and people maybe experiment or do things wrong. On top of it, the ever changing nature of always up to day can break sometimes (usually it doesn’t, but its more prone to breakage than a cyclic upgrade).

My above suggestion wasn’t actually using Archlinux directly, but more like EndeavourOS or CachyOS in example. Arch was just an example, there are also Rolling Release models for Fedora and openSUSE as well. I just mentioned this type of Rolling Release as to why you would want to switch off from Mint, as this could be a good reason for.

“Newbie distro” is usually meant to describe an operating system that is easy to get into for newcomers to Linux, who don’t want to get into the details yet and just start using it. This is my interpretation of what the communities usually mean by that term.

If you like Mint, then there is no reason to switch off it, especially not for the reasons because people call it “newbie”. It’s likely that there is no “better” distribution for you and everything that is different will be bother you. One reason why you might want to switch off could be a Rolling Release model, like Archlinux (or something based on Arch that is rolling too). But that comes with its own problems and you might not like it to have an ever changing and evolving system, always updating to the newest. If that doesn’t excite you, then maybe you should stick with a cyclic release model like Mint. And nothing wrong with it, if you like that stability*!

*stability=here that doesn’t mean a stable system in sense of problems, but more in the sense of non changing stable environment, unstable would mean its always evolving as a rolling release, not that it is less stable in problems

The full context of the paragraph, which is important here:

A virtual machine boots a guest operating system. Raven instead implements Windows interfaces through these guest components and supervisor services. Wine also implements Windows interfaces; the distinction here is how Raven divides that work and supervises the guest, rather than whether system libraries exist inside the application’s process.

I’m not entirely understanding this, but it sounds like a hybrid concept between WINE and a virtual machine. So its only partially virtualized.

It’s not about the popularity…

In fact, if anything, it’s easier to assume rustc is present than it is to assume cargo is present, because cargo needs rustc, but rustc does not need cargo

No. Because if there was rustc+stdlib as a package to install, then we could make the argument. But if Cargo is the only package available with rustc, then there is no point in making this argument. In most distributions there aren’t rustc+stdlib only package.

then it would make more sense to assume rustc (which has to be installed to have cargo anyway)

The point is, not having Cargo and all the other rest of the systems to install when installing rustc. Sorry, but am I talking Chinese? (and yes, I get impatient.)

I think the g++ comparison doesn’t hold here, because it’s not the only way of using the language.

I’m not sure what do you even mean by that…

I explained it following that quote. I’m trying. You bring g++ as an argument why its not widespread adopted. Because g++ is not the only alternative to something like a package manager like Cargo. Nobody “needs” g++. There are many ways of compiling Cpp, even without using a package manager. So nobody has to use g++ to avoid something like Cargo and all the other stuff.

I’m not saying it stops people from using rustc only. I think there is a huge misunderstanding here. Currently, its just highly specialized use cases where they have to use rustc only without even the standard library (I think the Linux Kernel doesn’t use the stdlib). What I say is, that the current infrastructure and distributions doesn’t treat rustc+stdlib as its own thing, that nobody will target it and everyone assumes Cargo.

In example there is no rustc+stdlib compiler as a package by distributions. This should be a standard package by all distributions in my opinion, just like we have C compilers doing the most basic thing. From packaging standpoint. This would encourage people to do such projects, as if you just require basic tools that are not always installed, but can be assumed to easily install. It also should have less dependencies than Cargo and rustfmt in example, or even rustup.

I think the g++ comparison doesn’t hold here, because it’s not the only way of using the language. Rust on the other hand has only one other way of doing this, it’s the dependency heavy and full package with cargo and the rest, even usually downloading dependencies and and so on. It’s a full package manager. If g++ was the only alternative to such a system, I think it would have more widespread adoption.

Debian does have a rustc package, is using rustc directly more widespread in Debian?

Well it needs to be a standard in most common distributions. No one wants to rely on something that is found in one distribution only.

you are likely gonna need dependencies in rust. regex was just an example…

As I said, not if you don’t need dependencies.

Using Rust as some freestanding - side thing is not the common usecase

Because there is no infrastructure supporting this. Why would anyone write Rustc only programs, if there is no such package and widespread availability?

That’s true if you try to replicate the same program without Cargo. But that’s not what I am suggesting. If you don’t need regex and all the dependencies, then you don’t need Cargo. And this could encourage to write programs without all these dependencies. Also Cargo is deeply integrated into Rust, but Rust is not deeply integrated (speak no dependency) to Cargo. I know of all the features and why Cargo is fantastic, I love it myself.

But one has nothing to do with the other. My suggestion is for tools and code that doesn’t need these dependencies. I am not suggesting to replicate the same work or features as when doing huge applications with Cargo and dependencies. We can write programs with stdlib only, hell even without stdlib (technically, I’m not suggesting this as the new normal).

“self-confined” I think my weak English showed up again. I mean projects that has all dependencies in the project itself. And don’t get me wrong, I’m not suggesting to write Regex Parser, GUI system and other huge tasks and put them in the project. If you need those, then its better to use the libraries that are available, with Cargo.

Not every program needs all those dependencies and features. Also relying on those dependencies, that rely on other dependencies and so on can also be a security nightmare. My point is to have those projects that are much more simple, maybe even part of other projects like Python (just a random idea, don’t over analyze that).

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.

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.

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.

What distribution includes precompiled libraries (not user programs) in Rust?

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.

I think one of the reasons why this is not done is because Rust deliberately pushes away from relying on precompiled binaries.

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).

If they are packaged in the repository itself or like C and Python packages with your distribution, then it’s not different.

“nobody” means: those who have big projects with multiple .rs files but no Makefile, no cargo.toml, no build.sh, nothing, only the .rs files. Can you point to a project that does that?

That’s the point. We don’t have default rustc on all machines and repositories. In example in Archlinux repositories there is not package rustc only and its standard libraries to install. That’s why most people don’t do it. You can’t fault the missing projects are missing, because the infrastructure is not there yet.

But that was not MY point at all. My point is to avoid Cargo, the registry and external dependencies from cratesio. The makefile just uses standard Linux make command. It was just an example to automate this (it could have been a simple Bash script too), but the point is it can be done manually. In this example and even in more useful ones, it can be just a simple rustc invocation.

What does nobody mean here? We are doing this for ages in C in example. A Makefile can help automate this process. Download git project and run make without any Cargo or regristry or other requirements. Don’t talk about everyone, just because you are not doing it.

Also the shown example is a single rustc command that will automatically compile and link all associated (with the dependency in the files) and produce a single output.

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.