Also, do we just trust all these random libraries? Not just about malicious code, but also what kind of quality/usability are you including?
I mean, no, I don’t trust them. At best, I largely trust the libraries that I’ve included directly, and somewhat trust them to themselves pick libraries which don’t look too fishy. But I do not know what most libraries in my project actually even do, so it would be ridiculous to claim that I trust them.
In terms of quality/usability, well, Rust has the advantage that the compiler is very strict and checks a lot of things. If it compiles, it’s already half-decent.
You also get easy access to a linter and unit testing. Documentation tooling is built-in. If you put in the tiniest amount of effort, it’s really not hard to create something usable.
Rust, like JS, also locks the dependencies. So, it picks out a set of versions that works together and then it documents those versions (as well as checksums of the libraries) in a file, which you put into the repo. And then it uses those documented versions until I run cargo update to grab new versions. So, if a library author pushes a malicious version, I won’t be affected unless I do run cargo update at the wrong time. This gives the ecosystem at least some time to react or to find malicious code, if it’s been included in an inactive state. Certainly no silver-bullet, but it makes it less attractive for malicious devs to try to include malware in a library.
The huge benefit of the standard library is that I can always trust it, and it will always be the idiomatic way to do things.
Well, counter-example: Python.
Python chose to have a pretty big std lib, which kind of makes sense, because you want scripts to be able to run without having to install dependencies first.
But as a result, Python’s std lib also has relatively poor quality, with sometimes just bugs or unexpected behavior in there. And if you look online how to do XYZ, chances are half the people will tell you to use the std lib and the other half will tell you that the std lib is awful, you should use xyzlib instead.
In general, in many languages, parts of the std lib get implemented before anything else, when the language typically hasn’t found its style yet. In Python, you can see that, for example, with some stdlib functions not using snake_case. So, I kind of get what you mean with “idiomatic”, in that it’s normal to use the std lib, but the way how you invoke that std lib function may not be idiomatic at all…
Also, do we just trust all these random libraries? Not just about malicious code, but also what kind of quality/usability are you including?
Big companies do not want to trust open package repositories. They attempt to take countermeasures (but how much can you do?)
The huge benefit of the standard library is that I can always trust it, and it will always be the idiomatic way to do things.
I mean, no, I don’t trust them. At best, I largely trust the libraries that I’ve included directly, and somewhat trust them to themselves pick libraries which don’t look too fishy. But I do not know what most libraries in my project actually even do, so it would be ridiculous to claim that I trust them.
In terms of quality/usability, well, Rust has the advantage that the compiler is very strict and checks a lot of things. If it compiles, it’s already half-decent.
You also get easy access to a linter and unit testing. Documentation tooling is built-in. If you put in the tiniest amount of effort, it’s really not hard to create something usable.
Rust, like JS, also locks the dependencies. So, it picks out a set of versions that works together and then it documents those versions (as well as checksums of the libraries) in a file, which you put into the repo. And then it uses those documented versions until I run
cargo update
to grab new versions. So, if a library author pushes a malicious version, I won’t be affected unless I do runcargo update
at the wrong time. This gives the ecosystem at least some time to react or to find malicious code, if it’s been included in an inactive state. Certainly no silver-bullet, but it makes it less attractive for malicious devs to try to include malware in a library.Well, counter-example: Python.
Python chose to have a pretty big std lib, which kind of makes sense, because you want scripts to be able to run without having to install dependencies first.
But as a result, Python’s std lib also has relatively poor quality, with sometimes just bugs or unexpected behavior in there. And if you look online how to do XYZ, chances are half the people will tell you to use the std lib and the other half will tell you that the std lib is awful, you should use
xyzlib
instead.In general, in many languages, parts of the std lib get implemented before anything else, when the language typically hasn’t found its style yet. In Python, you can see that, for example, with some stdlib functions not using snake_case. So, I kind of get what you mean with “idiomatic”, in that it’s normal to use the std lib, but the way how you invoke that std lib function may not be idiomatic at all…