4 ms·

Such as?

• marcus_holmes 4y ago
  goimports, godoc and the other tools (https://pkg.go.dev/golang.org/x/tools https://pkg.go.dev/golang.org/x/tools - you basically can't use Go properly without these) all the crypto stuff (https://pkg.go.dev/golang.org/x/crypto https://pkg.go.dev/golang.org/x/crypto) if you're doing anything with crypto then this is needed others are really useful (see index at https://pkg.go.dev/golang.org/x https://pkg.go.dev/golang.org/x) - I've imported the image, sync and text packages it's a lot of the "missing bits" from the standard lib. I get why they're in /x but the distinction is moot in most cases.
  • tptacek 4y ago
    Almost nobody uses goimports or godoc as a declared dependency; they're tools, not standard library components. It's perfectly possible to implement cryptography without touching x/crypto; std includes SHA2, HMAC, an AEAD interface, ED25519, and, of course, Go's entire TLS stack. Arguably there's too much cryptography in std (almost nobody is better off directly building on cipher cores and signature algorithms). Thankfully: most Go programs don't implement cryptography, which is dangerous even with Go's relatively solid library interfaces.
    • marcus_holmes 4y ago
      I used the Go crypto primitives in /x to build a perfectly serviceable document encryption mechanism inside a document storage service. It was relatively painless and worked well. I can't really comment on how secure it ended up being - you can always build a crypto product that you can't break. The standard advice is always "never write your own crypto" and it's very good advice.