TLDR: Rust, Go and other modern languages don’t use more dependencies than C/C++, but have larger binaries due to including libraries into the executable binary. This trade-off was chosen to ensure you can reliably run the executable on various systems without dependency issues.
I personally have gone with both options on several occasions. Being able to include an HTTP client without having to debug someone’s cURL installation is certainly worth a few extra MiB’s of disk space. However, I’ve also used C instead of Rust to avoid a very simple CLI program turning into several MiB’s large binary (due to statically including the Rust std lib).
The article seems like a rebuttal to a strawman argument to me.
You’d have to be pretty oblivious (or a non-software engineer) to express the premise of this article as an opinion.
The only interesting part to me was asking specifically what types of functionality are being delegated to libraries instead of (re-)implemented in the program itself. The author should ask this same question of some Rust and Javascript programs of similar size, so we can see if left-pad in Javascript is just a meme or if programmers armed with convenient package managers are delegating trivial one-liners to external libraries.
Speaking as a Rust programmer, I feel like the biggest hurdle to using libraries in place of one-liners, is finding out about those libraries. At some point, you’re going to search “How to pad string in Rust/JS?”. And then StackOverflow, or an LLM mindlessly parroting it, will tell you to use leftpad, or well, in the case of Rust, this functionality is actually in the std lib.
So, I’d say, it actually depends a lot on the culture of a given programming language, whether the use of a library will be the top response or a short code snippet.
And I do feel like JS is in somewhat of a special spot in this regard, having been designed by committee, so there’s some really silly omissions from the std lib. And it’s also often used by hobbyists, who just dish out a project and then move on, never having to deal with the dependency hell that follows…
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…
Yup. Or at the very least, a distro package’s listed dependencies don’t show you the true dependencies a program needs to function. There are a lot of dependencies that are needed but not listed because they are installed through transitively by other packages.
Rust shows you the true scale because it’s statically linked. That being said, Rust really may use more dependencies, but directly comparing the number of dependencies can be misleading without considering the scope and focus of each dependency.
TLDR: Rust, Go and other modern languages don’t use more dependencies than C/C++, but have larger binaries due to including libraries into the executable binary. This trade-off was chosen to ensure you can reliably run the executable on various systems without dependency issues.
I personally have gone with both options on several occasions. Being able to include an HTTP client without having to debug someone’s cURL installation is certainly worth a few extra MiB’s of disk space. However, I’ve also used C instead of Rust to avoid a very simple CLI program turning into several MiB’s large binary (due to statically including the Rust std lib).
The article seems like a rebuttal to a strawman argument to me.
You’d have to be pretty oblivious (or a non-software engineer) to express the premise of this article as an opinion.
The only interesting part to me was asking specifically what types of functionality are being delegated to libraries instead of (re-)implemented in the program itself. The author should ask this same question of some Rust and Javascript programs of similar size, so we can see if
left-padin Javascript is just a meme or if programmers armed with convenient package managers are delegating trivial one-liners to external libraries.Speaking as a Rust programmer, I feel like the biggest hurdle to using libraries in place of one-liners, is finding out about those libraries. At some point, you’re going to search “How to pad string in Rust/JS?”. And then StackOverflow, or an LLM mindlessly parroting it, will tell you to use leftpad, or well, in the case of Rust, this functionality is actually in the std lib.
So, I’d say, it actually depends a lot on the culture of a given programming language, whether the use of a library will be the top response or a short code snippet.
And I do feel like JS is in somewhat of a special spot in this regard, having been designed by committee, so there’s some really silly omissions from the std lib. And it’s also often used by hobbyists, who just dish out a project and then move on, never having to deal with the dependency hell that follows…
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 updateto grab new versions. So, if a library author pushes a malicious version, I won’t be affected unless I do runcargo updateat 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
xyzlibinstead.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…
Yup. Or at the very least, a distro package’s listed dependencies don’t show you the true dependencies a program needs to function. There are a lot of dependencies that are needed but not listed because they are installed through transitively by other packages.
Rust shows you the true scale because it’s statically linked. That being said, Rust really may use more dependencies, but directly comparing the number of dependencies can be misleading without considering the scope and focus of each dependency.