5 ms·

I like Rust-the-language, but I hate the Rust-dependencies situation. Honestly I like C++ a lot better for that. People will complain that "it's hard to add a d

by palata 2y ago

I like Rust-the-language, but I hate the Rust-dependencies situation. Honestly I like C++ a lot better for that. People will complain that "it's hard to add a dependency to a C++ project", but I actually see it as a feature. It forces you to think about whether or not it is worth it. In C++, I control my dependencies. In Rust I get above 100 so quickly I just give up. In terms of security, let's be honest: I have no clue what I am shipping. Also Rust does not have ABI compatibility and no culture of shared libraries (I guess it wouldn't be practical anyway given the number of libraries one needs). But that just destroys the OS package distribution model: when I choose a Linux distribution, I choose to trust those who build it. Say Canonical has a security team that tries to minimize the security issues in the packages that Ubuntu provides. Rust feels a lot more like Python in that sense, where anyone could push anything to PyPi.

fxtentacle 2y ago
How is Debian / Ubuntu secure? It's signed by a maintainer. And maintainers are vetted. You trust Debian/Ubuntu to only allow trustworthy people to sign packages. How are Docker / Python / Rust secure? I don't know any of the people who created my docker images, PyPi packages, or Rust crates. Yes. We're basically back to sending around EXE and DLL files in a ZIP. It's just that now we call it a container and proudly start it as root. BTW, I agree with the author of the article: Sometimes you're best off just merging dependency source code. It used to be called "vendoring" and was a big thing in Rails / Ruby. The big advantage is that you're not affected by future malicious package takeovers. But you can still merge security patches from upstream, if you choose to do that.
- tonyhart7 2y ago
  You use in house solution??? any of these guys that want build something minimal dependency free is valid concern, I agree with that but but what if people just don't want that??? it given people jobs and things to do (lol, this is serious) also there are certain things better to use third party library than develop in house like crypto
- akerl_ 2y ago
  The vetting process for open source maintainers has very little overlap with the vetting process for “is this person trustworthy”. This is true for individual libraries and also for Linux distros.
- liontwist 2y ago
  > How is Debian / Ubuntu secure? You’re also forgetting process isolation and roles which provide strong invariants to control what a given package can do. No such guarantees exist for code you load into your process.
