What I always hated about defer is that you can simply forget or place it in the wrong position. Destructors or linear types (must-use-once types) are a much better solution.
> Wasn't that a suspected state actor? Against that threat model your best course of action is a prayer and some incense.
No? They caught it! But they did so because the software had extensive downstream (!) integration and validation sitting between the users and authors. xz-utils pushed backdoored software, but Fedora and Debian picked it up only in rawhide/testing and found the issue.
> Notably, xz utils didn't use any package manager ala NPM and it relied on package management by hand.
With all respect, this is an awfully obtuse take. The problem isn't the "package manager", it's (and I was explicit about this) it's the lack of curation.
It's true that xz-utils didn't use NPM. The point is that NPM's lack of curation is, from a security standpoint, isomorphic to not having any packaging regime at all, and equally dangerous.
> a Postgres dev running bleeding edge Debian
Exactly. Not sure how you think this makes the point different. Everything in Debian is volunteer, the fact that people do other stuff is a bonus. Point is the debian community is immunized against malicious software because everyone is working on validation downstream of the authors.
No one does that for NPM. There is no Cargo Rawhide or NPM Testing operated by attested organizations where new software gets quarantined and validated. If the malicious authors of your upstream dependencies want you to run backdoored software, then that's what you're going to run.
No? Who else has 2-3 years worth of time to become a contributior and maintainer for obscure OSS utils?
Plus made sockpuppets to put pressure on OG maintainer to give Jia Tan maintainer privilege.
> Exactly. Not sure how you think this makes the point different. Everything in Debian is volunteer, the fact that people do other stuff is a bonus.
What you mean exactly? This isn't curation working as intended. This is some random dev discovering it by chance. While it snuck past maintainers and curator of both Debian and Red Hat.
> Everything in Debian is volunteer, the fact that people do other stuff is a bonus. Point is the debian community is immunized against malicious software because everyone is working on validation downstream of the authors.
You can do same in NPM and Cargo.
Release a v1.x.y-rc0, give everyone a trial run, see if anyone complains. If they do, it's downstream validation working as intended.
Then yank RC version and publish a non-RC version. No one is preventing anyone from making their release candidate version.
> No one does that for NPM. There is no Cargo Rawhide or NPM Testing
Because, it makes no more sense to have Cargo Rawhide than to have XZ utils SID.
Cargo isn't an integration point, it's infra.
Bevy, which integrates many different libs, has a Release Candidate. But a TOML/XYZ library it uses doesn't.
> You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.
The idea with making std.Io an interface is that we're not forcing you into using green threads - or OS threads for that matter. You can (and should) bring your own std.Io implementation for embedded targets if you need standard I/O.
Ok. But if your program assumes green threads and spawn like two million of them on target that doesn't support them, then what?
The nice thing about async is that it tells you threads are cheap to spawn. By making everything colourless you implicitly assume everything is green thread.
reply