Did you read the post? It ends with several critiques of Rust.

Why not? Of course people who make something (in this case, a programming language) are going to promote what they make and share praise they've received. It's a pretty normal thing to do. They're not trying to obscure the fact that they're the Rust Foundation—it's on the Rust blog.

It kinda feels like cheating for rust to publish a list of reasons why rust people like rust...

I like rust too, but this feels more like advertising than useful commentary on the language and its tools.

Oh yeah, I'm not saying this is what makes Rust special. Rust's strength in comparison to Bash is that it's a lot more competent at control flow and structuring programs. But yeah, virtually any programming language is at least better at that than Bash, so whichever one you're most comfortable with, is probably the best choice. This trick just allows you to make use of Bash's biggest strengths, which is easily running commands and piping between commands, while also having the competent control flow and structuring of your programming language of choice.

less likely to be insecure

Evidenced by?

requires reviewing all source code

This is exactly the la-la-land view of what distributors do I was dispelling with facts and reality checks. No one is reviewing all source code of anything, except for cases where a distro developer and an upstream member are the same person. And even then, this may not be the case depending on the upstream project, its size, and the distro developer's role within that project.

to make sure it meets interoperability

Doesn't mean anything other than "it builds" and "API is not broken" (e.g. withing the same .so version), and "seems to work".

These considerations happen to hardly exist with the good tooling provided by cargo.

and open-source standards.

Doesn't mean anything outside of licensing (for code and assets), and "seems to work".

Your argument that crates.io is a known organization therefore we should trust the packages distributed is undermined by your acknowledgement that crates.io does not produce any code. Instead we are relying on the individual crate developers, who can be as anonymous as they want.

Largely correct. But that was me comparing middle-man vs. middle-man. That is if crates.io operators can be described as middle-men, since their responsibilities (and consequently, attack vectors) are much smaller.

Barring organizational attacks from within, with crates.io, you have one presumably competent/knowledgable, possibly anonymous, source, and operators that don't do much. With a binary distro, you have that, AND another "middle-man" source, possibly anonymous, and with competence and applicable knowledge <= upstream (charitable), yet put in a position to decide what to do with what upstream provides, or rather, provided.. X years ago, if we are talking about the claimed "stable" release channel.

The middle man pulls sources from places like crates.io anyway. So applying trivial "logic"/"maths", it can't be "better", in the context being discussed.

Software doesn't get depended on out of thin air. You are either first in line directly depending on a library, and thus you would naturally at least make the minimum effort to make sure it's minimally "fit for purpose". Or you are an indirect dependant, and thus looking at your direct dependencies, and maybe "trusting" them with the "trickle down".

More processes, especially automated ones, are always welcome to help catch "stuff" early. But it is no surprise that the "success stories" concern crates with fat ZERO dependants.

Processes that help dependants share their knowledge about their dependencies (a la cargo vet) are unquestionably good additions. They sure trump the dogmatic blind faith in distros doing something they simply don't have the knowledge or resources to do, or the slightly less dogmatic faith in some library being "trustable" if packaged by X or XX distros, assuming at least someone knowledgable/competent must have given a thorough look (this has a rough equivalent in the number of dependants anyway).

This is all obvious, and doesn't take much thought from anyone active from the inside (upstreams or distros), instead of the surface "knowledge" that leaks, and possibly gets manipulated, in route to the outside.

You can do this in all programming languages that exist...

Kind of agree with you here.. I wouldnt reach for rust. Python gives much faster results than rust.

I think you are completely missing the point. Packages distributed by Debian are less likely to be insecure because Debian policy requires reviewing all source code to make sure it meets interoperability and open-source standards.

Regardless of how frequently this is actually done, if it's done at all is a point in favor of using Debian distribution. The fact that Debian has introduced errors themselves in a few cases is irrelevant, any developer can do that and crates.io is full of them with not even an attempt at additional review.

You need to balance whether or not the distributor is fixing or introducing more bugs, and in the case of Debian it seems to be overwhelmingly the former.

Your argument that crates.io is a known organization therefore we should trust the packages distributed is undermined by your acknowledgement that crates.io does not produce any code. Instead we are relying on the individual crate developers, who can be as anonymous as they want.

Yeah it's great for little scripts. There's even a cargo script feature that's being worked on so you can compile & run them using a shebang.

I'd use a shell script if it is literally just a list of commands with no control logic or piping. Anything more than that and you're pointing a loaded gun at your face, and should switch to a proper language, of which Rust is a great choice.

"I think proc macros are a really big superpower for Rust."

Yeah, been working on a framework and proc-macros are really useful to simplify the API.

For example, previously I needed users to define a struct and then an impl block with a function inside. Well, and they need to do that a lot, so it was genuinely a bit of a pain to write out, but it also made the code feel more complex than it really was.

Now I've got an annotation, which you can slap onto a function and then it generates the struct from the function parameters and puts the function into the impl block.
And while you do need to be aware that the function parameters will be put into a struct and therefore you want owned parameters, all-in-all it still feels really nice to just delete dozens of boilerplate lines and an indentation level in the codebases where I've introduced it.

