alt Hacker NewsI 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.
Replies
> 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.
Go has an official package search at https://pkg.go.dev/
There’s no poking, unless you are into that sort of thing
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.