Hacker News Reader

Comment by __david__ | Hacker News Reader

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.

View on HN

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.

> 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.

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.

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.

Does it? The only think I can think of not being in the standard library is a json parser

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.

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".

Go has an official package search at https://pkg.go.dev/

There’s no poking, unless you are into that sort of thing

> 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.

Reply on news.ycombinator.com