5 ms·

This is spot on. I am extremely uncomfortable with the large number of transitive dependencies that end up in pretty much any non-trivial rust application. No a

This is spot on. I am extremely uncomfortable with the large number of transitive dependencies that end up in pretty much any non-trivial rust application. No amount of memory safety will save us if a tiny, ubiquitous library that nobody scrutinizes because it’s nested eight layers down the dependency graph gets compromised. I think Go apps tend to have better dependency hygiene because the language has a better standard library, which results in better culture around dependencies. I also think it’s frustrating that both cargo and npm totally ignore the decades of prior art from Linux distributions that have figured out good ways to improve dependency management. We’d be in better shape if there was a community curated subset of known-good dependencies that are release-managed together that the broader ecosystem could build on, sort of like Ubuntu having “main” and “universe”.

__david__ 1mo ago
I think Go ends up with fewer dependencies mostly because there is more friction in finding them. With rust (and npm) you just "cargo search xxx", then "cargo add xxx". Go makes you web search and poke around github looking for something. It's not onerous or anything, but just that extra step slows things down just a bit. C projects tend to have the least because it's even more annoying to add them and you have to create build commands that deal with slightly different distributions (and learn makefile+pkg-config or cmake, or autoconf). Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason.
- teach 1mo ago
  Actually I think this is more of a culture thing. Or maybe "is also" a culture thing. One of the core tenets of early Go was the maxim "a little copying is better than a little dependency". Probably because of this stance, they didn't even HAVE a dependency-management solution for years I strongly agree the fewer dependencies the better, on average.
  - cogman10 1mo ago
    I agree. Java has the same ability to quickly add deps, and in some case they can be sprawling, but it's still perfectly possible to develop complex apps without a lot of deps coming in. Culture has a lot to do with it.
    - vips7L 1mo ago
      Does it? The only think I can think of not being in the standard library is a json parser
  - __david__ 1mo ago
    Perhaps, but I think it depends on where the Go devs are coming from. In my experience the lack of proper dependency management in older versions of Go didn't really lessen dependencies, it just made teams have to deal with annoying $GOSRC issues. But then I worked at a place where the devs used PHP (w/composer) and node before Go was introduced. Personally I came from a C background so I tended to use deps more sparingly. In the end it's a bit of a balancing act—lots of dependencies is a larger opportunity for these kind of supply chain attacks to affect you. Copying stuff into your repo protects you from that, but it also makes it way more likely that you'll miss security fixes, unless you're actively looking for them. Re-implementing what you need is also viable but it slows down the dev process.
  - 0rzech 1mo ago
    It absolutely is a culture thing. I've seen many threads asking about backend frameworks in Go, and every time there were lots of answers akin to "screw framework dependencies, stdlib is more than enough".
- overfeed 1mo ago
  > Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason I disagree: having a big stdlib that encompasses a huge chunk of common functionality (logging, a plethora of network server/client protocols, etc) means that for basic needs, the question of 3rd party libs never arise, whereas for other language, the question is not if you need a dep, but which one. Making gorilla easier to find won't undo the cultural reluctance of adding a 3rd party dep when using the (very pragmatic, IMO) stdlib server is adequate to the task.
- saturn_vk 1mo ago
  Go has an official package search at https://pkg.go.dev/ https://pkg.go.dev/ There’s no poking, unless you are into that sort of thing
- kelnos 1mo ago
  I don't really agree. You reach for a dependency when you need to do something non-trivial and the stdlib doesn't have what you need (or the stdlib implementation is bad). You don't just sit around running `cargo search` for fun. I think the ease of adding dependencies does drive the idea of "microdependencies", where you have many dependencies that do one little thing, and then those dependencies likely have their own small dependencies. Whereas in the C world, you'll probably have a smaller number of dependencies, but it's likely that some of them are very big dependencies that offer a lot of functionality (like glib, for example). I could maybe see the argument that ease of adding dependencies discourages people from writing small things themselves. Good ol' left-pad comes to mind. In an ecosystem like C, I'd just write that algorithm myself, over and over and over, because pulling in a dep just for that feels annoying.
