4 ms·

effectively the same place at this point. There's so many "standard" libs in /x that trying to constraint to "just the standard lib" has to include /x to be act

effectively the same place at this point. There's so many "standard" libs in /x that trying to constraint to "just the standard lib" has to include /x to be actually useful.

tptacek 4y ago
They're not at all effectively the same place, and much of what's in /x competes with third-party packages, which are on a somewhat level playing field in that both /x and third-party code have to be explicitly brought in to a project as a dep.
- marcus_holmes 4y ago
  meh, I'm always going to prefer an /x package to a 3rd-party package.
philosopher1234 4y ago
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.

effectively the same place at this point. There's so many "standard" libs in /x that trying to constraint to "just the standard lib" has to include /x to be actually useful.

tptacek 4y ago

They're not at all effectively the same place, and much of what's in /x competes with third-party packages, which are on a somewhat level playing field in that both /x and third-party code have to be explicitly brought in to a project as a dep.

marcus_holmes 4y ago
meh, I'm always going to prefer an /x package to a 3rd-party package.

philosopher1234 4y ago

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.