←back to thread

177 points signa11 | 1 comments | | HN request time: 0s | source
Show context
mjevans ◴[] No.42160806[source]
This makes me further appreciate how golang's features tend to work entirely at compile time, which is also fast.

One of the other things that makes me worry about Rust is how similar it's depends look to npm projects, where there's a kitchen sink of third party (not the language's included library of code, and not the project's code) libraries pulled in for seemingly small utilities.

replies(4): >>42160836 #>>42160837 #>>42160849 #>>42160939 #
hypeatei ◴[] No.42160849[source]
Dependencies are optional, and having a huge standard library also has its tradeoffs. If the standard library has a less than ideal API, it's stuck with that until a major version bump and you either:

1. End up with a third party package filling in the gaps, or

2. Another standard library API that users slowly migrate to

replies(2): >>42160871 #>>42162412 #
tsimionescu ◴[] No.42162412[source]
Unfortunately, in a world with increasingly more sophisticated attackers looking at supply chain attacks, having a lot of dependencies, especially ones that update regularly, is a huge security risk. For a language like Rust, which aims to be both low level and used in secure environments, I would argue that the risks far outweigh the benefits.

We'll see how this works, Rust is still young and not yet used in any hugely important projects (or at least not in hugely important parts of those projects - e.g. some Linux drivers, not the core kernel; some bits of Firefox'S rendering, not the JS engine). As it becomes more central, it's value as an attack target will increase, and people will start taking infiltrating malicious code in small but widely used dependencies.

replies(2): >>42162816 #>>42166078 #
1. ◴[] No.42162816{3}[source]