- e2le 1mo ago
  > Go makes you web search and poke around github looking for something. I'm not sure that's a bad thing. I suspect with increased friction, users are more likely to scrutinise dependencies before importing them.
CrimsonCape 1mo ago
I learned programming from C# which has an excellent standard library. Just recently started using Go which seems to have a good standard library. Been using python for years, can't say I ever had a complaint about the standard library. Rust meanwhile seems to be following some "no standard library" philosophy. I feel like there's an opportunity out there to become like an amoeba: fund and build a third party Rust standard library, absorb absolutely everyone who is so grateful to have a library, and then get so big absorb Rust itself.
- ModernMech 1mo ago
  > Rust meanwhile seems to be following some "no standard library" philosophy. As an embedded dev, I personally find it very useful to compile Rust programs without a standard library. I would not use C# or Python for an embedded project for the reasons you probably prefer them for your projects.
  - CrimsonCape 1mo ago
    The guide that NASA put out for spaceflight systems was on HN earlier this year and one of the rules is "no heap allocations; all memory must be declared and fixed size for the life of the app." Isn't Rust the ideal language for that kind of limitation? We are talking C, C++, Rust, Zig as options I would guess; Rust certainly seems the ideal from those options. But you gotta admit people trying to build GUI libraries and using linked lists don't fit.
sunshowers 1mo ago
Every Rust crate is heavily scrutinized these days using LLMs (which also caught this issue). The days when no one looked at dependencies are gone.
- stubish 1mo ago
  At upload time? Or by every client at download time? Or just adhoc by random users? This does sound like an excellent way of improving automated package checks, even if it does result in some false positives and false negatives. For all sorts of packages, not just code dependencies.
  - sunshowers 1mo ago
    By security scanners, the moment a crate is uploaded to crates.io. The way forward here is dependency cooldowns enabled by default for ordinary users (and crates.io changed to show the old version until the new one is a day or two old). Essentially, security scanners get to vet a package for a day or two before ordinary users see it in everyday development.
TZubiri 1mo ago
If those transitive dependencies are baked into the language runtime, how is anything materially different? You just shift the vector around.
- atiedebee 1mo ago
  Because the standard library of a programming language has a lot more eyes on it than one of the many small dependencies does.
  - TZubiri 1mo ago
    You are just shifting where the eyes are, the amount of eyeballs (developer time) is the same. Unless the proposal is to increase the amount of (other) developers time. The proposal ends up amounting to either shifting stuff around, or asking to other people to put in more effort? Into a project that usually doesn't pay (programming languages and runtimes) Which by the way, asking other people to do stuff for free IS the attack vector, if you are the kind of dev or company that gets hit by these, your ultimate root cause is that your business strategy is using code without paying for it. No such thing as a free lunch, you will pay for it, among other things, with an increased cybersecurity risk.
- 0rzech 1mo ago
  There are more differences. Packages can release updates arbitrarily, while standard libraries tend to have longer release cadences. It's also more difficult to put arbitrary code into an stdlib, because stdlibs are scrutinized better. Also, it's harder for some random anonymous developer to gain push access to stdlib repository. One of the reasons so much Rust code is in libraries is not because there are no people to write it (duh), but because putting these in std commits maintainers to keeping backwards compatibility and slows down included package's release cycle.
cloudfudge 1mo ago
I think one thing that has made Go have better dependency hygiene is not merely having "batteries included" in the standard lib, but the early focus on having production-ready implementations of a lot of stuff in the standard lib, as opposed to minimum viable implementations. I used to get a long way with one or two dependencies that would barely fan out at all. It's been a while since I worked on a Go project, so I'm not sure if it's still that way.
- lovehashbrowns 1mo ago
  I think having production-grade implementations makes a huge difference also. Go’s net/http in the std lib feels like a good example of that, though I’m fairly new to go still. But it seems net/http still gets pretty big updates despite something like Chi being available as an external lib. Odin is doing this as well, even including raylib in the std lib. Odin is even more primed to keep you on the std lib as it doesn’t include a package manager at all.
  - thatspartan 1mo ago
    So I went to have a look at Odin and was mind blown at the lispiness in the hellope example. A list of operators defined as "program"; that are applied to the accumulator then printed. It's a striking first impression for me and I want to see what the Odin people have cooked up.
    - a-french-anon 1mo ago
      I wasn't when I saw they made the exact same stupid error as Python: if and switch are statements, so that you need a stupid ternary operator to do the same.
    - lovehashbrowns 1mo ago
      Odin has been a masterpiece so far! Ginger Bill has a massive update coming in for it Jan 2027 as well. :) I think it's definitely going to take off in the next few years.

