chore: Update external Go links (#207)

* chore: Update external Go links

* Auto-update style.md

---------

Co-authored-by: vorobeyme <vorobeyme@users.noreply.github.com>

src/atomic.md

@@ -7,8 +7,8 @@ read or modify the variables.
 [go.uber.org/atomic] adds type safety to these operations by hiding the
 underlying type. Additionally, it includes a convenient `atomic.Bool` type.
 
-  [go.uber.org/atomic]: https://godoc.org/go.uber.org/atomic
-  [sync/atomic]: https://golang.org/pkg/sync/atomic/
+  [go.uber.org/atomic]: https://pkg.go.dev/go.uber.org/atomic
+  [sync/atomic]: https://pkg.go.dev/sync/atomic
 
 <table>
 <thead><tr><th>Bad</th><th>Good</th></tr></thead>

src/builtin-name.md

@@ -8,8 +8,8 @@ the original within the current lexical scope (and any nested scopes) or make
 affected code confusing. In the best case, the compiler will complain; in the
 worst case, such code may introduce latent, hard-to-grep bugs.
 
-  [language specification]: https://golang.org/ref/spec
-  [predeclared identifiers]: https://golang.org/ref/spec#Predeclared_identifiers
+  [language specification]: https://go.dev/ref/spec
+  [predeclared identifiers]: https://go.dev/ref/spec#Predeclared_identifiers
 
 <table>
 <thead><tr><th>Bad</th><th>Good</th></tr></thead>

src/embed-public.md

@@ -62,7 +62,7 @@ The outer type gets implicit copies of the embedded type's methods.
 These methods, by default, delegate to the same method of the embedded
 instance.
 
-  [type embedding]: https://golang.org/doc/effective_go.html#embedding
+  [type embedding]: https://go.dev/doc/effective_go#embedding
 
 The struct also gains a field by the same name as the type.
 So, if the embedded type is public, the field is public.

src/error-type.md

@@ -13,8 +13,8 @@ Consider the following before picking the option best suited for your use case.
 - Are we propagating a new error returned by a downstream function?
   If so, see the [section on error wrapping](error-wrap.md).
 
-[`errors.Is`]: https://golang.org/pkg/errors/#Is
-[`errors.As`]: https://golang.org/pkg/errors/#As
+[`errors.Is`]: https://pkg.go.dev/errors#Is
+[`errors.As`]: https://pkg.go.dev/errors#As
 
 | Error matching? | Error Message | Guidance                            |
 |-----------------|---------------|-------------------------------------|
@@ -23,8 +23,8 @@ Consider the following before picking the option best suited for your use case.
 | Yes             | static        | top-level `var` with [`errors.New`] |
 | Yes             | dynamic       | custom `error` type                 |
 
-[`errors.New`]: https://golang.org/pkg/errors/#New
-[`fmt.Errorf`]: https://golang.org/pkg/fmt/#Errorf
+[`errors.New`]: https://pkg.go.dev/errors#New
+[`fmt.Errorf`]: https://pkg.go.dev/fmt#Errorf
 
 For example,
 use [`errors.New`] for an error with a static string.

src/exit-main.md

@@ -3,8 +3,8 @@
 Go programs use [`os.Exit`] or [`log.Fatal*`] to exit immediately. (Panicking
 is not a good way to exit programs, please [don't panic](panic.md).)
 
-  [`os.Exit`]: https://golang.org/pkg/os/#Exit
-  [`log.Fatal*`]: https://golang.org/pkg/log/#Fatal
+  [`os.Exit`]: https://pkg.go.dev/os#Exit
+  [`log.Fatal*`]: https://pkg.go.dev/log#Fatal
 
 Call one of `os.Exit` or `log.Fatal*` **only in `main()`**. All other
 functions should return errors to signal failure.

src/function-name.md

@@ -5,4 +5,4 @@ names]. An exception is made for test functions, which may contain underscores
 for the purpose of grouping related test cases, e.g.,
 `TestMyFunction_WhatIsBeingTested`.
 
-  [MixedCaps for function names]: https://golang.org/doc/effective_go.html#mixed-caps
+  [MixedCaps for function names]: https://go.dev/doc/effective_go#mixed-caps

src/interface-receiver.md

@@ -3,7 +3,7 @@
 Methods with value receivers can be called on pointers as well as values.
 Methods with pointer receivers can only be called on pointers or [addressable values].
 
-  [addressable values]: https://golang.org/ref/spec#Method_values
+  [addressable values]: https://go.dev/ref/spec#Method_values
 
 For example,
 
@@ -75,4 +75,4 @@ i = s2Ptr
 
 Effective Go has a good write up on [Pointers vs. Values].
 
-  [Pointers vs. Values]: https://golang.org/doc/effective_go.html#pointers_vs_values
+  [Pointers vs. Values]: https://go.dev/doc/effective_go#pointers_vs_values

src/intro.md

@@ -20,9 +20,9 @@ This documents idiomatic conventions in Go code that we follow at Uber. A lot
 of these are general guidelines for Go, while others extend upon external
 resources:
 
-1. [Effective Go](https://golang.org/doc/effective_go.html)
-2. [Go Common Mistakes](https://github.com/golang/go/wiki/CommonMistakes)
-3. [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments)
+1. [Effective Go](https://go.dev/doc/effective_go)
+2. [Go Common Mistakes](https://go.dev/wiki/CommonMistakes)
+3. [Go Code Review Comments](https://go.dev/wiki/CodeReviewComments)
 
 We aim for the code samples to be accurate for the two most recent minor versions
 of Go [releases](https://go.dev/doc/devel/release).
@@ -34,4 +34,4 @@ recommend setting up your editor to:
 - Run `golint` and `go vet` to check for errors
 
 You can find information in editor support for Go tools here:
-<https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins>
+<https://go.dev/wiki/IDEsAndTextEditorPlugins>

src/lint.md

@@ -14,10 +14,10 @@ quality without being unnecessarily prescriptive:
 - [staticcheck] to do various static analysis checks
 
   [errcheck]: https://github.com/kisielk/errcheck
-  [goimports]: https://godoc.org/golang.org/x/tools/cmd/goimports
+  [goimports]: https://pkg.go.dev/golang.org/x/tools/cmd/goimports
   [golint]: https://github.com/golang/lint
-  [govet]: https://golang.org/cmd/vet/
-  [staticcheck]: https://staticcheck.io/
+  [govet]: https://pkg.go.dev/cmd/vet
+  [staticcheck]: https://staticcheck.dev
 
 ## Lint Runners
 

src/package-name.md

@@ -11,5 +11,5 @@ When naming packages, choose a name that is:
 
 See also [Package Names] and [Style guideline for Go packages].
 
-  [Package Names]: https://blog.golang.org/package-names
+  [Package Names]: https://go.dev/blog/package-names
   [Style guideline for Go packages]: https://rakyll.org/style-packages/

src/printf-name.md

@@ -7,7 +7,7 @@ This means that you should use predefined `Printf`-style function
 names if possible. `go vet` will check these by default. See [Printf family]
 for more information.
 
-  [Printf family]: https://golang.org/cmd/vet/#hdr-Printf_family
+  [Printf family]: https://pkg.go.dev/cmd/vet#hdr-Printf_family
 
 If using the predefined names is not an option, end the name you choose with
 f: `Wrapf`, not `Wrap`. `go vet` can be asked to check specific `Printf`-style

src/string-escape.md

@@ -1,6 +1,6 @@
 # Use Raw String Literals to Avoid Escaping
 
-Go supports [raw string literals](https://golang.org/ref/spec#raw_string_lit),
+Go supports [raw string literals](https://go.dev/ref/spec#raw_string_lit),
 which can span multiple lines and include quotes. Use these to avoid
 hand-escaped strings which are much harder to read.
 

src/struct-embed.md

@@ -31,12 +31,9 @@ type Client struct {
 
 Embedding should provide tangible benefit, like adding or augmenting
 functionality in a semantically-appropriate way. It should do this with zero
-adverse user-facing effects (see also: [Avoid Embedding Types in Public Structs]).
+adverse user-facing effects (see also: [Avoid Embedding Types in Public Structs](embed-public.md)).
 
-Exception: Mutexes should not be embedded, even on unexported types. See also: [Zero-value Mutexes are Valid].
-
-  [Avoid Embedding Types in Public Structs]: #avoid-embedding-types-in-public-structs
-  [Zero-value Mutexes are Valid]: #zero-value-mutexes-are-valid
+Exception: Mutexes should not be embedded, even on unexported types. See also: [Zero-value Mutexes are Valid](mutex-zero-value.md).
 
 Embedding **should not**:
 

src/struct-field-key.md

@@ -3,7 +3,7 @@
 You should almost always specify field names when initializing structs. This is
 now enforced by [`go vet`].
 
-  [`go vet`]: https://golang.org/cmd/vet/
+  [`go vet`]: https://pkg.go.dev/cmd/vet
 
 <table>
 <thead><tr><th>Bad</th><th>Good</th></tr></thead>

src/struct-zero.md

@@ -22,8 +22,7 @@ var user User
 </tbody></table>
 
 This differentiates zero valued structs from those with non-zero fields
-similar to the distinction created for [map initialization], and matches how
+similar to the distinction created for [map initialization](map-init.md), and matches how
 we prefer to [declare empty slices].
 
-  [map initialization]: #initializing-maps
-  [declare empty slices]: https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices
+  [declare empty slices]: https://go.dev/wiki/CodeReviewComments#declaring-empty-slices

src/test-table.md

@@ -7,7 +7,7 @@ If a system under test needs to be tested against _multiple conditions_ where
 certain parts of the the inputs and outputs change, a table-driven test should
 be used to reduce redundancy and improve readability.
 
-  [subtests]: https://blog.golang.org/subtests
+  [subtests]: https://go.dev/blog/subtests
 
 <table>
 <thead><tr><th>Bad</th><th>Good</th></tr></thead>

src/time.md

@@ -15,14 +15,14 @@ yield a new calendar day.
 Therefore, always use the [`"time"`] package when dealing with time because it
 helps deal with these incorrect assumptions in a safer, more accurate manner.
 
-  [`"time"`]: https://golang.org/pkg/time/
+  [`"time"`]: https://pkg.go.dev/time
 
 ## Use `time.Time` for instants of time
 
 Use [`time.Time`] when dealing with instants of time, and the methods on
 `time.Time` when comparing, adding, or subtracting time.
 
-  [`time.Time`]: https://golang.org/pkg/time/#Time
+  [`time.Time`]: https://pkg.go.dev/time#Time
 
 <table>
 <thead><tr><th>Bad</th><th>Good</th></tr></thead>
@@ -50,7 +50,7 @@ func isActive(now, start, stop time.Time) bool {
 
 Use [`time.Duration`] when dealing with periods of time.
 
-  [`time.Duration`]: https://golang.org/pkg/time/#Duration
+  [`time.Duration`]: https://pkg.go.dev/time#Duration
 
 <table>
 <thead><tr><th>Bad</th><th>Good</th></tr></thead>
@@ -90,8 +90,8 @@ the next calendar day, we should use [`Time.AddDate`]. However, if we want an
 instant of time guaranteed to be 24 hours after the previous time, we should
 use [`Time.Add`].
 
-  [`Time.AddDate`]: https://golang.org/pkg/time/#Time.AddDate
-  [`Time.Add`]: https://golang.org/pkg/time/#Time.Add
+  [`Time.AddDate`]: https://pkg.go.dev/time#Time.AddDate
+  [`Time.Add`]: https://pkg.go.dev/time#Time.Add
 
 ```go
 newDay := t.AddDate(0 /* years */, 0 /* months */, 1 /* days */)
@@ -112,13 +112,13 @@ possible. For example:
 - YAML: [`gopkg.in/yaml.v2`] supports `time.Time` as an [RFC 3339] string, and
   `time.Duration` via [`time.ParseDuration`].
 
-  [`flag`]: https://golang.org/pkg/flag/
-  [`time.ParseDuration`]: https://golang.org/pkg/time/#ParseDuration
-  [`encoding/json`]: https://golang.org/pkg/encoding/json/
+  [`flag`]: https://pkg.go.dev/flag
+  [`time.ParseDuration`]: https://pkg.go.dev/time#ParseDuration
+  [`encoding/json`]: https://pkg.go.dev/encoding/json
   [RFC 3339]: https://tools.ietf.org/html/rfc3339
-  [`UnmarshalJSON` method]: https://golang.org/pkg/time/#Time.UnmarshalJSON
-  [`database/sql`]: https://golang.org/pkg/database/sql/
-  [`gopkg.in/yaml.v2`]: https://godoc.org/gopkg.in/yaml.v2
+  [`UnmarshalJSON` method]: https://pkg.go.dev/time#Time.UnmarshalJSON
+  [`database/sql`]: https://pkg.go.dev/database/sql
+  [`gopkg.in/yaml.v2`]: https://pkg.go.dev/gopkg.in/yaml.v2
 
 When it is not possible to use `time.Duration` in these interactions, use
 `int` or `float64` and include the unit in the name of the field.
@@ -155,8 +155,8 @@ alternative is agreed upon, use `string` and format timestamps as defined in
 [RFC 3339]. This format is used by default by [`Time.UnmarshalText`] and is
 available for use in `Time.Format` and `time.Parse` via [`time.RFC3339`].
 
-  [`Time.UnmarshalText`]: https://golang.org/pkg/time/#Time.UnmarshalText
-  [`time.RFC3339`]: https://golang.org/pkg/time/#RFC3339
+  [`Time.UnmarshalText`]: https://pkg.go.dev/time#Time.UnmarshalText
+  [`time.RFC3339`]: https://pkg.go.dev/time#RFC3339
 
 Although this tends to not be a problem in practice, keep in mind that the
 `"time"` package does not support parsing timestamps with leap seconds

src/type-assert.md

@@ -3,7 +3,7 @@
 The single return value form of a [type assertion] will panic on an incorrect
 type. Therefore, always use the "comma ok" idiom.
 
-  [type assertion]: https://golang.org/ref/spec#Type_assertions
+  [type assertion]: https://go.dev/ref/spec#Type_assertions
 
 <table>
 <thead><tr><th>Bad</th><th>Good</th></tr></thead>

src/var-decl.md

@@ -24,7 +24,7 @@ s := "foo"
 However, there are cases where the default value is clearer when the `var`
 keyword is used. [Declaring Empty Slices], for example.
 
-  [Declaring Empty Slices]: https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices
+  [Declaring Empty Slices]: https://go.dev/wiki/CodeReviewComments#declaring-empty-slices
 
 <table>
 <thead><tr><th>Bad</th><th>Good</th></tr></thead>