> there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x.

I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture.

IMO, it might be due to the fact that Go mod came rather late in the game, while NPM was introduced near the beginning of NodeJS. But it might be more related to Go's target audience being more low-level, where such tools are less ubiquitous?

▲

christophilus 4 hours ago | parent | next [-]

"A little duplication is better than a little dependency," -- Rob Pike

I think the culture was set from the top. Also, the fairly comprehensive standard library helps a lot. C# was in a similar boat back when I used it.

▲

cesarb 3 hours ago | parent | prev | next [-]

> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture.

I've also seen something similar with Java, with its culture of "pure Java" code which reimplements everything in Java instead of calling into preexisting native libraries. What's common between Java and Go is that they don't play well with native code; they really want to have full control of the process, which is made harder by code running outside their runtime environment.

▲

Icathian 2 hours ago | parent | prev | next [-]

Go sits at about the same level of abstraction as Python or Java, just with less OO baked in. I'm not sure where go's reputation as "low-level" comes from. I'd be curious to hear why that's the category you think of it in?

▲

Ajedi32 3 hours ago | parent | prev | next [-]

> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture.

I think it's because the final deliverable of Go projects is usually a single self-contained binary executable with no dependencies, whereas with Node the final deliverable is usually an NPM package which pulls its dependencies automatically.

▲

int_19h 2 hours ago | parent | next [-]

With Node the final deliverable is an app that comes packaged with all its dependencies, and often bundled into a single .js file, which is conceptually the same as a single binary produced by Go.

	▲	Ajedi32 2 hours ago \| parent [-]
		Can you give an example? While theoretically possible I almost never see that in Node projects. It's not even very practical because even if you do cram everything into a single .js file you still need an external dependency on the Node runtime.

▲

yunohn 3 hours ago | parent | prev [-]

> usually an NPM package which pulls its dependencies automatically

Built applications do not pull dependencies at runtime, just like with golang. If you want to use a library/source, you pull in all the deps, again just like golang.

	▲	Ajedi32 2 hours ago \| parent [-]
		Not at runtime no, but at install time yes. In contrast, with Go programs I often see "install time" being just `curl $url > /usr/local/bin/my_application` which is basically never the case with Node (for obvious reasons).

▲

johnisgood 4 hours ago | parent | prev [-]

C encourages such culture, too, FWIW.