We all dodged a bullet

If I compare a typical Rust project, with a same JavaScript one, JavaScript project itself often has magnitudes more direct dependencies (wide supply chain?). The rust tool will have three or four, the JavaScript over ten, sometimes ten alone to help with just building the typescript in dev. Worsened by the JavaScript dependencies own deps (and theirs, and theirs, all the way down to is_array or left_pad). Easily getting in the hundreds. In rust, that graph will list maybe ten more. Or, with some complex libraries, a total of several tens.

This attitude difference is also clear in Python community. Where the knee-jerk reaction is to add an import, rather than think it through, maybe copy paste a file, and in any case, being very conservative. Do we really need colors in the terminal output? We do? Can we not just create a file with some constants that hold the four ANSI escape codes instead?

I'm trying to argue that there's also an important cultural problem with supply chain attacks to be considered.

"This is a 10/10 phishing email."

It's not. But it doesn't mean I wouldn't also fall for it because I was tired/in a hurry or whatever else could let me drop my guard.

Humans are humans.

> But beyond the technical aspects, there's something more critical: trust and long-term maintenance. I have been active in open source for over a decade, and I'm committed to keeping Chalk maintained. Smaller packages might seem appealing now, but there's no guarantee they will be around for the long term, or that they won't become malicious over time.

I expect him to know better.

For more context on why I thought that link would have been helpful: In Go you download dependencies "straight" from the source[1], while in npm and other languages you download dependencies from a completely unrelated registry that can have any random code (i.e. whether the published artifact was built from the alleged source repository, is a flip of a coin).

So not having this kind of third party registry eliminates the point of failure that caused the issue commented in the article. The issue was caught because of a centralized place, yes, but it was also caused because npm dependencies are downloaded from a centralized place and because this centralized place only hosts artifacts unrelated to the source code itself; package authors can `npm publish` artifacts containing the exact source code from their repos if they want though. If.

With Go, having a mirror of the source code is still third party infra, but is more an optimization than anything else, and checksums are generated based on the source itself[2] (rather than any unrelated artifact). This checksum should match even for people not using any proxy, so if you serve different code to someone, there will be a mismatch between the checksum of the downloaded module and the checksum from the SumDB. This should catch force-pushes done to a git repository version tag, for example.

Also, Go downloads the minimum version that satisfies packages, so it's less likely that you'll download a (semver) "patch" release that someone pushed hours ago.

All this makes me both like and dislike how Go handles dependencies.

[1]: Well, from a mirror, unless you set `GOPROXY=direct`. Reasoning explained in next paragraph.

[2]: The checksum is calculated from a zip file, but it is generated in a deterministic way, and this checksum is also generated and validated locally when you download dependencies. More info at https://go.dev/ref/mod#zip-files and https://go.dev/ref/mod#go-mod-verify