I like that I have to think in Rust before compiling, not after.

A nice patena on aged metal !

One of the simplest tricks is that you can throw down a function, which you can call with a command like e.g. this: run("cat /etc/os-release | grep NAME")
by constructing a Command like so:

Command::new("sh")
    .arg("-c")
    .arg(command) //the string passed as parameter

There's proper libraries to make running commands even easier and more robust, but if you don't want to pull in a library, that's really easy to write out ad-hoc and gets you 95% of the way there, with shell piping and everything.

As someone who uses a lot of shell scripts and learning Rust, do tell more.

@lens0021 Nice! I will have to give this a go. Congrats on 1.0.0.

Honestly yes. If I need to manipulate the filesystem or manage processes with any amount of conditional logic or looping, I'd much rather do it with Rust than shell scripts.

The only thing I use shell scripts for anymore is completely trivial sequences of commands.

...and not just for performance-heavy stuff or embedded development, but for shell scripts...

WHAT

This is the way with modern software engineering, especially in the industry. It comes from the basic fact that:

1. Companies want to get code for free from the internet - someone else already wrote that code, let's use it for free and have better profit margins!
2. Companies do not want to spend time and effort vetting that free code, as that would make it... well, not free. That would require manpower (perhaps unless you trust AI to do it these days...) and that's money.

Basically they want to eat their cake and have it too. This applies to all modern package managers for modern languages that make it easy to distribute your own code and consume free online code.

I doubt the industry will ever mature to a point where this will stop, as the tradeoff of getting free code with no work is just too good for most companies, especially the smaller ones.

This user wanted to audit the dependencies of cargo vet which is not shipped to an end user. It is part your toolchain in the same way your OS is. One might assume the Linux or BSD kernel has been audited; it is not reasonable to assume the UI stack has because it’s open source. It is equally unreasonable to assume the Windows anything has been audited. It is only slightly reasonable to assume parts of macOS have been audited.

You’re only partially correct. If you are not securing the environment in which you code, your code is vulnerable to supply chain attacks. The chances are incredibly low, of course, but nonzero. You also can’t get away with, say, running your editor in a read-only image that only mounts your code because that read-only image could be exfiltrating your data.

Edit: here’s a great example from this year; while the exploit came from a package the attack vector was social engineering. Job postings and related files are a common entry point outside of dev tools.

That's different to developing software. As a developer you are in large part responsible for ensuring that your software doesn't compromise your users' security. It's reasonable to not want to distribute software that may contain malware or just shitty code that is full of vulnerabilities or bugs.

One of the things I immediately liked about cargo is that (so far as I've seen thus far) the source is already there, without vendoring, in ~/.cargo/registry. In Debian, to get the source it's apt-get source $package and as an end user it's super easy to build things from those source packages if you want to.

While it may never be "enough" depending on your requirements (which you didn't specifically and coherently define), the amount of "review", and having the required know-how to do it competently, is much bigger/higher from your crate dependants, than from your distro packages.

It's not rare for a distro packager to not know much about the programming language (let a lone the specific code) of some packages they package. It's very rare for a packager to know much about the specific code of what they package (they may or may not have some level of familiarity with a handful of codebases).

So what you get is someone who pulls source packages (from the interwebs), possibly patching them (and possibly breaking them), compiling them, and giving you the binaries (libs/execs). With source distros, you don't have the compiling and binary package part. With crates.io, you don't have the middle man at all. Which is why the comparison was never right from the start. That's the pondering I left you to do on your own two comments ago.

Almost all sufficiently complex user-space software in your system right now has a lot of dependencies (vendored or packaged), you just don't think of them because they are not in your face, and/or because you are ambivalent to the realities of how distros work, and what distro developers/packagers actually do (described above). You can see for yourself with whatever the Debian equivalent is to pactree (from pcaman).

At least with cargo, you can have all your dependencies in their source form one command away from you (cargo vendor), so you can trivially inspect as much as you like/require. The only part that adds unknowns/complexities is crates that usebuild.rs. But just like unsafe{}, this factor is actually useful, because it tells you where you should look first with the biggest magnifying glass. And just like cargo itself, the streamlining of the process means there aren't thousands of ways/places in the build process to do something.

Yeah, the personal risk doesn't worry me as much as the idea that it might eventually get to be as bad as npm.

It's definitely a growing problem with Rust. I have noticed my dependency trees growing from 20-50 a few years ago to usually 200-500 now.

It's not quite as bad as NPM yet, where it can easily get into the low thousands. Also the Rust projects I have tend to have justifiably large dependencies, e.g. wasmtime or Slint. I don't think it's unreasonable to expect a whole GUI toolkit to have quite a few dependencies. I have yet to find any dependencies that I thought were ridiculous like leftpad.

We could definitely do with better tooling to handle supply chain attacks. Maybe even a way of (voluntarily) tying crate authors to verified real identities.

But I also wouldn't worry about it too much. If you a really worried, develop in a docker container, use a dependency cooldown, and whatever you do don't use cryptocurrencies on your dev machine.