Go is still not good

> Rust crates re-introduces dependency hell and the potential for supply-chain attacks.

I’m only a casual user of both but how are rust crates meaningfully different from go’s dependency management?

I think it's because go's community sticks close to the standard library:

e.g. iirc. Rust has multiple ways of handling Strings while Go has (to a big extent) only one (thanks to the GC)

Go has a big, high quality standard library with most of what one might need. Means you have to bring in and manage (and trust) far fewer third party dependencies, and you can work faster because you’re not spending a bunch of time figuring out what the crate of the week is for basic functionality.

Rust intentionally chooses to have a small standard library to avoid the "dead batteries" problem. But the Rust community also maintains lists of "blessed" crates to try and cope with the issue of having to trust third-party software components of unknown quality.

> Rust intentionally chooses to have a small standard library to avoid the "dead batteries" problem.

There is a difference between "small" and Rust's which is for all intents and purposes, non-existent.

I mean, in 2025, not having crypto in stdlib when every man and his dog is using crypto ? Or http when every man and his dog are calling REST APIs ?

As the other person who replied to you said. Go just allows you to hit the ground running and get on with it.

Having to navigate the world of crates, unofficially "blessed" or not is just a bit of a re-inventing the wheel scenario really....

P.S. The Go stdlib is also well maintained, so I don't really buy the specific "dead batteries" claim either.

> I mean, in 2025, not having crypto in stdlib when every man and his dog is using crypto ? Or http when every man and his dog are calling REST APIs ?

I'm not and I'm glad the core team doesn't have to maintain an http server and can spend time on the low level features I chose Rust for.

I think having http in the standard library is a perfect example of the dead batteries problem: should the stdlib http also support QUIC and/or websockets? If you choose to include it, you've made stdlib include support for very specific use cases. If you choose not to include it, should the quic crate then extend or subsume the stdlib http implementation? If you choose subsume, you've created a dead battery. If you choose extend, you've created a maintenance nightmare by introducing a dependency between stdlib and an external crate.

Sorry but for most programming tasks I prefer having actual data containers with features than an HTTP library: Set, Tree, etc types. Those are fundamental CS building blocks yet are absent from the Go standard library. (well, they were added pretty recently, still nowhere near as featureful than std::collection in Rust).

Also, as mentioned by another comment, an HTTP or crypto library can become obsolete _fast_. What about HTTP3? What about post-quantum crypto? What about security fixes? The stdlib is tied to the language version, thus to a language release. Having such code independant allows is to evolve much faster, be leaner, and be more composable. So yes, the library is well maintained, but it's tied to the Go version.

Also, it enables breaking API changes if absolutely needed. I can name two precendents:

- in rust, time APIs in chrono had to be changed a few times, and the Rust maintainers were thankful it was not part of the stdlib, as it allowed massive changes

- otoh, in Go, it was found out that net.Ip has an absolutely atrocious design (it's just an alias for []byte). Tailscale wrote a replacement that's now in a subpackage in net, but the old net.Ip is set in stone. (https://tailscale.com/blog/netaddr-new-ip-type-for-go)

Do you think C and C++ should have http or crypto in their standard libraries?

What does String/OsSfeing have to do with garbage collection?

Different trade offs, both are fine.

The downside of a small stdlib is the proliferation of options, and you suddenly discover(ed?, it's been a minute) that your async package written for Tokio won't work on async-std and so forth.

This has often been the case in Go too - until `log/slog` existed, lots of people chose a structured logger and made it part of their API, forcing it on everyone else.

The go stdlib is well maintained and featureful because Google is very invested in it being both of those things for the use cases

That works well for go and Google but I'm not sure how easily that'd be to replicate with rust or others

Well crypt(3) is part of POSIX so…

> Rust has multiple ways of handling Strings

No, none outside of stdlib anyway in the way you're probably thinking of.

There are specialized constructs which live in third-party crates, such as rope implementations and stack-to-heap growable Strings, but those would have to exist as external modules in Go as well.

> Set, Tree, etc types. Those are fundamental CS building blocks

And if you're engaging in CS then Go is probably the last language you should be using. If however, what you're interested in doing is programming, the fundamental data structures there are arrays and hashmaps, which Go has built-in. Everything else is niche.

> Also, as mentioned by another comment, an HTTP or crypto library can become obsolete _fast_. What about HTTP3? What about post-quantum crypto? What about security fixes? The stdlib is tied to the language version, thus to a language release. Having such code independant allows is to evolve much faster, be leaner, and be more composable. So yes, the library is well maintained, but it's tied to the Go version.

The entire point is to have a well supported crypto library. Which Go does and it's always kept up to date. Including security fixes.

As for post-quantum: https://words.filippo.io/mlkem768/

> - otoh, in Go, it was found out that net.Ip has an absolutely atrocious design (it's just an alias for []byte). Tailscale wrote a replacement that's now in a subpackage in net, but the old net.Ip is set in stone. (https://tailscale.com/blog/netaddr-new-ip-type-for-go)

Yes, and? This seems to me to be the perfect way to handle things - at all times there is a blessed high-quality library to use. As warts of its design get found out over time, a new version is worked on and released once every ~10 years.

A total mess of barely-supported libraries that the userbase is split over is just that - a mess.

It would be nice if folks linked crates up into ecosystems thst shared maintainers and guidelines. We don't need everyone using the same stuff, but I'd rather prefer to get 10 different dependences rather than 30. In c++ this plays out in libraries like absl, folly, boost and others. Fewer larger dependencies that bring in a mix of functionality.