- woodruffw 2y ago
  I don’t follow this reasoning: you might trust this distribution packager to be honest, but this doesn’t stop them from honestly packaging malicious code. It’s unlikely that the typical distribution packager is reviewing more than a minority of the code in the packages they’re accepting, especially between updates. There are significant advantages to the distribution model, including exact provenance at the point of delivery. But I think it’s an error to treat it as uniquely trustworthy: it’s the same code either way.
  - WhyNotHugo 2y ago
    "Trust" as two meanings in English: - You can trust someone as in "think they're honest and won't betray me". - You can trust someone as in "think they are competent and won't screw-up". In this case, we trust distributions packagers in both ways. Not only do we trust that they are non-malicious, we also trust that they won't clumsily package code without even skimming through it.
    - woodruffw 2y ago
      The point was not about competency. I think typical distribution packagers are very competent. "They won't screw up" is the wrong way to look at security: humans always screw up. We're essentially fallible. We would all do well to remember that the xz backdoor was not caught by distribution code review: it was caught due to a performance side effect that the next adversary will be more careful to avoid. Software stacks are getting bigger, largely due to engineering pressures that are outside of the control of distributions. It's a basic fact that that means work for the same (or fewer) people, which in turn means less time spent on more complicated packages. Under those conditions, competency is not the deciding factor. This is, separately, why having lots of little packages can be (but isn't necessarily) a good thing: small packages that decompose into well-understood units of work can be reviewed more quickly and comprehensively, and can be assigned capabilities that can be tracked and audited with static analysis. You can't do that as easily (or at all) when every package decides to hand-roll its own subcomponents.
      - 2y ago
- KronisLV 2y ago
  > How are Docker / Python / Rust secure? I don't know any of the people who created my docker images, PyPi packages, or Rust crates. I know who created the Docker images, because I'm the person who built them! A lot of the time you can build your images either from scratch, or based on the official base images like Alpine or Ubuntu/Debian or some of the RPM base images, not that much different than downloading an ISO for a VM. With a base, you can use apk/apt/dnf to get whatever packages you want if you trust that more, just remember to clean up the package cache so it's not persisted in the layers (arguably wastes space). For most software, it actually isn't as difficult as it might have initially seemed. As an alternative, you can also look for vaguely trustworthy parties that have a variety of prepackaged images available and you can either borrow their Dockerfiles or just trust their images, for example, https://bitnami.com/stacks/containers https://bitnami.com/stacks/containers and https://hub.docker.com/u/bitnami https://hub.docker.com/u/bitnami Most likely you have to have trust somewhere in the mix, for example, I'm probably installing the Debian/Ubuntu packaged JDK instead of compiling mine in most cases, just because that's more convenient. Also, rootless containers are pretty cool! People do like Podman and other solutions a lot, you can even do some remapping with Docker if there are issues with how the containers expect to be run https://docs.docker.com/engine/security/userns-remap/ https://docs.docker.com/engine/security/userns-remap/ or if you have to use Docker and need something a bit more serious you can try this https://docs.docker.com/engine/security/rootless/ https://docs.docker.com/engine/security/rootless/
- rad_gruchalski 2y ago
  > It's signed by a maintainer. And maintainers are vetted. You trust Debian/Ubuntu to only allow trustworthy people to sign packages. > How are Docker / Python / Rust secure? I don't know any of the people who created my docker images, PyPi packages, or Rust crates. Me neither. But the same goes for those from Debian/Ubuntu. In fact, neither I know anyone who vets those who sign and publish packages. What I know is that I can build my own images from container files and then I’m back to installing those apparently trusted packages from Debian/Ubuntu. > We're basically back to sending around EXE and DLL files in a ZIP. It's just that now we call it a container and proudly start it as root. I don’t get your point. And what’s an rpm or deb? You also potentially run stuff as root… sudo apt install -y… post install scripts…
jvanderbot 2y ago
So, the feature of "Here's a set of easily pulled libraries" is an anti-feature because it makes it easy to pull supporting libraries? I suspect this is actually about developers and not Rust or JS. Developers choose what dependencies to pull. If nobody pulled a dependency it would wither and die. There are a lot of dependencies for most libraries because most developers prefer to use dependencies to build something. But I digress. If we're talking build system, nobody is forcing you to use Crates.io with cargo, they just make it easy to. You can use path-based dependencies just like CMake/VCPkg,Conan, or you can DIY the library. Even with crates.io, nobody is forcing you to not use version pinning if you want to avoid churn, but they just make it easy to get latest. It's easy to build software on existing software in Rust. If you don't like the existing software or the rate it changes don't blame Cargo. Just do it the way you like it.
- chrisco255 2y ago
  [flagged]
  - palata 2y ago
    > They also prefer languages with buffer overflow and use-after-free errors. Bad faith? My first sentence clearly says that I like the language, not the dependency situation.
  - johnnyjeans 2y ago
    he literally said he likes rust as a programming language, so no. also it's not "optional" when it's the de-facto standard in the language. you lock yourself out of the broader tooling ecosystem. no language server, no libraries (because they all use cargo), etc. oftentimes you run into ergonomic problems with a language's module system because it's been hacked together in service of the enormous combo build/dependency management system rather than vice versa. you're running so far against the grain you might as well not use the language. this kind of passive-aggressive snark whenever someone leverages this very valid criticism is ridiculous
- a-french-anon 2y ago
  > because it makes it easy to pull supporting libraries? No, because it's used as an excuse for a lack of large(r) standard library. It's the equivalent of "the bazaar/free market will solve it!". You basically end up with a R5RS level of fragmentation and cruft outside your pristine small language; something that the Scheme community decided is not fun and prompted the idea of R6RS/R7RS-large. Yeah, it's hard to make a good, large and useful stdlib, but punting it to the outside world isn't a proper long-term solution either. It's really a combination of factors.
a-french-anon 2y ago
That's what I say when I converse about my colleagues: having a package manager from the start that greatly lowers the friction of adding or publishing yet another package deprives a language's ecosystem from something very useful: a good measure of natural selection. Add to that a free-for-all/no curation repository situation like pypi, npm or cargo together with a too small standard library and prepare to suffer.
- XorNot 2y ago
  I wonder how much of this is just the move away from shared libraries. In the .NET space nuget certainly makes it easy to add dependencies, but dependencies do seem to be overall fewer and the primary interesting difference I'd note is that a dependency is in fact it's own DLL file - to the extent that it's a feature that you can upgrade and replace them by dropping in a new file or changing configuration. It strikes me that we'd perhaps see far less churn like this if more languages were back to having shared libraries and ABI compatibility as a first class priority. Because then the value of stable ABIs and more limited selections of upgrades would be much higher.
  - a-french-anon 2y ago
    The quest for performance makes macros, monomorphisation/specialization and LTO too attractive for simple dynamic linking to remain the norm, unfortunately. And in a way, I understand, a Stalin/MLton style whole-program optimizing compiler certainly is worth it when you have today's computing power.
    - funcDropShadow 2y ago
      Unless you have a very good JIT compiler, like JVMs. Than you can defer LTO and whole program optimization to runtime.
oersted 2y ago
This frankly sounds like a rationalization for an aesthetic preference. It is undeniable that being able to easily build on top of others' hard work is an enormous advantage in any domain. Duplicate work should only happen if you are confident that your requirements are significantly different, and that you can deliver an implementation as good as a team that has likely focused on the problem for much longer and has acquired a lot more know-how. It is true that such an attitude might be justifiable for certain security or performance critical applications, you might need end-to-end control. But even in those cases, the argument for trusting yourself by default over focused and experienced library authors is dubious. Either way, a good dependency manager opens the door for better auditing, analysis and tagging of dependencies, so that such critical requirements can be properly guaranteed, again probably better than you can do yourself.
- palata 2y ago
  > Duplicate work should only happen if you are confident that [...] You are making a ton of assumptions on the quality of the average library you can depend on: that a whole team worked on it, that it worked on it a long time and that it produced good code. That's really not a given. You are also assuming that writing a feature instead of using a library is "duplicate work". It's not necessarily the case. Maybe the library approaches the problem in a much more generic way than you need. Your requirements are not "significantly different" then, just a subset of the library. > so that such critical requirements can be properly guaranteed, again probably better than you can do yourself. Are you saying that the packages available in cargo are systematically audited? I believe that the vast majority of them is not audited at all.
lolinder 2y ago
There's a corollary here to "build it yourself", which is "vet it yourself". Cargo, npm, and pip all default to a central registry which you're encouraged to trust implicitly, but we've seen time and time again that central registries do not adequately protect against broken or malicious code that causes major security flaws downstream. Each of these ecosystems trains its developers to use hundreds of dependencies—far more than they can personally vet—with the understanding that someone else must surely have done so, even though we've seen over and over again that the staff of these registries can't actually keep up and that even long-running and popular projects can suddenly become insecure. I'd like to see an ecosystem develop that provides a small amount of convenience on top of plain old vendoring. No central repository to create a false sense of security. No overly clever version resolution scheme to hide the consequences of libraries depending on dozens of transitive dependencies. Just a minimal version resolution algorithm and a decentralized registry system—give each developer an index of their own libraries which they maintain and make downstream developers pick and choose which developers they actually trust. Maybe a bit like Maven if Maven Central didn't exist?
- pdimitar 2y ago
  Thought about it many times but never had the time or energy to tackle something as big and new. You?
Ygg2 2y ago
> In C++, I control my dependencies. In Rust I get above 100 so quickly I just Just don't add dependencies, it's that simple. If you have enough time to control C++ dependencies, you can control them in Rust as well.
- lolinder 2y ago
  That's not an answer when the entire ecosystem is built around the idea of adding lots of dependencies to do stuff. I don't need no dependencies, I'd like to live in a world where I can add two or three. But if the culture is so far gone that those two or three transitively import 20 each, I don't have that as an option—it's all or nothing.
  - Ygg2 2y ago
    > That's not an answer when the entire ecosystem is built around the idea of adding lots of dependencies to do stuff. Again. Don't add dependencies. Just don't. Vendor it yourself. Or write it yourself. Absolutely nothing is forcing you to use the dependencies except your own desire to save time. Cargo is giving you the option to A) save your own time B) minimize dependencies. You choose A) and blame Cargo.
    - palata 2y ago
      I don't think it's entirely fair. You're telling me "don't use any dependency at all". Vendoring is not a solution, because it does not remove the transitive dependencies. So I have to essentially rewrite it myself. I find many libraries in C++ that don't pull 20 dependencies. It's common for me to have a C++ project that has ~6-8 dependencies. In Rust I have never seen that. Either I have no dependency at all, or I have 100+. I actually had this toy project that I wrote both in C++ and in Rust, for the learning experience. Both did exactly the same thing, with a very similar design. In C++ I had 8 dependencies. In Rust, 186. The thing is, 186 is enough for me to not even read all their names in the lock file. As soon as 25 dependencies magically appear in my lock file, I stop caring and start YOLOing it.
      - 2y ago
SkiFire13 2y ago
> People will complain that "it's hard to add a dependency to a C++ project" The way I see it the issue is that it's hard to add a dependency _in such a way that no people will have issues building your project with it_. This is problematic because even if you manage to make it work on your machine it may not work on some potential user or contributor's. > But that just destroys the OS package distribution model: when I choose a Linux distribution, I choose to trust those who build it. Distros still build Rust packages from sources and vendor crate dependencies in their repos. It's more painful because there are usually more dependencies with more updates, but this has nothing to do with shared libraries.
- palata 2y ago
  > The way I see it the issue is that it's hard to add a dependency _in such a way that no people will have issues building your project with it_. From my point of view, if it's done properly I can just build/install the dependency and use pkgconfig. Whenever I have a problem, it's because it was done wrong. Because many (most?) developers can't be arsed to learn how to do it properly; it's easier to just say that dependency management in C++ sucks.
  - pdimitar 2y ago
    Taking pride in being willing to take the longer and more error-prone and tedious path makes me wonder if you're not just flexing here. There are thousands of tools and methodologies screaming for our attention to "be arsed to learn to do them properly". They're not owed that attention, they must deserve it. And statistically + historically speaking, most have failed to do so. You may choose to interpret this as you belonging to a small elite group of intellectuals who "are arsed to learn to do stuff properly" -- that's your right. I choose to interpret it as "Cargo solves a real problem that has wasted numerous hours of my time in the past". And it wasn't because, for the third time, "I wasn't arsed to learn to do it properly", it's because nobody followed basic protocol and good practices to make the legendary "proper way" work reliably. You're likely living and working in a bubble. It's much worse than the Wild West out there, man. Any tool that reduces the drudgery and allows for quicker doing of the annoying parts is a net positive.
LinXitoW 2y ago
I genuinely don't know what people with this opinion work on that they can so easily choose to completely re-invent the wheel in every project, just because they're afraid of hypothetical dangers. Most of which are still present for private re-implementations (like bugs). I cannot think of a single project where NIH syndrome would've been a net positive. Even dependencies that aren't "essential" are super helpful in saving time. When you recreate parts of an "optional" dependency for every single project, how do you find the time to fix all the extra bugs, the edge cases, the support for different versions of lower level dependencies, of different platforms?
- palata 2y ago
  > that they can so easily choose to completely re-invent the wheel in every project Nobody, and I mean 0, chooses to completely re-invent the wheel in every project. I understand why you would find this weird. I don't start every project with nand gates. But the tendency is to use a library to check if a number is even or odd. It is a gradient, and you have to choose what you write and when you rely on a dependency. If you need to parse an XML file, or run HTTP requests, most likely you should find a library for it. But personally, if I can write it in 1-2 days, I always do it instead of adding a dependency. And I'm pretty sure it's worth it. > how do you find the time to fix all the extra bugs, the edge cases, the support for different versions of lower level dependencies, of different platforms If you take e.g. C++, maintaining your dependencies takes time. If you support multiple platforms, probably you need to (cross-)compile the dependencies. You should probably update them too (or at least check for security vulnerabilities), and updating dependencies brings its lot of issues (also in Rust: most libraries are 0.x.x and can break the API whenever they please). Then, if you miss a feature in the library, you're pretty much screwed: learning the codebase to contribute your feature may be a lot of work, and it may not be merged. Same for a bug (debugging a codebase that is not yours is harder). If you end up forking the dependency and having to live with a codebase you did not write, most likely it's better to write it yourself. The people advocating the "not re-inventing the wheel because NIH is really bad" philosophy seem to assume that libraries are always good. Now if you have a team of good developers, it may well be that the code they write is better than the average library out there. So if they write their features themselves, you end up with less but better code to maintain, and the people who understand that code work for you. Doesn't that sound good?
eddd-ddde 2y ago
If you can implement it in C++ with no dependencies, you can also just, do the same with rust. Like just don't add dependencies.
- palata 2y ago
  Obviously. But that's not what we are talking about here. I am saying that if I can implement it in C++ with few dependencies, I get tons of dependencies when doing the same in Rust. It's different.
patrick451 2y ago
I agree. It's really nice how few dependencies get pulled into a typical c++ project. When I started playing with rust, I was shocked at at how many dependencies got pulled in to just build hello world. I'm just not interested in adopting the npm left-pad model.
- pdimitar 2y ago
  While Rust projects unquestionably pull more dependency, there's zero of the left-pad culture in the community. It's simply pragmatism. And the OP is wrong about the terminal functionality by the way; stuff does actually change there still (sadly, though not very often). No point reacting to something that is almost disinformation.

by palata 2y ago

fxtentacle 2y ago

How is Debian / Ubuntu secure? It's signed by a maintainer. And maintainers are vetted. You trust Debian/Ubuntu to only allow trustworthy people to sign packages. How are Docker / Python / Rust secure? I don't know any of the people who created my docker images, PyPi packages, or Rust crates. Yes. We're basically back to sending around EXE and DLL files in a ZIP. It's just that now we call it a container and proudly start it as root. BTW, I agree with the author of the article: Sometimes you're best off just merging dependency source code. It used to be called "vendoring" and was a big thing in Rails / Ruby. The big advantage is that you're not affected by future malicious package takeovers. But you can still merge security patches from upstream, if you choose to do that.

tonyhart7 2y ago
You use in house solution??? any of these guys that want build something minimal dependency free is valid concern, I agree with that but but what if people just don't want that??? it given people jobs and things to do (lol, this is serious) also there are certain things better to use third party library than develop in house like crypto
akerl_ 2y ago
The vetting process for open source maintainers has very little overlap with the vetting process for “is this person trustworthy”. This is true for individual libraries and also for Linux distros.
liontwist 2y ago
> How is Debian / Ubuntu secure? You’re also forgetting process isolation and roles which provide strong invariants to control what a given package can do. No such guarantees exist for code you load into your process.
woodruffw 2y ago
I don’t follow this reasoning: you might trust this distribution packager to be honest, but this doesn’t stop them from honestly packaging malicious code. It’s unlikely that the typical distribution packager is reviewing more than a minority of the code in the packages they’re accepting, especially between updates. There are significant advantages to the distribution model, including exact provenance at the point of delivery. But I think it’s an error to treat it as uniquely trustworthy: it’s the same code either way.
- WhyNotHugo 2y ago
  "Trust" as two meanings in English: - You can trust someone as in "think they're honest and won't betray me". - You can trust someone as in "think they are competent and won't screw-up". In this case, we trust distributions packagers in both ways. Not only do we trust that they are non-malicious, we also trust that they won't clumsily package code without even skimming through it.
  - woodruffw 2y ago
    The point was not about competency. I think typical distribution packagers are very competent. "They won't screw up" is the wrong way to look at security: humans always screw up. We're essentially fallible. We would all do well to remember that the xz backdoor was not caught by distribution code review: it was caught due to a performance side effect that the next adversary will be more careful to avoid. Software stacks are getting bigger, largely due to engineering pressures that are outside of the control of distributions. It's a basic fact that that means work for the same (or fewer) people, which in turn means less time spent on more complicated packages. Under those conditions, competency is not the deciding factor. This is, separately, why having lots of little packages can be (but isn't necessarily) a good thing: small packages that decompose into well-understood units of work can be reviewed more quickly and comprehensively, and can be assigned capabilities that can be tracked and audited with static analysis. You can't do that as easily (or at all) when every package decides to hand-roll its own subcomponents.
    - 2y ago
KronisLV 2y ago
> How are Docker / Python / Rust secure? I don't know any of the people who created my docker images, PyPi packages, or Rust crates. I know who created the Docker images, because I'm the person who built them! A lot of the time you can build your images either from scratch, or based on the official base images like Alpine or Ubuntu/Debian or some of the RPM base images, not that much different than downloading an ISO for a VM. With a base, you can use apk/apt/dnf to get whatever packages you want if you trust that more, just remember to clean up the package cache so it's not persisted in the layers (arguably wastes space). For most software, it actually isn't as difficult as it might have initially seemed. As an alternative, you can also look for vaguely trustworthy parties that have a variety of prepackaged images available and you can either borrow their Dockerfiles or just trust their images, for example, https://bitnami.com/stacks/containers https://bitnami.com/stacks/containers and https://hub.docker.com/u/bitnami https://hub.docker.com/u/bitnami Most likely you have to have trust somewhere in the mix, for example, I'm probably installing the Debian/Ubuntu packaged JDK instead of compiling mine in most cases, just because that's more convenient. Also, rootless containers are pretty cool! People do like Podman and other solutions a lot, you can even do some remapping with Docker if there are issues with how the containers expect to be run https://docs.docker.com/engine/security/userns-remap/ https://docs.docker.com/engine/security/userns-remap/ or if you have to use Docker and need something a bit more serious you can try this https://docs.docker.com/engine/security/rootless/ https://docs.docker.com/engine/security/rootless/
rad_gruchalski 2y ago
> It's signed by a maintainer. And maintainers are vetted. You trust Debian/Ubuntu to only allow trustworthy people to sign packages. > How are Docker / Python / Rust secure? I don't know any of the people who created my docker images, PyPi packages, or Rust crates. Me neither. But the same goes for those from Debian/Ubuntu. In fact, neither I know anyone who vets those who sign and publish packages. What I know is that I can build my own images from container files and then I’m back to installing those apparently trusted packages from Debian/Ubuntu. > We're basically back to sending around EXE and DLL files in a ZIP. It's just that now we call it a container and proudly start it as root. I don’t get your point. And what’s an rpm or deb? You also potentially run stuff as root… sudo apt install -y… post install scripts…

jvanderbot 2y ago

So, the feature of "Here's a set of easily pulled libraries" is an anti-feature because it makes it easy to pull supporting libraries? I suspect this is actually about developers and not Rust or JS. Developers choose what dependencies to pull. If nobody pulled a dependency it would wither and die. There are a lot of dependencies for most libraries because most developers prefer to use dependencies to build something. But I digress. If we're talking build system, nobody is forcing you to use Crates.io with cargo, they just make it easy to. You can use path-based dependencies just like CMake/VCPkg,Conan, or you can DIY the library. Even with crates.io, nobody is forcing you to not use version pinning if you want to avoid churn, but they just make it easy to get latest. It's easy to build software on existing software in Rust. If you don't like the existing software or the rate it changes don't blame Cargo. Just do it the way you like it.

chrisco255 2y ago
[flagged]
- palata 2y ago
  > They also prefer languages with buffer overflow and use-after-free errors. Bad faith? My first sentence clearly says that I like the language, not the dependency situation.
- johnnyjeans 2y ago
  he literally said he likes rust as a programming language, so no. also it's not "optional" when it's the de-facto standard in the language. you lock yourself out of the broader tooling ecosystem. no language server, no libraries (because they all use cargo), etc. oftentimes you run into ergonomic problems with a language's module system because it's been hacked together in service of the enormous combo build/dependency management system rather than vice versa. you're running so far against the grain you might as well not use the language. this kind of passive-aggressive snark whenever someone leverages this very valid criticism is ridiculous
a-french-anon 2y ago
> because it makes it easy to pull supporting libraries? No, because it's used as an excuse for a lack of large(r) standard library. It's the equivalent of "the bazaar/free market will solve it!". You basically end up with a R5RS level of fragmentation and cruft outside your pristine small language; something that the Scheme community decided is not fun and prompted the idea of R6RS/R7RS-large. Yeah, it's hard to make a good, large and useful stdlib, but punting it to the outside world isn't a proper long-term solution either. It's really a combination of factors.

a-french-anon 2y ago

That's what I say when I converse about my colleagues: having a package manager from the start that greatly lowers the friction of adding or publishing yet another package deprives a language's ecosystem from something very useful: a good measure of natural selection. Add to that a free-for-all/no curation repository situation like pypi, npm or cargo together with a too small standard library and prepare to suffer.

XorNot 2y ago
I wonder how much of this is just the move away from shared libraries. In the .NET space nuget certainly makes it easy to add dependencies, but dependencies do seem to be overall fewer and the primary interesting difference I'd note is that a dependency is in fact it's own DLL file - to the extent that it's a feature that you can upgrade and replace them by dropping in a new file or changing configuration. It strikes me that we'd perhaps see far less churn like this if more languages were back to having shared libraries and ABI compatibility as a first class priority. Because then the value of stable ABIs and more limited selections of upgrades would be much higher.
- a-french-anon 2y ago
  The quest for performance makes macros, monomorphisation/specialization and LTO too attractive for simple dynamic linking to remain the norm, unfortunately. And in a way, I understand, a Stalin/MLton style whole-program optimizing compiler certainly is worth it when you have today's computing power.
  - funcDropShadow 2y ago
    Unless you have a very good JIT compiler, like JVMs. Than you can defer LTO and whole program optimization to runtime.

oersted 2y ago

This frankly sounds like a rationalization for an aesthetic preference. It is undeniable that being able to easily build on top of others' hard work is an enormous advantage in any domain. Duplicate work should only happen if you are confident that your requirements are significantly different, and that you can deliver an implementation as good as a team that has likely focused on the problem for much longer and has acquired a lot more know-how. It is true that such an attitude might be justifiable for certain security or performance critical applications, you might need end-to-end control. But even in those cases, the argument for trusting yourself by default over focused and experienced library authors is dubious. Either way, a good dependency manager opens the door for better auditing, analysis and tagging of dependencies, so that such critical requirements can be properly guaranteed, again probably better than you can do yourself.

palata 2y ago
> Duplicate work should only happen if you are confident that [...] You are making a ton of assumptions on the quality of the average library you can depend on: that a whole team worked on it, that it worked on it a long time and that it produced good code. That's really not a given. You are also assuming that writing a feature instead of using a library is "duplicate work". It's not necessarily the case. Maybe the library approaches the problem in a much more generic way than you need. Your requirements are not "significantly different" then, just a subset of the library. > so that such critical requirements can be properly guaranteed, again probably better than you can do yourself. Are you saying that the packages available in cargo are systematically audited? I believe that the vast majority of them is not audited at all.

lolinder 2y ago

There's a corollary here to "build it yourself", which is "vet it yourself". Cargo, npm, and pip all default to a central registry which you're encouraged to trust implicitly, but we've seen time and time again that central registries do not adequately protect against broken or malicious code that causes major security flaws downstream. Each of these ecosystems trains its developers to use hundreds of dependencies—far more than they can personally vet—with the understanding that someone else must surely have done so, even though we've seen over and over again that the staff of these registries can't actually keep up and that even long-running and popular projects can suddenly become insecure. I'd like to see an ecosystem develop that provides a small amount of convenience on top of plain old vendoring. No central repository to create a false sense of security. No overly clever version resolution scheme to hide the consequences of libraries depending on dozens of transitive dependencies. Just a minimal version resolution algorithm and a decentralized registry system—give each developer an index of their own libraries which they maintain and make downstream developers pick and choose which developers they actually trust. Maybe a bit like Maven if Maven Central didn't exist?

pdimitar 2y ago
Thought about it many times but never had the time or energy to tackle something as big and new. You?

Ygg2 2y ago

> In C++, I control my dependencies. In Rust I get above 100 so quickly I just Just don't add dependencies, it's that simple. If you have enough time to control C++ dependencies, you can control them in Rust as well.

lolinder 2y ago
That's not an answer when the entire ecosystem is built around the idea of adding lots of dependencies to do stuff. I don't need no dependencies, I'd like to live in a world where I can add two or three. But if the culture is so far gone that those two or three transitively import 20 each, I don't have that as an option—it's all or nothing.
- Ygg2 2y ago
  > That's not an answer when the entire ecosystem is built around the idea of adding lots of dependencies to do stuff. Again. Don't add dependencies. Just don't. Vendor it yourself. Or write it yourself. Absolutely nothing is forcing you to use the dependencies except your own desire to save time. Cargo is giving you the option to A) save your own time B) minimize dependencies. You choose A) and blame Cargo.
  - palata 2y ago
    I don't think it's entirely fair. You're telling me "don't use any dependency at all". Vendoring is not a solution, because it does not remove the transitive dependencies. So I have to essentially rewrite it myself. I find many libraries in C++ that don't pull 20 dependencies. It's common for me to have a C++ project that has ~6-8 dependencies. In Rust I have never seen that. Either I have no dependency at all, or I have 100+. I actually had this toy project that I wrote both in C++ and in Rust, for the learning experience. Both did exactly the same thing, with a very similar design. In C++ I had 8 dependencies. In Rust, 186. The thing is, 186 is enough for me to not even read all their names in the lock file. As soon as 25 dependencies magically appear in my lock file, I stop caring and start YOLOing it.
    - 2y ago

SkiFire13 2y ago

> People will complain that "it's hard to add a dependency to a C++ project" The way I see it the issue is that it's hard to add a dependency _in such a way that no people will have issues building your project with it_. This is problematic because even if you manage to make it work on your machine it may not work on some potential user or contributor's. > But that just destroys the OS package distribution model: when I choose a Linux distribution, I choose to trust those who build it. Distros still build Rust packages from sources and vendor crate dependencies in their repos. It's more painful because there are usually more dependencies with more updates, but this has nothing to do with shared libraries.

palata 2y ago
> The way I see it the issue is that it's hard to add a dependency _in such a way that no people will have issues building your project with it_. From my point of view, if it's done properly I can just build/install the dependency and use pkgconfig. Whenever I have a problem, it's because it was done wrong. Because many (most?) developers can't be arsed to learn how to do it properly; it's easier to just say that dependency management in C++ sucks.
- pdimitar 2y ago
  Taking pride in being willing to take the longer and more error-prone and tedious path makes me wonder if you're not just flexing here. There are thousands of tools and methodologies screaming for our attention to "be arsed to learn to do them properly". They're not owed that attention, they must deserve it. And statistically + historically speaking, most have failed to do so. You may choose to interpret this as you belonging to a small elite group of intellectuals who "are arsed to learn to do stuff properly" -- that's your right. I choose to interpret it as "Cargo solves a real problem that has wasted numerous hours of my time in the past". And it wasn't because, for the third time, "I wasn't arsed to learn to do it properly", it's because nobody followed basic protocol and good practices to make the legendary "proper way" work reliably. You're likely living and working in a bubble. It's much worse than the Wild West out there, man. Any tool that reduces the drudgery and allows for quicker doing of the annoying parts is a net positive.

LinXitoW 2y ago

I genuinely don't know what people with this opinion work on that they can so easily choose to completely re-invent the wheel in every project, just because they're afraid of hypothetical dangers. Most of which are still present for private re-implementations (like bugs). I cannot think of a single project where NIH syndrome would've been a net positive. Even dependencies that aren't "essential" are super helpful in saving time. When you recreate parts of an "optional" dependency for every single project, how do you find the time to fix all the extra bugs, the edge cases, the support for different versions of lower level dependencies, of different platforms?

palata 2y ago
> that they can so easily choose to completely re-invent the wheel in every project Nobody, and I mean 0, chooses to completely re-invent the wheel in every project. I understand why you would find this weird. I don't start every project with nand gates. But the tendency is to use a library to check if a number is even or odd. It is a gradient, and you have to choose what you write and when you rely on a dependency. If you need to parse an XML file, or run HTTP requests, most likely you should find a library for it. But personally, if I can write it in 1-2 days, I always do it instead of adding a dependency. And I'm pretty sure it's worth it. > how do you find the time to fix all the extra bugs, the edge cases, the support for different versions of lower level dependencies, of different platforms If you take e.g. C++, maintaining your dependencies takes time. If you support multiple platforms, probably you need to (cross-)compile the dependencies. You should probably update them too (or at least check for security vulnerabilities), and updating dependencies brings its lot of issues (also in Rust: most libraries are 0.x.x and can break the API whenever they please). Then, if you miss a feature in the library, you're pretty much screwed: learning the codebase to contribute your feature may be a lot of work, and it may not be merged. Same for a bug (debugging a codebase that is not yours is harder). If you end up forking the dependency and having to live with a codebase you did not write, most likely it's better to write it yourself. The people advocating the "not re-inventing the wheel because NIH is really bad" philosophy seem to assume that libraries are always good. Now if you have a team of good developers, it may well be that the code they write is better than the average library out there. So if they write their features themselves, you end up with less but better code to maintain, and the people who understand that code work for you. Doesn't that sound good?

eddd-ddde 2y ago

If you can implement it in C++ with no dependencies, you can also just, do the same with rust. Like just don't add dependencies.

palata 2y ago
Obviously. But that's not what we are talking about here. I am saying that if I can implement it in C++ with few dependencies, I get tons of dependencies when doing the same in Rust. It's different.

patrick451 2y ago

I agree. It's really nice how few dependencies get pulled into a typical c++ project. When I started playing with rust, I was shocked at at how many dependencies got pulled in to just build hello world. I'm just not interested in adopting the npm left-pad model.

pdimitar 2y ago
While Rust projects unquestionably pull more dependency, there's zero of the left-pad culture in the community. It's simply pragmatism. And the OP is wrong about the terminal functionality by the way; stuff does actually change there still (sadly, though not very often). No point reacting to something that is almost disinformation.