← Back to context

Comment by tempay

1 day ago

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

14 comments

tempay

Reply
jaas  1 day ago

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.

  • zozbot234  1 day ago

    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.

    • traceroute66  1 day ago

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

      7 replies →

    • jen20  21 hours ago

      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.

tzekid  1 day ago

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)

  • diarrhea  19 hours ago

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