__david__ 1mo ago

I think Go ends up with fewer dependencies mostly because there is more friction in finding them. With rust (and npm) you just "cargo search xxx", then "cargo add xxx". Go makes you web search and poke around github looking for something. It's not onerous or anything, but just that extra step slows things down just a bit. C projects tend to have the least because it's even more annoying to add them and you have to create build commands that deal with slightly different distributions (and learn makefile+pkg-config or cmake, or autoconf). Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason.

teach 1mo ago
Actually I think this is more of a culture thing. Or maybe "is also" a culture thing. One of the core tenets of early Go was the maxim "a little copying is better than a little dependency". Probably because of this stance, they didn't even HAVE a dependency-management solution for years I strongly agree the fewer dependencies the better, on average.
- cogman10 1mo ago
  I agree. Java has the same ability to quickly add deps, and in some case they can be sprawling, but it's still perfectly possible to develop complex apps without a lot of deps coming in. Culture has a lot to do with it.
  - vips7L 1mo ago
    Does it? The only think I can think of not being in the standard library is a json parser
- __david__ 1mo ago
  Perhaps, but I think it depends on where the Go devs are coming from. In my experience the lack of proper dependency management in older versions of Go didn't really lessen dependencies, it just made teams have to deal with annoying $GOSRC issues. But then I worked at a place where the devs used PHP (w/composer) and node before Go was introduced. Personally I came from a C background so I tended to use deps more sparingly. In the end it's a bit of a balancing act—lots of dependencies is a larger opportunity for these kind of supply chain attacks to affect you. Copying stuff into your repo protects you from that, but it also makes it way more likely that you'll miss security fixes, unless you're actively looking for them. Re-implementing what you need is also viable but it slows down the dev process.
- 0rzech 1mo ago
  It absolutely is a culture thing. I've seen many threads asking about backend frameworks in Go, and every time there were lots of answers akin to "screw framework dependencies, stdlib is more than enough".
overfeed 1mo ago
> Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason I disagree: having a big stdlib that encompasses a huge chunk of common functionality (logging, a plethora of network server/client protocols, etc) means that for basic needs, the question of 3rd party libs never arise, whereas for other language, the question is not if you need a dep, but which one. Making gorilla easier to find won't undo the cultural reluctance of adding a 3rd party dep when using the (very pragmatic, IMO) stdlib server is adequate to the task.
saturn_vk 1mo ago
Go has an official package search at https://pkg.go.dev/ https://pkg.go.dev/ There’s no poking, unless you are into that sort of thing
kelnos 1mo ago
I don't really agree. You reach for a dependency when you need to do something non-trivial and the stdlib doesn't have what you need (or the stdlib implementation is bad). You don't just sit around running `cargo search` for fun. I think the ease of adding dependencies does drive the idea of "microdependencies", where you have many dependencies that do one little thing, and then those dependencies likely have their own small dependencies. Whereas in the C world, you'll probably have a smaller number of dependencies, but it's likely that some of them are very big dependencies that offer a lot of functionality (like glib, for example). I could maybe see the argument that ease of adding dependencies discourages people from writing small things themselves. Good ol' left-pad comes to mind. In an ecosystem like C, I'd just write that algorithm myself, over and over and over, because pulling in a dep just for that feels annoying.
e2le 1mo ago
> Go makes you web search and poke around github looking for something. I'm not sure that's a bad thing. I suspect with increased friction, users are more likely to scrutinise dependencies before importing them.

CrimsonCape 1mo ago

I learned programming from C# which has an excellent standard library. Just recently started using Go which seems to have a good standard library. Been using python for years, can't say I ever had a complaint about the standard library. Rust meanwhile seems to be following some "no standard library" philosophy. I feel like there's an opportunity out there to become like an amoeba: fund and build a third party Rust standard library, absorb absolutely everyone who is so grateful to have a library, and then get so big absorb Rust itself.

