[juliend2]

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

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

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

[kelnos]

I think it's important for managed/safe languages to have their own implementations of things, and avoid dropping down into C/C++ code unless absolutely necessary.

~13 years ago I needed to do DTLS (TLS-over-UDP) from a Java backend, something that would be exposed to the public internet. There were exactly zero Java DTLS implementations at the time, so I chose to write JNI bindings to OpenSSL. I was very unhappy with this: my choices were to 1) accept that my service could now segfault -- possibly in an exploitable way -- if there was a bug in my bindings or in OpenSSL's (not super well tested) DTLS code, or 2) write my own DTLS implementation in Java, and virtually guarantee I'd get something wrong and break it cryptographically.

These were not great choices, and I wished I had a Java DTLS implementation to use.

This is why in my Rust projects, I generally prefer to tell my dependencies to use rustls over native (usually OpenSSL) TLS when there's an option between the two. All the safety guarantees of my chosen language just disappear whenever I have to call out to a C library. Sure, now I have to worry about rustls having bugs (as a much less mature implementation), but at least in this case there are people working on it who actually know things about cryptography and security that I don't, and they've had third-party audits that give me more confidence.

[Ajedi32]

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

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.

[yunohn]

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

[johnisgood]

C encourages such culture, too, FWIW.

[Icathian]

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?

[cookiengineer]

I'd argue that Go is somewhere in between static C and memory safe VM languages, because the compiler always tries to "monomorphize" everything as much as possible.

Generic methods are somewhat an antipattern to how the language was designed from the start. That is kind of the reason they're not there yet, because Go maintainers don't want boxing in their runtime, and also don't want compile time expansions (or JIT compilation for that matter).

So I'd argue that this way of handling compilation is more low level than other VM based languages where almost everything is JITed now.