ModernMech 1mo ago
> Rust meanwhile seems to be following some "no standard library" philosophy. As an embedded dev, I personally find it very useful to compile Rust programs without a standard library. I would not use C# or Python for an embedded project for the reasons you probably prefer them for your projects.
- CrimsonCape 1mo ago
  The guide that NASA put out for spaceflight systems was on HN earlier this year and one of the rules is "no heap allocations; all memory must be declared and fixed size for the life of the app." Isn't Rust the ideal language for that kind of limitation? We are talking C, C++, Rust, Zig as options I would guess; Rust certainly seems the ideal from those options. But you gotta admit people trying to build GUI libraries and using linked lists don't fit.

sunshowers 1mo ago

Every Rust crate is heavily scrutinized these days using LLMs (which also caught this issue). The days when no one looked at dependencies are gone.

stubish 1mo ago
At upload time? Or by every client at download time? Or just adhoc by random users? This does sound like an excellent way of improving automated package checks, even if it does result in some false positives and false negatives. For all sorts of packages, not just code dependencies.
- sunshowers 1mo ago
  By security scanners, the moment a crate is uploaded to crates.io. The way forward here is dependency cooldowns enabled by default for ordinary users (and crates.io changed to show the old version until the new one is a day or two old). Essentially, security scanners get to vet a package for a day or two before ordinary users see it in everyday development.

TZubiri 1mo ago

If those transitive dependencies are baked into the language runtime, how is anything materially different? You just shift the vector around.

atiedebee 1mo ago
Because the standard library of a programming language has a lot more eyes on it than one of the many small dependencies does.
- TZubiri 1mo ago
  You are just shifting where the eyes are, the amount of eyeballs (developer time) is the same. Unless the proposal is to increase the amount of (other) developers time. The proposal ends up amounting to either shifting stuff around, or asking to other people to put in more effort? Into a project that usually doesn't pay (programming languages and runtimes) Which by the way, asking other people to do stuff for free IS the attack vector, if you are the kind of dev or company that gets hit by these, your ultimate root cause is that your business strategy is using code without paying for it. No such thing as a free lunch, you will pay for it, among other things, with an increased cybersecurity risk.
0rzech 1mo ago
There are more differences. Packages can release updates arbitrarily, while standard libraries tend to have longer release cadences. It's also more difficult to put arbitrary code into an stdlib, because stdlibs are scrutinized better. Also, it's harder for some random anonymous developer to gain push access to stdlib repository. One of the reasons so much Rust code is in libraries is not because there are no people to write it (duh), but because putting these in std commits maintainers to keeping backwards compatibility and slows down included package's release cycle.

cloudfudge 1mo ago

I think one thing that has made Go have better dependency hygiene is not merely having "batteries included" in the standard lib, but the early focus on having production-ready implementations of a lot of stuff in the standard lib, as opposed to minimum viable implementations. I used to get a long way with one or two dependencies that would barely fan out at all. It's been a while since I worked on a Go project, so I'm not sure if it's still that way.

lovehashbrowns 1mo ago
I think having production-grade implementations makes a huge difference also. Go’s net/http in the std lib feels like a good example of that, though I’m fairly new to go still. But it seems net/http still gets pretty big updates despite something like Chi being available as an external lib. Odin is doing this as well, even including raylib in the std lib. Odin is even more primed to keep you on the std lib as it doesn’t include a package manager at all.
- thatspartan 1mo ago
  So I went to have a look at Odin and was mind blown at the lispiness in the hellope example. A list of operators defined as "program"; that are applied to the accumulator then printed. It's a striking first impression for me and I want to see what the Odin people have cooked up.
  - a-french-anon 1mo ago
    I wasn't when I saw they made the exact same stupid error as Python: if and switch are statements, so that you need a stupid ternary operator to do the same.
  - lovehashbrowns 1mo ago
    Odin has been a masterpiece so far! Ginger Bill has a massive update coming in for it Jan 2027 as well. :) I think it's definitely going to take off in the next few years.