diff options
38 files changed, 169 insertions, 169 deletions
diff --git a/_content/blog/14years.md b/_content/blog/14years.md index 9902b93d..73726211 100644 --- a/_content/blog/14years.md +++ b/_content/blog/14years.md @@ -26,7 +26,7 @@ of your program that run most often. In Go 1.21, workloads typically get between 2% and 7% CPU usage improvements from enabling PGO. See “[Profile-guided optimization in Go 1.21](/blog/pgo)” for an overview -and the [profile-guided optimization user guide](https://go.dev/doc/pgo) +and the [profile-guided optimization user guide](/doc/pgo) for complete documentation. Go has provided support for gathering coverage profiles during `go test` @@ -108,7 +108,7 @@ dependencies and vulnerabilities, with [Govulncheck 1.0 launching in July](/blog/govulncheck). If you use VS Code, you can run govulncheck directly in your editor using the Go extension: -see [this tutorial](https://go.dev/doc/tutorial/govulncheck-ide) to get started. +see [this tutorial](/doc/tutorial/govulncheck-ide) to get started. And if you use GitHub, you can run govulncheck as part of your CI/CD, with the [GitHub Action for govulncheck](https://github.com/marketplace/actions/golang-govulncheck-action). diff --git a/_content/blog/deconstructing-type-parameters.md b/_content/blog/deconstructing-type-parameters.md index aff44fc0..3a423da0 100644 --- a/_content/blog/deconstructing-type-parameters.md +++ b/_content/blog/deconstructing-type-parameters.md @@ -81,7 +81,7 @@ replacing the type parameter with the type argument. func InstantiatedClone1(s []string) []string ``` -The [Go assignment rules](https://go.dev/ref/spec#Assignability) allow +The [Go assignment rules](/ref/spec#Assignability) allow us to pass a value of type `MySlice` to a parameter of type `[]string`, so calling `Clone1` is fine. But `Clone1` will return a value of type `[]string`, not a value of @@ -166,7 +166,7 @@ underlying type of `T2`. The underlying type of a predeclared type like `int` or a type literal like `[]string` is just the type itself. For the exact details, [see the language -spec](https://go.dev/ref/spec#Underlying_types). +spec](/ref/spec#Underlying_types). In our example, the underlying type of `MySlice` is `[]string`. Since the underlying type of `MySlice` is a slice, we can pass an diff --git a/_content/blog/get-familiar-with-workspaces.md b/_content/blog/get-familiar-with-workspaces.md index 09d27b3c..fb499cba 100644 --- a/_content/blog/get-familiar-with-workspaces.md +++ b/_content/blog/get-familiar-with-workspaces.md @@ -13,20 +13,20 @@ summary: Learn about Go workspaces and some of the workflows they enable. Go 1.18 adds workspace mode to Go, which lets you work on multiple modules simultaneously. -You can get Go 1.18 by visiting the [download](https://go.dev/dl/) page. The -[release notes](https://go.dev/doc/go1.18) have more details about all the +You can get Go 1.18 by visiting the [download](/dl/) page. The +[release notes](/doc/go1.18) have more details about all the changes. ## Workspaces -[Workspaces](https://go.dev/ref/mod#workspaces) in Go 1.18 let you work on +[Workspaces](/ref/mod#workspaces) in Go 1.18 let you work on multiple modules simultaneously without having to edit `go.mod` files for each module. Each module within a workspace is treated as a main module when resolving dependencies. Previously, to add a feature to one module and use it in another module, you needed to either publish the changes to the first module, or [edit the -go.mod](https://go.dev/doc/tutorial/call-module-code) file of the dependent +go.mod](/doc/tutorial/call-module-code) file of the dependent module with a `replace` directive for your local, unpublished module changes. In order to publish without errors, you had to remove the `replace` directive from the dependent module's `go.mod` file after you published the local changes to @@ -237,13 +237,13 @@ documentation](https://pkg.go.dev/golang.org/x/tools/gopls#readme-editors). ## What's next? -- Download and install [Go 1.18](https://go.dev/dl/). -- Try using [workspaces](https://go.dev/ref/mod#workspaces) with the [Go - workspaces Tutorial](https://go.dev/doc/tutorial/workspaces). +- Download and install [Go 1.18](/dl/). +- Try using [workspaces](/ref/mod#workspaces) with the [Go + workspaces Tutorial](/doc/tutorial/workspaces). - If you encounter any problems with workspaces, or want to suggest something, file an [issue](https://github.com/golang/go/issues/new/choose). - Read the [workspace maintenance documentation](https://pkg.go.dev/cmd/go#hdr-Workspace_maintenance). - Explore module commands for [working outside of a single - module](https://go.dev/ref/mod#commands-outside) including `go work init`, + module](/ref/mod#commands-outside) including `go work init`, `go work sync` and more. diff --git a/_content/blog/go1.18beta2.md b/_content/blog/go1.18beta2.md index c3de1edd..e81448cb 100644 --- a/_content/blog/go1.18beta2.md +++ b/_content/blog/go1.18beta2.md @@ -8,9 +8,9 @@ summary: Go 1.18 Beta 2 is our second preview of Go 1.18. Please try it and let We are encouraged by all the excitement around Go’s upcoming 1.18 release, which adds support for -[generics](https://go.dev/blog/why-generics), -[fuzzing](https://go.dev/blog/fuzz-beta), and the new -[Go workspace mode](https://go.dev/design/45713-workspace). +[generics](/blog/why-generics), +[fuzzing](/blog/fuzz-beta), and the new +[Go workspace mode](/design/45713-workspace). We released Go 1.18 beta 1 two months ago, and it is now the most downloaded Go beta ever, @@ -42,5 +42,5 @@ and to configure the VS Code Go extension, follow [this instruction](https://git As always, especially for beta releases, -if you notice any problems, please [file an issue](https://go.dev/issue/new). +if you notice any problems, please [file an issue](/issue/new). diff --git a/_content/blog/go1.21rc.md b/_content/blog/go1.21rc.md index 156b50f6..0fb643f6 100644 --- a/_content/blog/go1.21rc.md +++ b/_content/blog/go1.21rc.md @@ -36,10 +36,10 @@ because a bug was found and fixed after tagging `go1.21rc1`)* has been expanded and clarified. - In a future version of Go we’re planning to address one of the most common gotchas of Go programming: - [loop variable capture](https://go.dev/wiki/CommonMistakes). + [loop variable capture](/wiki/CommonMistakes). Go 1.21 comes with a preview of this feature that you can enable in your code using an environment variable. See [this LoopvarExperiment wiki - page](https://go.dev/wiki/LoopvarExperiment) for more details. + page](/wiki/LoopvarExperiment) for more details. ## Standard library additions diff --git a/_content/blog/go119runtime.md b/_content/blog/go119runtime.md index 15d4010b..e67ab396 100644 --- a/_content/blog/go119runtime.md +++ b/_content/blog/go119runtime.md @@ -15,12 +15,12 @@ Let's catch you up on the highlights! ### What's new? - `sync.Pool`, a GC-aware tool for reusing memory, has a [lower latency - impact](https://go.dev/cl/166960) and [recycles memory much more - effectively](https://go.dev/cl/166961) than before. + impact](/cl/166960) and [recycles memory much more + effectively](/cl/166961) than before. (Go 1.13) - The Go runtime returns unneeded memory back to the operating system [much - more proactively](https://go.dev/issue/30333), reducing excess memory + more proactively](/issue/30333), reducing excess memory consumption and the chance of out-of-memory errors. This reduces idle memory consumption by up to 20%. (Go 1.13 and 1.14) @@ -32,7 +32,7 @@ Let's catch you up on the highlights! (Go 1.14) - The Go runtime [manages timers more efficiently than - before](https://go.dev/cl/171883), especially on machines with many CPU cores. + before](/cl/171883), especially on machines with many CPU cores. (Go 1.14) - Function calls that have been deferred with the `defer` statement now cost as @@ -41,8 +41,8 @@ Let's catch you up on the highlights! here.](https://www.youtube.com/watch?v=DHVeUsrKcbM) (Go 1.14) -- The memory allocator's slow path [scales](https://go.dev/issue/35112) - [better](https://go.dev/issue/37487) with CPU cores, increasing throughput up +- The memory allocator's slow path [scales](/issue/35112) + [better](/issue/37487) with CPU cores, increasing throughput up to 10% and decreasing tail latencies up to 30%, especially in highly-parallel programs. (Go 1.14 and 1.15) @@ -55,16 +55,16 @@ Let's catch you up on the highlights! (Go 1.16) - The Go scheduler spends up to [30% less CPU time spinning to find new - work](https://go.dev/issue/43997). + work](/issue/43997). (Go 1.17) - Go code now follows a [register-based calling - convention](https://go.dev/issues/40724) on amd64, arm64, and ppc64, improving + convention](/issues/40724) on amd64, arm64, and ppc64, improving CPU efficiency by up to 15%. (Go 1.17 and Go 1.18) - The Go GC's internal accounting and scheduling has been - [redesigned](https://go.dev/issue/44167), resolving a variety of long-standing + [redesigned](/issue/44167), resolving a variety of long-standing issues related to efficiency and robustness. This results in a significant decrease in application tail latency (up to 66%) for applications where goroutines stacks are a substantial portion of memory @@ -72,7 +72,7 @@ Let's catch you up on the highlights! (Go 1.18) - The Go GC now limits [its own CPU use when the application is - idle](https://go.dev/issue/44163). + idle](/issue/44163). This results in 75% lower CPU utilization during a GC cycle in very idle applications, reducing CPU spikes that can confuse job shapers. (Go 1.19) diff --git a/_content/blog/gonew.md b/_content/blog/gonew.md index c5732d1e..2b36b28b 100644 --- a/_content/blog/gonew.md +++ b/_content/blog/gonew.md @@ -25,7 +25,7 @@ leveraging the Go module proxy and checksum database for better security and ava The prototype `gonew` is intentionally minimal: what we have released today is an extremely limited prototype meant to provide a base from which we can gather feedback and community direction. -Try it out, [tell us what you think](https://go.dev/s/gonew-feedback), +Try it out, [tell us what you think](/s/gonew-feedback), and help us build a more useful tool for everyone. ## Getting started @@ -67,5 +67,5 @@ and [Service Weaver](https://github.com/ServiceWeaver/template) teams. Please try out `gonew` and let us know how we can make it better and more useful. Remember, `gonew` is just an experiment for now; -we need your [feedback to get it right](https://go.dev/s/gonew-feedback). +we need your [feedback to get it right](/s/gonew-feedback). diff --git a/_content/blog/gopls-scalability.md b/_content/blog/gopls-scalability.md index 2975dd5a..9e14dfe9 100644 --- a/_content/blog/gopls-scalability.md +++ b/_content/blog/gopls-scalability.md @@ -18,7 +18,7 @@ summary: As the Go ecosystem gets bigger, gopls must get smaller } </style> -Earlier this summer, the Go team released version [v0.12](https://go.dev/s/gopls-v0.12) +Earlier this summer, the Go team released version [v0.12](/s/gopls-v0.12) of [gopls](https://pkg.go.dev/golang.org/x/tools/gopls), the [language server](https://microsoft.github.io/language-server-protocol/) for Go, featuring a rewrite of its core that allows it to scale to larger codebases. @@ -66,7 +66,7 @@ Since its beginnings in 2018, gopls has consolidated many disparate command-line tools such as [guru](https://pkg.go.dev/golang.org/x/tools/cmd/guru), [gorename](https://pkg.go.dev/golang.org/x/tools/cmd/gorename), and [goimports](https://pkg.go.dev/golang.org/x/tools/cmd/goimports) and -has become the [default backend for the VS Code Go extension](https://go.dev/blog/gopls-vscode-go) +has become the [default backend for the VS Code Go extension](/blog/gopls-vscode-go) as well as many other editors and LSP plugins. Perhaps you’ve been using gopls through your editor without even knowing it---that’s the goal! @@ -79,7 +79,7 @@ that gopls's high memory usage was barely tolerable. Meanwhile, the Go ecosystem was growing, with more code being written in larger repositories. -[Go workspaces](https://go.dev/blog/get-familiar-with-workspaces) allowed +[Go workspaces](/blog/get-familiar-with-workspaces) allowed developers to work on multiple modules simultaneously, and [containerized development](https://code.visualstudio.com/docs/devcontainers/containers) put language servers in increasingly resource-constrained environments. @@ -183,7 +183,7 @@ require recompiling _all_ the packages that indirectly depend on that package. Pruned incremental rebuilds make the amount of work proportional to the scope of each change. This is not a new idea: it was introduced by [Vesta](https://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-177.pdf) -and also used in [`go build`](https://go.dev/doc/go1.10#build). +and also used in [`go build`](/doc/go1.10#build). The v0.12 release introduces a similar pruning technique to gopls, going one step further to implement a faster pruning heuristic based on syntactic analysis. @@ -216,8 +216,8 @@ even in your user-defined wrappers around `fmt.Printf`. Notably, `go vet` has provided this level of precision for years, but gopls was unable to do this in real time after each edit. Now it can. -The second is [simpler workspace configuration](https://go.dev/issue/57979) -and [improved handling for build tags](https://go.dev/issue/29202). +The second is [simpler workspace configuration](/issue/57979) +and [improved handling for build tags](/issue/29202). These two features both amount to gopls "doing the right thing" when you open any Go file on your machine, but both were infeasible without the optimization work because (for example) diff --git a/_content/blog/govulncheck.md b/_content/blog/govulncheck.md index 026769c8..d05673cc 100644 --- a/_content/blog/govulncheck.md +++ b/_content/blog/govulncheck.md @@ -9,12 +9,12 @@ summary: Version v1.0.0 of golang.org/x/vuln has been released, introducing a ne We are excited to announce that govulncheck v1.0.0 has been released, along with v1.0.0 of the API for integrating scanning into other tools! -Go's support for vulnerability management was [first announced](https://go.dev/blog/vuln) last September. +Go's support for vulnerability management was [first announced](/blog/vuln) last September. We have made several changes since then, culminating in today's release. This post describes Go's updated vulnerability tooling, and how to get started using it. We also recently published a -[security best practices guide](https://go.dev/security/best-practices) +[security best practices guide](/security/best-practices) to help you prioritize security in your Go projects. ## Govulncheck @@ -38,7 +38,7 @@ Then, run govulncheck inside your module: govulncheck ./... ``` -See the [govulncheck tutorial](https://go.dev/doc/tutorial/govulncheck) +See the [govulncheck tutorial](/doc/tutorial/govulncheck) for additional information on how to get started with using the tool. As of this release, there is now a stable API available, @@ -55,17 +55,17 @@ which provides a comprehensive source of information about known vulnerabilities in public Go modules. You can browse the entries in the database at [pkg.go.dev/vuln](https://pkg.go.dev/vuln). -Since the initial release, we have updated the [database API](https://go.dev/security/vuln/database#api) +Since the initial release, we have updated the [database API](/security/vuln/database#api) to improve performance and ensure long-term extensibility. An experimental tool to generate your own vulnerability database index is provided at [golang.org/x/vulndb/cmd/indexdb](https://golang.org/x/vulndb/cmd/indexdb). If you are a Go package maintainer, we encourage you to -[contribute information](https://go.dev/s/vulndb-report-new) +[contribute information](/s/vulndb-report-new) about public vulnerabilities in your projects. For more information about the Go vulnerability database, -see [go.dev/security/vuln/database](https://go.dev/security/vuln/database). +see [go.dev/security/vuln/database](/security/vuln/database). ## Integrations @@ -81,7 +81,7 @@ shows vulnerabilities in older versions of the module. You can also run govulncheck directly in your editor using the Go extension for Visual Studio Code. -See [the tutorial](https://go.dev/doc/tutorial/govulncheck-ide) to get started. +See [the tutorial](/doc/tutorial/govulncheck-ide) to get started. Lastly, we know that many developers will want to run govulncheck as part of their CI/CD systems. @@ -98,7 +98,7 @@ we presented a walkthrough of these tools at Google I/O this year, in our talk, ## Feedback As always, we welcome your feedback! See details on -[how to contribute and help us make improvements](https://go.dev/security/vuln/#feedback). +[how to contribute and help us make improvements](/security/vuln/#feedback). We hope you’ll find the latest release of Go’s support for vulnerability management useful and work with us to build a more secure and reliable Go diff --git a/_content/blog/integration-test-coverage.md b/_content/blog/integration-test-coverage.md index 49b9236e..de99c97f 100644 --- a/_content/blog/integration-test-coverage.md +++ b/_content/blog/integration-test-coverage.md @@ -8,7 +8,7 @@ summary: Code coverage for integration tests, available in Go 1.20. Code coverage tools help developers determine what fraction of a source code base is executed (covered) when a given test suite is executed. -Go has for some time provided support ([introduced](https://go.dev/blog/cover) in the Go 1.2 release) to measure code coverage at the package level, using the **"-cover"** flag of the "go test" command. +Go has for some time provided support ([introduced](/blog/cover) in the Go 1.2 release) to measure code coverage at the package level, using the **"-cover"** flag of the "go test" command. This tooling works well in most cases, but has some weaknesses for larger Go applications. For such applications, developers often write "integration" tests that verify the behavior of an entire program (in addition to package-level unit tests). diff --git a/_content/blog/loopvar-preview.md b/_content/blog/loopvar-preview.md index 535f4e83..d610026a 100644 --- a/_content/blog/loopvar-preview.md +++ b/_content/blog/loopvar-preview.md @@ -40,7 +40,7 @@ For example, consider this program: The three created goroutines are all printing the same variable `v`, so they usually print “c”, “c”, “c”, instead of printing “a”, “b”, and “c” in some order. -The [Go FAQ entry “What happens with closures running as goroutines?”](https://go.dev/doc/faq#closures_and_goroutines), +The [Go FAQ entry “What happens with closures running as goroutines?”](/doc/faq#closures_and_goroutines), gives this example and remarks “Some confusion may arise when using closures with concurrency.” @@ -168,7 +168,7 @@ we have had zero reports of any problems in production code. You can also try test programs to better understand the semantics on the Go playground by including a `// GOEXPERIMENT=loopvar` comment -at the top of the program, like in [this program](https://go.dev/play/p/YchKkkA1ETH). +at the top of the program, like in [this program](/play/p/YchKkkA1ETH). (This comment only applies in the Go playground.) ## Fixing Buggy Tests @@ -200,7 +200,7 @@ Fixing for loops exposes this kind of buggy test. To help prepare for this kind of discovery, we improved the precision of the `loopclosure` analyzer in Go 1.21 so that it can identify and report this problem. -You can see the report [in this program](https://go.dev/play/p/WkJkgXRXg0m) on the Go playground. +You can see the report [in this program](/play/p/WkJkgXRXg0m) on the Go playground. If `go vet` is reporting this kind of problem in your own tests, fixing them will prepare you better for Go 1.22. @@ -214,5 +214,5 @@ which specific loop is causing a test failure when the new semantics are applied For more information about the change, see the [design document](https://go.googlesource.com/proposal/+/master/design/60078-loopvar.md) and the -[FAQ](https://go.dev/wiki/LoopvarExperiment). +[FAQ](/wiki/LoopvarExperiment). diff --git a/_content/blog/pgo-preview.md b/_content/blog/pgo-preview.md index 08ab74f1..561d2347 100644 --- a/_content/blog/pgo-preview.md +++ b/_content/blog/pgo-preview.md @@ -19,14 +19,14 @@ The compiler must make a best guess based on static heuristics because it can't Or can it? With no definitive information about how the code is used in a production environment, the compiler can operate only on the source code of packages. -But we do have a tool to evaluate production behavior: [profiling](https://go.dev/doc/diagnostics#profiling). +But we do have a tool to evaluate production behavior: [profiling](/doc/diagnostics#profiling). If we provide a profile to the compiler, it can make more informed decisions: more aggressively optimizing the most frequently used functions, or more accurately selecting common cases. Using profiles of application behavior for compiler optimization is known as _Profile-Guided Optimization (PGO)_ (also known as Feedback-Directed Optimization (FDO)). Go 1.20 includes initial support for PGO as a preview. -See the [profile-guided optimization user guide](https://go.dev/doc/pgo) for complete documentation. -There are still some rough edges that may prevent production use, but we would love for you to try it out and [send us any feedback or issues you encounter](https://go.dev/issue/new). +See the [profile-guided optimization user guide](/doc/pgo) for complete documentation. +There are still some rough edges that may prevent production use, but we would love for you to try it out and [send us any feedback or issues you encounter](/issue/new). ## Example @@ -125,7 +125,7 @@ In `main.go`, we imported [net/http/pprof](https://pkg.go.dev/net/http/pprof) wh Normally you want to collect a profile from your production environment so that the compiler gets a representative view of behavior in production. Since this example doesn't have a "production" environment, we will create a simple program to generate load while we collect a profile. -Copy the source of [this program](https://go.dev/play/p/yYH0kfsZcpL) to `load/main.go` and start the load generator (make sure the server is still running!). +Copy the source of [this program](/play/p/yYH0kfsZcpL) to `load/main.go` and start the load generator (make sure the server is still running!). ``` $ go run example.com/markdown/load @@ -158,7 +158,7 @@ $ go build -pgo=auto -o markdown.withpgo.exe ### Evaluation We will use a Go benchmark version of the load generator to evaluate the effect of PGO on performance. -Copy [this benchmark](https://go.dev/play/p/6FnQmHfRjbh) to `load/bench_test.go`. +Copy [this benchmark](/play/p/6FnQmHfRjbh) to `load/bench_test.go`. First, we will benchmark the server without PGO. Start that server: @@ -211,7 +211,7 @@ So we may collect a profile from production, which is running last week's code, That is perfectly fine! PGO in Go can handle minor changes to source code without issue. -For much more information on using PGO, best practices and caveats to be aware of, please see the [profile-guided optimization user guide](https://go.dev/doc/pgo). +For much more information on using PGO, best practices and caveats to be aware of, please see the [profile-guided optimization user guide](/doc/pgo). Please send us your feedback! PGO is still in preview and we'd love to hear about anything that is difficult to use, doesn't work correctly, etc. diff --git a/_content/blog/pgo.md b/_content/blog/pgo.md index 6f9383dc..6dce0797 100644 --- a/_content/blog/pgo.md +++ b/_content/blog/pgo.md @@ -8,7 +8,7 @@ summary: Introduction to profile-guided optimization, generally available in Go Earlier in 2023, Go 1.20 [shipped a preview of profile-guided optimization (PGO)](/blog/pgo-preview) for users to test. After addressing known limitations in the preview, and with additional refinements thanks to community feedback and contributions, PGO support in Go 1.21 is ready for general production use! -See the [profile-guided optimization user guide](https://go.dev/doc/pgo) for complete documentation. +See the [profile-guided optimization user guide](/doc/pgo) for complete documentation. [Below](#example) we will run through an example of using PGO to improve the performance of an application. Before we get to that, what exactly is "profile-guided optimization"? @@ -27,7 +27,7 @@ The compiler must make a best guess based on static heuristics because it can’ Or can it? With no definitive information about how the code is used in a production environment, the compiler can operate only on the source code of packages. -But we do have a tool to evaluate production behavior: [profiling](https://go.dev/doc/diagnostics#profiling). +But we do have a tool to evaluate production behavior: [profiling](/doc/diagnostics#profiling). If we provide a profile to the compiler, it can make more informed decisions: more aggressively optimizing the most frequently used functions, or more accurately selecting common cases. Using profiles of application behavior for compiler optimization is known as _Profile-Guided Optimization (PGO)_ (also known as Feedback-Directed Optimization (FDO)). @@ -225,7 +225,7 @@ That is perfectly fine! PGO in Go can handle minor changes to source code without issue. Of course, over time source code will drift more and more, so it is still important to update the profile occasionally. -For much more information on using PGO, best practices and caveats to be aware of, please see the [profile-guided optimization user guide](https://go.dev/doc/pgo). +For much more information on using PGO, best practices and caveats to be aware of, please see the [profile-guided optimization user guide](/doc/pgo). If you are curious about what is going on under the hood, keep reading! ## Under the hood @@ -350,7 +350,7 @@ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ``` So `runtime.scanobject` is ultimately coming from `runtime.gcBgMarkWorker`. -The [Go GC Guide](https://go.dev/doc/gc-guide#Identiying_costs) tells us that `runtime.gcBgMarkWorker` is part of the garbage collector, so `runtime.scanobject` savings must be GC savings. +The [Go GC Guide](/doc/gc-guide#Identiying_costs) tells us that `runtime.gcBgMarkWorker` is part of the garbage collector, so `runtime.scanobject` savings must be GC savings. What about `nextFreeFast` and other `runtime` functions? ``` diff --git a/_content/blog/slog.md b/_content/blog/slog.md index ea491c6c..4ac400d1 100644 --- a/_content/blog/slog.md +++ b/_content/blog/slog.md @@ -217,7 +217,7 @@ and the `LogValuer` interface. We changed the mapping from log levels to integers twice. After two months and about 300 comments, we felt we were ready for an actual -[proposal](https://go.dev/issue/56345) and accompanying [design +[proposal](/issue/56345) and accompanying [design doc](https://go.googlesource.com/proposal/+/03441cb358c7b27a8443bca839e5d7a314677ea6/design/56345-structured-logging.md). The proposal issue garnered over 800 comments and resulted in many improvements to the API and the implementation. Here are two examples of API changes, both diff --git a/_content/blog/supply-chain.md b/_content/blog/supply-chain.md index cf2a9c1b..f07298c8 100644 --- a/_content/blog/supply-chain.md +++ b/_content/blog/supply-chain.md @@ -24,11 +24,11 @@ dependency being published—to automatically affect a Go build. Unlike most other package managers files, Go modules don’t have a separate list of constraints and a lock file pinning specific versions. The version of every dependency contributing to any Go build is fully determined -by the [`go.mod` file](https://go.dev/ref/mod#go-mod-file) of the main module. +by the [`go.mod` file](/ref/mod#go-mod-file) of the main module. Since Go 1.16, this determinism is enforced by default, and build commands (`go build`, `go test`, `go install`, `go run`, …) [will fail if the go.mod is -incomplete](https://go.dev/ref/mod#go-mod-file-updates). +incomplete](/ref/mod#go-mod-file-updates). The only commands that will change the `go.mod` (and therefore the build) are `go get` and `go mod tidy`. These commands are not expected to be run automatically or in CI, so changes to @@ -43,7 +43,7 @@ There is no way for third parties to affect that. Moreover, when a dependency is added with `go get`, its transitive dependencies are added at the version specified in the dependency’s `go.mod` file, not at their latest versions, thanks to -[Minimal version selection](https://go.dev/ref/mod#minimal-version-selection). +[Minimal version selection](/ref/mod#minimal-version-selection). The same happens for invocations of `go install example.com/cmd/devtoolx@latest`, [the equivalents of which in some ecosystems bypass pinning](https://research.swtch.com/npm-colors). @@ -63,7 +63,7 @@ that the contents of a module version are immutable. If an attacker that compromises a dependency could re-upload an existing version, they could automatically compromise all projects that depend on it. -That’s what the [`go.sum` file](https://go.dev/ref/mod#go-sum-files) is for. +That’s what the [`go.sum` file](/ref/mod#go-sum-files) is for. It contains a list of cryptographic hashes of each dependency that contributes to the build. Again, an incomplete <code>go.sum</code> causes an error, and only <code>go @@ -73,7 +73,7 @@ Other builds are guaranteed to have a full set of checksums. This is a common feature of most lock files. Go goes beyond it with the -[Checksum Database](https://go.dev/ref/mod#checksum-database) (sumdb for short), +[Checksum Database](/ref/mod#checksum-database) (sumdb for short), a global append-only cryptographically-verifiable list of go.sum entries. When `go get` needs to add an entry to the `go.sum` file, it fetches it from the sumdb along with cryptographic proof of the sumdb integrity. @@ -109,7 +109,7 @@ The import path of a package embeds the information that `go mod download` module](https://pkg.go.dev/cmd/go#hdr-Remote_import_paths) directly from the VCS, where tags define versions. -We do have the [Go Module Mirror](https://go.dev/blog/module-mirror-launch), but +We do have the [Go Module Mirror](/blog/module-mirror-launch), but that’s only a proxy. Module authors don’t register an account and don’t upload versions to the proxy. The proxy uses the same logic that the `go` tool uses (in fact, the proxy runs @@ -126,7 +126,7 @@ Running VCS tools on the client exposes a pretty large attack surface. That’s another place the Go Module Mirror helps: the `go` tool on the proxy runs inside a robust sandbox and is configured to support every VCS tool, while [the default is to only support the two major VCS -systems](https://go.dev/ref/mod#vcs-govcs) (git and Mercurial). +systems](/ref/mod#vcs-govcs) (git and Mercurial). Anyone using the proxy can still fetch code published using off-by-default VCS systems, but attackers can’t reach that code in most installations. diff --git a/_content/blog/survey2021-results.md b/_content/blog/survey2021-results.md index 12858f8c..1a4c74b1 100644 --- a/_content/blog/survey2021-results.md +++ b/_content/blog/survey2021-results.md @@ -25,7 +25,7 @@ In 2021, we ran the Go Developer Survey from Oct 26th to Nov 16th and had 11,840 ## Who did we hear from? {#demographics} -Our demographics have been pretty stable year over year ([See 2020 results](https://go.dev/blog/survey2020-results)). Consistent with previous years, Go is primarily used in the tech industry. 70% of respondents were software developers, with a few in IT or DevOps and 76% of respondents said they program in Go at work. +Our demographics have been pretty stable year over year ([See 2020 results](/blog/survey2020-results)). Consistent with previous years, Go is primarily used in the tech industry. 70% of respondents were software developers, with a few in IT or DevOps and 76% of respondents said they program in Go at work. <img src="survey2021/industry_yoy.svg" alt="Bar chart of industries where respondents work" width="700"/> <img src="survey2021/where_yoy.svg" alt="Bar chart showing Go used more at work than outide of work" width="700"/> <img src="survey2021/app_yoy.svg" alt="Bar chart of uses for Go where API/RPC services and CLI apps are most common" width="700"/> @@ -152,7 +152,7 @@ Respondents deploying to AWS saw increases in deploying to a managed Kubernetes ## Changes this year {#changes} -Last year we introduced a [modular survey design](https://go.dev/blog/survey2020-results) so that we could ask more questions without lengthening the survey. We continued the modular design this year, although some questions were discontinued and others were added or modified. No respondents saw all the questions on the survey. Additionally, some questions may have much smaller sample sizes because they were asked selectively based on a previous question. +Last year we introduced a [modular survey design](/blog/survey2020-results) so that we could ask more questions without lengthening the survey. We continued the modular design this year, although some questions were discontinued and others were added or modified. No respondents saw all the questions on the survey. Additionally, some questions may have much smaller sample sizes because they were asked selectively based on a previous question. The most significant change to the survey this year was in how we recruited participants. In previous years, we announced the survey through the Go Blog, where it was picked up on various social channels like Twitter, Reddit, or Hacker News. This year, in addition to the traditional channels, we used the VS Code Go plugin to randomly select users to be shown a prompt asking if they’d like to participate in the survey. This created a random sample that we used to compare the self-selected respondents from our traditional channels and helped identify potential effects of [self-selection bias](https://en.wikipedia.org/wiki/Self-selection_bias). diff --git a/_content/blog/survey2022-q2-results.md b/_content/blog/survey2022-q2-results.md index a4cfd2ec..233f456a 100644 --- a/_content/blog/survey2022-q2-results.md +++ b/_content/blog/survey2022-q2-results.md @@ -91,7 +91,7 @@ included in the chart, in the form "_n = [number of respondents]_". ### A note on methodology Most survey respondents "self-selected" to take the survey, meaning they found -it on [the Go blog](https://go.dev/blog), [@golang on +it on [the Go blog](/blog), [@golang on Twitter](https://twitter.com/golang), or other social Go channels. A potential problem with this approach is that people who don't follow these channels are less likely to learn about the survey, and might respond differently than @@ -172,8 +172,8 @@ breach](https://en.wikipedia.org/wiki/2020_United_States_federal_government_data the practice of developing software securely has received renewed attention. The Go team has prioritized work in this area, including tools for creating [a software bill of materials (SBOM)](https://pkg.go.dev/debug/buildinfo), [fuzz -testing](https://go.dev/doc/fuzz/), and most recently, [vulnerability -scanning](https://go.dev/blog/vuln/). To support these efforts, this survey +testing](/doc/fuzz/), and most recently, [vulnerability +scanning](/blog/vuln/). To support these efforts, this survey asked several questions about software development security practices and challenges. We specifically wanted to understand: @@ -286,7 +286,7 @@ understanding of _how_ an application uses a vulnerable dependency, are crucial for understanding the risk the vulnerability may present to an organization, as well as understanding whether a data breach or other security compromise occurred. Thus, [we designed -`govulncheck`](https://go.dev/blog/vuln) to only alert developers when a +`govulncheck`](/blog/vuln) to only alert developers when a vulnerability is invoked, and point developers to the exact places in their code using the vulnerable functions. Our hope is that this will make it easier for developers to quickly investigate the vulnerabilities that truly matter to @@ -319,7 +319,7 @@ for the tool used to distribute the invitation, which is exactly what we saw (91% of the randomly sampled respondents preferred VS Code). Following the 2021 switch to [power VS Code's Go support via the gopls -language server](https://go.dev/blog/gopls-vscode-go), the Go team has been +language server](/blog/gopls-vscode-go), the Go team has been interested in understanding developer pain points related to gopls. While we receive a healthy amount of feedback from developers currently using gopls, we wondered whether a large proportion of developers had disabled it shortly @@ -399,7 +399,7 @@ class="chart" /> Overall, the demographics and firmographics of respondents did not meaningfully shift since [our 2021 -survey](https://go.dev/blog/survey2021-results). A small majority of +survey](/blog/survey2021-results). A small majority of respondents (53%) have at least two years of experience using Go, while the rest are newer to the Go community. About ⅓ of respondents work at small businesses (< 100 employees), ¼ work at medium-sized businesses (100 -- 1,000 @@ -467,7 +467,7 @@ of challenges reported by survey respondents" class="chart" /> ## Survey methodology We publicly announced this survey on June 1st, 2022 via -[go.dev/blog](https://go.dev/blog) and [@golang](https://twitter.com/golang) +[go.dev/blog](/blog) and [@golang](https://twitter.com/golang) on Twitter. We also randomly prompted 10% of [VS Code](https://code.visualstudio.com/) users via the Go plugin between June 1st -- 21st. The survey closed on June 22nd, and partial responses (i.e., people diff --git a/_content/blog/survey2023-h2-results.md b/_content/blog/survey2023-h2-results.md index 0ca4db9d..27b8aed0 100644 --- a/_content/blog/survey2023-h2-results.md +++ b/_content/blog/survey2023-h2-results.md @@ -320,7 +320,7 @@ analysis, we did identify some interesting patterns: ## How developers start new Go projects {#gonew} As part of our [experimentation with project -templates](https://go.dev/blog/gonew), we wanted to understand how Go +templates](/blog/gonew), we wanted to understand how Go developers get started with new projects today. Respondents told us their biggest challenges were choosing an appropriate way to structure their project (54%) and learning how to write idiomatic Go (47%). As two respondents phrased @@ -730,7 +730,7 @@ respondents recently used Go" class="chart" /> The majority of respondents have been working with Go for under five years (68%). As we've seen in [prior -years](https://go.dev/blog/survey2023-q1-results#novice-respondents-are-more-likely-to-prefer-windows-than-more-experienced-respondents), +years](/blog/survey2023-q1-results#novice-respondents-are-more-likely-to-prefer-windows-than-more-experienced-respondents), people who found this survey via VS Code tended to be less experienced than people who found the survey via other channels. @@ -895,4 +895,4 @@ everyone who shared their feedback about Go---we have immense gratitude for taking your time to help shape Go's future, and we hope you see some of your own feedback reflected in this report. 🩵 ---- Todd (on behalf of the Go team at Google)
\ No newline at end of file +--- Todd (on behalf of the Go team at Google) diff --git a/_content/blog/survey2023-q1-results.md b/_content/blog/survey2023-q1-results.md index 5dc7294c..6bc7a448 100644 --- a/_content/blog/survey2023-q1-results.md +++ b/_content/blog/survey2023-q1-results.md @@ -86,7 +86,7 @@ included in the chart, in the form “_n = [number of respondents]_”. ### A note on methodology Most survey respondents “self-selected” to take the survey by accessing it -through a link on [the Go blog](https://go.dev/blog), [@golang on +through a link on [the Go blog](/blog), [@golang on Twitter](https://twitter.com/golang), or other social Go channels. People who don’t follow these channels might respond differently from people who _do_ closely follow them. About a quarter of respondents were randomly sampled, @@ -101,7 +101,7 @@ down responses into “Random sample” and “Self-selected” groups. ## Taking a closer look at different groups of respondents Our respondent demographics did not change significantly from [our last -survey](https://go.dev/blog/survey2022-q2-results). Consistent with previous +survey](/blog/survey2022-q2-results). Consistent with previous cycles, Go is primarily used in the tech industry, and about 80% of respondents said they program in Go at work. Overall, survey respondents tended to be satisfied with Go over the past year, with 92% saying they were @@ -275,7 +275,7 @@ One respondent succinctly illustrated this issue: >"Using Go effectively. Easy to learn, hard to master." We’ve heard that Go is easy to learn, and a [previous survey showed that over -70%](https://go.dev/blog/survey2020-results#TOC_6.2) of respondents feel +70%](/blog/survey2020-results#TOC_6.2) of respondents feel productive using Go within their first year, but learning Go best practices came up as one of the biggest challenges to using Go. Respondents this year told us that best practices around **code structure** and **recommended tools diff --git a/_content/blog/type-inference.md b/_content/blog/type-inference.md index 9b520fb0..8053144e 100644 --- a/_content/blog/type-inference.md +++ b/_content/blog/type-inference.md @@ -118,13 +118,13 @@ The `Sort` function call passes the `list` variable as function argument for the of [`slices.Sort`](https://pkg.go.dev/slices#Sort). Therefore the type of `list`, which is `List`, must match the type of `x`, which is type parameter `S`. If `S` has the type `List`, this assignment becomes valid. -In reality, the [rules for assignments](https://go.dev/ref/spec#Assignability) are complicated, +In reality, the [rules for assignments](/ref/spec#Assignability) are complicated, but for now it's good enough to assume that the types must be identical. Once we have inferred the type for `S`, we can look at the -[type constraint](https://go.dev/ref/spec#Type_constraints) for `S`. +[type constraint](/ref/spec#Type_constraints) for `S`. It says—because of the tilde `~` symbol—that the -[_underlying type_](https://go.dev/ref/spec#Underlying_types) of `S` +[_underlying type_](/ref/spec#Underlying_types) of `S` must be the slice `[]E`. The underlying type of `S` is `[]int`, therefore `[]int` must match `[]E`, and with that we can conclude that `E` must be `int`. @@ -178,9 +178,9 @@ slices.Sort(list) ``` Inference succeeds if the type equations below can be solved. -Here `≡` stands for [_is identical to_](https://go.dev/ref/spec#Type_identity), +Here `≡` stands for [_is identical to_](/ref/spec#Type_identity), and `under(S)` represents -the [underlying type](https://go.dev/ref/spec#Underlying_types) +the [underlying type](/ref/spec#Underlying_types) of `S`: S ≡ List // find S such that S ≡ List is true @@ -197,11 +197,11 @@ flows into inference. ### Being precise with type relations Until now we have simply talked about types having to be -[identical](https://go.dev/ref/spec#Type_identity). +[identical](/ref/spec#Type_identity). But for actual Go code that is too strong a requirement. In the previous example, `S` need not be identical to `List`, -rather `List` must be [assignable](https://go.dev/ref/spec#Assignability) to `S`. -Similarly, `S` must [satisfy](https://go.dev/ref/spec#Satisfying_a_type_constraint) +rather `List` must be [assignable](/ref/spec#Assignability) to `S`. +Similarly, `S` must [satisfy](/ref/spec#Satisfying_a_type_constraint) its corresponding type constraint. We can formulate our type equations more precisely by using specific operators that we write as `:≡` and `∈`: @@ -222,7 +222,7 @@ or one type must satisfy a type constraint: `≡`<sub>C</sub> for `∈`. We believe `:≡` more clearly evokes an assignment relation; and `∈` directly expresses that the type represented by a type parameter must -be an element of its constraint's [type set](https://go.dev/ref/spec#Interface_types).) +be an element of its constraint's [type set](/ref/spec#Interface_types).) ### Sources of type equations @@ -459,7 +459,7 @@ type parameters that may occur in `X` and `Y`. The goal is to make the types `X` and `Y` _identical_. This matching process is called [_unification_](https://en.wikipedia.org/wiki/Unification_(computer_science)). -The rules for [type identity](https://go.dev/ref/spec#Type_identity) tell +The rules for [type identity](/ref/spec#Type_identity) tell us how to compare types. Since _bound_ type parameters play the role of type variables, we need to specify how they are matched against other types. @@ -613,7 +613,7 @@ But what about `X :≡ Y` or `X ∈ Y`? A couple of observations help us out here: The job of type inference is solely to find the types of omitted type arguments. Type inference is always followed by type or function -[instantiation](https://go.dev/ref/spec#Instantiations) which +[instantiation](/ref/spec#Instantiations) which checks that each type argument actually satisfies its respective type constraint. Finally, in case of a generic function call, the compiler also checks that function arguments are assignable to their corresponding function parameters. @@ -650,7 +650,7 @@ their underlying types are compared instead. Furthermore, the assignment direction is ignored: `X :≡ Y` is treated like `Y :≡ X`. These adjustments apply only at the top level of a type structure: -for instance, per Go's [assignability rules](https://go.dev/ref/spec#Assignability), +for instance, per Go's [assignability rules](/ref/spec#Assignability), a named map type may be assigned to an unnamed map type, but the key and element types must still be identical. With these changes, unification for assignability becomes a (minor) variation @@ -685,7 +685,7 @@ slice type and we care about the slice's element type. For example, a type parameter list of the form `[P ~[]E]` tells us that whatever `P` is, its underlying type must be of the form `[]E`. These are exactly the situations where the constraint has a -[core type](https://go.dev/ref/spec#Core_types). +[core type](/ref/spec#Core_types). Therefore, if we have an equation of the form @@ -803,7 +803,7 @@ Untyped constants are ignored for type inference in this case and the calls beha as if `foo` was explicitly instantiated with `int`. It gets more interesting if `foo` is called with untyped constant arguments only. -In this case, type inference considers the [default types](https://go.dev/ref/spec#Constants) +In this case, type inference considers the [default types](/ref/spec#Constants) of the untyped constants. As a quick reminder, here are the possible default types in Go: @@ -842,7 +842,7 @@ the result is the floating-point constant `3.0` with default type `float64`. In Go 1.21 the behavior was changed accordingly. Now, if multiple untyped numeric constants are matched against the same type parameter, the default type that appears later in the list of `int`, `rune`, `float64`, `complex` is -selected, matching the rules for [constant expressions](https://go.dev/ref/spec#Constant_expressions): +selected, matching the rules for [constant expressions](/ref/spec#Constant_expressions): ```Go foo(1, 2.0) // Go 1.21: P ➞ float64 (larger default type of 1 and 2.0; behavior like in 1 + 2.0) @@ -863,7 +863,7 @@ order in each call of that function). Let's reconsider our variadic `foo` function: the type inferred for `P` should be the same irrespective of the order in which -we pass the arguments `s` and `t` ([playground](https://go.dev/play/p/sOlWutKnDFc)). +we pass the arguments `s` and `t` ([playground](/play/p/sOlWutKnDFc)). ```Go func foo[P any](...P) (x P) {} @@ -936,7 +936,7 @@ As a result, irrespective of the unification order, the result is the same (`T`) Another scenario that causes problems in a naive implementation of inference is self-recursive functions. Let's consider a generic factorial function `fact`, defined such that it also works for floating-point arguments -([playground](https://go.dev/play/p/s3wXpgHX6HQ)). +([playground](/play/p/s3wXpgHX6HQ)). Note that this is not a mathematically correct implementation of the [gamma function](https://en.wikipedia.org/wiki/Gamma_function), it is simply a convenient example. @@ -974,7 +974,7 @@ they denote the same generic functions irrespective of what the names of the typ For the purpose of this example, let's assume the `P` in the signature of `fact` got renamed to `Q`. The effect is as if the recursive call was done indirectly through a `helper` function -([playground](https://go.dev/play/p/TLpo-0auWwC)): +([playground](/play/p/TLpo-0auWwC)): ```Go func fact[P ~int | ~float64](n P) P { @@ -1000,7 +1000,7 @@ function that is being called, and the free type parameter `P`, declared by the function. This type equation is trivially solved for `Q` and results in the inference `Q ➞ P` which is of course what we'd expect, and which we can verify by explicitly instantiating -the recursive call ([playground](https://go.dev/play/p/zkUFvwJ54lC)): +the recursive call ([playground](/play/p/zkUFvwJ54lC)): ```Go func fact[P ~int | ~float64](n P) P { diff --git a/_content/blog/vuln.md b/_content/blog/vuln.md index 49b1e224..6f4829c7 100644 --- a/_content/blog/vuln.md +++ b/_content/blog/vuln.md @@ -36,14 +36,14 @@ and direct reports from Go package maintainers. This information is then reviewed by the Go security team and added to the database. We encourage package maintainers to [contribute](/s/vulndb-report-new) -information about public vulnerabilities in their own projects and [update](https://go.dev/s/vulndb-report-feedback) +information about public vulnerabilities in their own projects and [update](/s/vulndb-report-feedback) existing information about vulnerabilities in their Go packages. We aim to make reporting a low friction process, so please [send us your suggestions](https://golang.org/s/vuln-feedback) for any improvements. The Go vulnerability database can be viewed in your browser at [pkg.go.dev/vuln](https://pkg.go.dev/vuln). -For more information about the database, see [go.dev/security/vuln/database](https://go.dev/security/vuln/database). +For more information about the database, see [go.dev/security/vuln/database](/security/vuln/database). ## Vulnerability detection using govulncheck @@ -94,7 +94,7 @@ We would love for you to contribute and help us make improvements in the following ways: - [Contribute new](https://golang.org/s/vulndb-report-new) and - [update existing](https://go.dev/s/vulndb-report-feedback) information about + [update existing](/s/vulndb-report-feedback) information about public vulnerabilities for Go packages that you maintain - [Take this survey](https://golang.org/s/govulncheck-feedback) to share your experience using govulncheck diff --git a/_content/blog/wasi.md b/_content/blog/wasi.md index bc5e2ab5..965be46e 100644 --- a/_content/blog/wasi.md +++ b/_content/blog/wasi.md @@ -74,7 +74,7 @@ Hello world! That’s all it takes to get started with Wasm/WASI! You can expect almost all the features of Go to just work with `wasip1`. To learn more about the details of how WASI works with Go, please see -[the proposal](https://go.dev/issue/58141). +[the proposal](/issue/58141). ## Running go tests with wasip1 @@ -97,8 +97,8 @@ using the environment variable `GOWASIRUNTIME`. Currently supported values for this variable are `wazero`, `wasmedge`, `wasmtime`, and `wasmer`. This script is subject to breaking changes between Go versions. Note that Go `wasip1` binaries don’t execute perfectly on all hosts yet (see -[#59907](https://go.dev/issue/59907) and -[#60097](https://go.dev/issue/60097)). +[#59907](/issue/59907) and +[#60097](/issue/60097)). This functionality also works when using `go run`: @@ -145,7 +145,7 @@ eventually make its way to the host-defined `random_get` function. In the same way, users can define their own wrappers for host functions. To learn more about the intricacies of wrapping Wasm functions in Go, please -see [the `go:wasmimport` proposal](https://go.dev/issue/59149). +see [the `go:wasmimport` proposal](/issue/59149). ## Limitations diff --git a/_content/blog/when-generics.md b/_content/blog/when-generics.md index 92c0dcd1..28939a91 100644 --- a/_content/blog/when-generics.md +++ b/_content/blog/when-generics.md @@ -249,7 +249,7 @@ methods look exactly the same for all slice types. (I should mention that Go 1.19--not 1.18--will most likely include a generic function to sort a slice using a comparison function, and that generic function will most likely not use `sort.Interface`. -See [proposal #47619](https://go.dev/issue/47619). +See [proposal #47619](/issue/47619). But the general point is still true even if this specific example will most likely not be useful: it's reasonable to use type parameters when you need to implement methods that look the same for all the relevant @@ -335,7 +335,7 @@ so we shouldn't use type parameters. Instead, the package uses reflection. The code is not simple, but it works. For details, see [the source -code](https://go.dev/src/encoding/json/encode.go). +code](/src/encoding/json/encode.go). ## One simple guideline diff --git a/_content/blog/why-generics.md b/_content/blog/why-generics.md index 8b16c46f..9e02e833 100644 --- a/_content/blog/why-generics.md +++ b/_content/blog/why-generics.md @@ -359,8 +359,8 @@ discuss a design for how we think we can add them to the language. Note added January 2022: This blog post was written in 2019 and does not describe the version of generics that was finally adopted. For updated information please see the description of type parameters in -[the language spec](https://go.dev/ref/spec) and -[the generics design document](https://go.dev/design/43651-type-parameters). +[the language spec](/ref/spec) and +[the generics design document](/design/43651-type-parameters). At this year's Gophercon Robert Griesemer and I published [a design draft](https://github.com/golang/proposal/blob/master/design/go2draft-contracts.md) diff --git a/_content/doc/gc-guide.html b/_content/doc/gc-guide.html index cc081c6d..4a62c49f 100644 --- a/_content/doc/gc-guide.html +++ b/_content/doc/gc-guide.html @@ -112,7 +112,7 @@ be managed by the GC. For instance, non-pointer Go values stored in local variables will likely not be managed by the Go GC at all, and Go will instead arrange for memory to be allocated that's tied to the -<a href="https://go.dev/ref/spec#Declarations_and_scope">lexical scope</a> in +<a href="/ref/spec#Declarations_and_scope">lexical scope</a> in which it's created. In general, this is more efficient than relying on the GC, because the Go compiler is able to predetermine when that memory may be freed and emit @@ -1038,11 +1038,11 @@ For more information, see the following additional resources. document for the C/C++ memory allocator TCMalloc, which the Go memory allocator is based on. </li> <li> - <a href="https://go.dev/blog/go15gc">Go 1.5 GC announcement</a>—The + <a href="/blog/go15gc">Go 1.5 GC announcement</a>—The blog post announcing the Go 1.5 concurrent GC, which describes the algorithm in more detail. </li> <li> - <a href="https://go.dev/blog/ismmkeynote">Getting to Go</a>—An + <a href="/blog/ismmkeynote">Getting to Go</a>—An in-depth presentation about the evolution of Go's GC design up to 2018. </li> <li> diff --git a/_content/doc/go1.18.md b/_content/doc/go1.18.md index dbf74094..5d745cb1 100644 --- a/_content/doc/go1.18.md +++ b/_content/doc/go1.18.md @@ -229,7 +229,7 @@ FreeBSD 13.0+ will require a kernel with the COMPAT\_FREEBSD12 option set (this Go 1.18 includes an implementation of fuzzing as described by [the fuzzing proposal](https://golang.org/issue/44551). -See the [fuzzing landing page](https://go.dev/security/fuzz) to get +See the [fuzzing landing page](/security/fuzz) to get started. Please be aware that fuzzing can consume a lot of memory and may impact your @@ -531,7 +531,7 @@ Go now looks first for `$HOME/go1.17` or `$HOME/sdk/go1.17` before falling back to `$HOME/go1.4`. We intend for Go 1.19 to require Go 1.17 or later for bootstrap, and this change should make the transition smoother. -For more details, see [go.dev/issue/44505](https://go.dev/issue/44505). +For more details, see [go.dev/issue/44505](/issue/44505). ## Core library {#library} diff --git a/_content/doc/go1.19.md b/_content/doc/go1.19.md index 0a2cb88f..53dae468 100644 --- a/_content/doc/go1.19.md +++ b/_content/doc/go1.19.md @@ -167,7 +167,7 @@ a detailed guide explaining the soft memory limit in more detail, as well as a variety of common use-cases and scenarios. Please note that small memory limits, on the order of tens of megabytes or less, are less likely to be respected due to external latency factors, such as OS scheduling. See -[issue 52433](https://go.dev/issue/52433) for more details. Larger +[issue 52433](/issue/52433) for more details. Larger memory limits, on the order of hundreds of megabytes or more, are stable and production-ready. diff --git a/_content/doc/go1.20.md b/_content/doc/go1.20.md index 3d56a021..a9873af3 100644 --- a/_content/doc/go1.20.md +++ b/_content/doc/go1.20.md @@ -127,7 +127,7 @@ execute commands in multiple different modules. <!-- https://go.dev/issue/41696, CL 416094 --> The `go` `build` and `go` `test` commands no longer accept the `-i` flag, -which has been [deprecated since Go 1.16](https://go.dev/issue/41696). +which has been [deprecated since Go 1.16](/issue/41696). <!-- https://go.dev/issue/38687, CL 421440 --> The `go` `generate` command now accepts @@ -146,7 +146,7 @@ non-`main` packages to `GOPATH/pkg`, and `go` `list` no longer reports a `Target` field for such packages. (In module mode, compiled packages are stored in the [build cache](https://pkg.go.dev/cmd/go#hdr-Build_and_test_caching) -only, but [a bug](https://go.dev/issue/37015) had caused +only, but [a bug](/issue/37015) had caused the `GOPATH` install targets to unexpectedly remain in effect.) <!-- https://go.dev/issue/55022 --> @@ -228,7 +228,7 @@ To collect coverage data for a program, build it with `go` binary with the environment variable `GOCOVERDIR` set to an output directory for coverage profiles. See the -['coverage for integration tests' landing page](https://go.dev/testing/coverage) for more on how to get started. +['coverage for integration tests' landing page](/testing/coverage) for more on how to get started. For details on the design and implementation, see the [proposal](https://golang.org/issue/51430). @@ -424,7 +424,7 @@ Unlike `Director` hooks, which only operate on the outbound request, this permits `Rewrite` hooks to avoid certain scenarios where a malicious inbound request may cause headers added by the hook to be removed before forwarding. -See [issue #50580](https://go.dev/issue/50580). +See [issue #50580](/issue/50580). The [`ProxyRequest.SetURL`](/pkg/net/http/httputil/#ProxyRequest.SetURL) method routes the outbound request to a provided destination diff --git a/_content/doc/go1.21.md b/_content/doc/go1.21.md index b6cd3fcc..8f7184e2 100644 --- a/_content/doc/go1.21.md +++ b/_content/doc/go1.21.md @@ -115,7 +115,7 @@ Together, all these changes make type inference more powerful and inference fail Go 1.21 includes a preview of a language change we are considering for a future version of Go: making for loop variables per-iteration instead of per-loop, to avoid accidental sharing bugs. -For details about how to try that language change, see [the LoopvarExperiment wiki page](https://go.dev/wiki/LoopvarExperiment). +For details about how to try that language change, see [the LoopvarExperiment wiki page](/wiki/LoopvarExperiment). <!-- https://go.dev/issue/25448 --> @@ -673,7 +673,7 @@ correctly order the definition before any <!-- https://go.dev/issue/28089, CL 487935 --> The new [`IsGenerated`](/pkg/go/ast/#IsGenerated) predicate reports whether a file syntax tree contains the -[special comment](https://go.dev/s/generatedcode) +[special comment](/s/generatedcode) that conventionally indicates that the file was generated by a tool. <!-- https://go.dev/issue/59033, CL 476276 --> diff --git a/_content/doc/install/source.html b/_content/doc/install/source.html index 22469cc7..a3cc5820 100644 --- a/_content/doc/install/source.html +++ b/_content/doc/install/source.html @@ -728,7 +728,7 @@ default is <code>v1</code>) This sets the microarchitecture level for which to compile. Valid values are <code>v1</code> (default), <code>v2</code>, <code>v3</code>, <code>v4</code>. -See <a href="https://go.dev/wiki/MinimumRequirements#amd64">the Go wiki +See <a href="/wiki/MinimumRequirements#amd64">the Go wiki MinimumRequirements page</a> for more information. </p> </li> diff --git a/_content/doc/security/best-practices.md b/_content/doc/security/best-practices.md index fa0cac9a..0793390e 100644 --- a/_content/doc/security/best-practices.md +++ b/_content/doc/security/best-practices.md @@ -17,7 +17,7 @@ potential security risks early. You can use [govulncheck](https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck), backed by the [Go vulnerability database](https://pkg.go.dev), to scan your code for vulnerabilities and analyze which ones actually affect you. -Get started with [the govulncheck tutorial](https://go.dev/doc/tutorial/govulncheck). +Get started with [the govulncheck tutorial](/doc/tutorial/govulncheck). Govulncheck can also be integrated into CI/CD flows. The Go team provides a @@ -27,17 +27,17 @@ Govulncheck also supports a `-json` flag to help developers integrate vulnerabil scanning with other CI/CD systems. You can also scan for vulnerabilities directly in your code editor by using -the [Go extension for Visual Studio Code](https://go.dev/security/vuln/editor). -Get started with [this tutorial](https://go.dev/doc/tutorial/govulncheck-ide). +the [Go extension for Visual Studio Code](/security/vuln/editor). +Get started with [this tutorial](/doc/tutorial/govulncheck-ide). ## Keep your Go version and dependencies up to date -Keeping your [Go version up-to-date](https://go.dev/doc/install) offers +Keeping your [Go version up-to-date](/doc/install) offers access to the latest language features, performance improvements and patches for known security vulnerabilities. An updated Go version also ensures compatibility with newer versions of dependencies, helping to avoid potential integration issues. -Review the [Go release history](https://go.dev/doc/devel/release) to see +Review the [Go release history](/doc/devel/release) to see what changes have been made to Go between releases. The Go team issues point releases throughout the release cycle to address security bugs. Be sure to update to the latest minor Go version to ensure you have the @@ -55,22 +55,22 @@ each update should be carefully reviewed and tested. ## Test with fuzzing to uncover edge-case exploits -[Fuzzing](https://go.dev/security/fuzz) is a type of automated testing that +[Fuzzing](/security/fuzz) is a type of automated testing that uses coverage guidance to manipulate random inputs and walk through code to find and report potential vulnerabilities like SQL injections, buffer overflows, denial or service and cross-site scripting attacks. Fuzzing can often reach edge cases that programmers miss, or deem too improbable to test. -Get started with [this tutorial](https://go.dev/doc/tutorial/fuzz). +Get started with [this tutorial](/doc/tutorial/fuzz). ## Check for race conditions with Go’s race detector -Race conditions occur when two or more [goroutines](https://go.dev/tour/concurrency/1) +Race conditions occur when two or more [goroutines](/tour/concurrency/1) access the same resource concurrently, and at least one of those accesses is a write. This can lead to unpredictable, difficult-to-diagnose issues in your software. Identify potential race conditions in your Go code using the built-in -[race detector](https://go.dev/doc/articles/race_detector), +[race detector](/doc/articles/race_detector), which can help you ensure the safety and reliability of your concurrent programs. The race detector finds races that occur at runtime, however, so it will not find races in code paths that are not executed. @@ -81,7 +81,7 @@ for example, `go test -race`. This will compile your code with the race detector enabled and report any race conditions it detects at runtime. When the race detector finds a data race in the program, it will -[print a report](https://go.dev/doc/articles/race_detector#report-format) +[print a report](/doc/articles/race_detector#report-format) containing stack traces for conflicting accesses, and stacks where the involved goroutines were created. diff --git a/_content/doc/security/index.md b/_content/doc/security/index.md index 7df9067c..26560f11 100644 --- a/_content/doc/security/index.md +++ b/_content/doc/security/index.md @@ -6,13 +6,13 @@ layout: article This page provides resources for Go developers to improve security for their projects. -(See also: [Security Best Practices for Go Developers](https://go.dev/security/best-practices).) +(See also: [Security Best Practices for Go Developers](/security/best-practices).) ## Find and fix known vulnerabilities Go’s vulnerability detection aims to provide low-noise, reliable tools for developers to learn about known vulnerabilities that may affect their projects. -For an overview, start at [this summary and FAQ page](https://go.dev/security/vuln) +For an overview, start at [this summary and FAQ page](/security/vuln) about Go’s vulnerability management architecture. For an applied approach, explore the tools below. @@ -23,15 +23,15 @@ vulnerabilities affect their code and prioritize next steps based on which vulne functions and methods are actually called. - [View the govulncheck documentation](https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck) -- [Tutorial: Get started with govulncheck](https://go.dev/doc/tutorial/govulncheck) +- [Tutorial: Get started with govulncheck](/doc/tutorial/govulncheck) ### Detect vulnerabilities from your editor The VS Code Go extension checks third-party dependencies and surfaces relevant vulnerabilities. -- [User documentation](https://go.dev/security/vuln/editor) +- [User documentation](/security/vuln/editor) - [Download VS Code Go](https://marketplace.visualstudio.com/items?itemName=golang.go) -- [Tutorial: Get started with VS Code Go](https://go.dev/doc/tutorial/govulncheck-ide) +- [Tutorial: Get started with VS Code Go](/doc/tutorial/govulncheck-ide) ### Find Go modules to build upon @@ -50,20 +50,20 @@ maintainers as well as from outside sources such as [MITRE](https://www.cve.org/ are curated by the Go Security team. - [Browse reports in the Go vulnerability database](https://pkg.go.dev/vuln/) -- [View the Go Vulnerability Database documentation](https://go.dev/security/vuln/database) -- [Contribute a public vulnerability to the database](https://go.dev/s/vulndb-report-new) +- [View the Go Vulnerability Database documentation](/security/vuln/database) +- [Contribute a public vulnerability to the database](/s/vulndb-report-new) ## Report security bugs in the Go project -### [Security Policy](https://go.dev/security/policy) +### [Security Policy](/security/policy) Consult the Security Policy for instructions on how to -[report a vulnerability in the Go project](https://go.dev/security/policy#reporting-a-security-bug). +[report a vulnerability in the Go project](/security/policy#reporting-a-security-bug). The page also details the Go security team’s process of tracking issues and disclosing them to the public. See the -[release history](https://go.dev/doc/devel/release) for details about past security -fixes. Per the [release policy](https://go.dev/doc/devel/release#policy), +[release history](/doc/devel/release) for details about past security +fixes. Per the [release policy](/doc/devel/release#policy), we issue security fixes to the two most recent major releases of Go. ## Test unexpected inputs with fuzzing @@ -73,8 +73,8 @@ manipulates inputs to a program to find bugs. Go supports fuzzing in its standard toolchain beginning in Go 1.18. Native Go fuzz tests are [supported by OSS-Fuzz](https://google.github.io/oss-fuzz/getting-started/new-project-guide/go-lang/#native-go-fuzzing-support). -- [Review the basics of fuzzing](https://go.dev/security/fuzz) -- [Tutorial: Get started with fuzzing](https://go.dev/doc/tutorial/fuzz) +- [Review the basics of fuzzing](/security/fuzz) +- [Tutorial: Get started with fuzzing](/doc/tutorial/fuzz) ## Secure services with Go's cryptography libraries diff --git a/_content/doc/security/vuln/database.md b/_content/doc/security/vuln/database.md index 06389842..26b75e86 100644 --- a/_content/doc/security/vuln/database.md +++ b/_content/doc/security/vuln/database.md @@ -19,13 +19,13 @@ without warning. ## Contributing -We would love for all Go package maintainers to [contribute](https://go.dev/s/vulndb-report-new) +We would love for all Go package maintainers to [contribute](/s/vulndb-report-new) information about public vulnerabilities in their own projects, -and [update](https://go.dev/s/vulndb-report-feedback) existing information about vulnerabilities +and [update](/s/vulndb-report-feedback) existing information about vulnerabilities in their Go packages. We aim to make reporting a low friction process, -so feel free to [send us your suggestions](https://go.dev/s/vuln-feedback). +so feel free to [send us your suggestions](/s/vuln-feedback). Please **do not** use the forms above to report a vulnerability in the Go standard library or sub-repositories. @@ -131,7 +131,7 @@ To work correctly with `govulncheck`, the vulnerability database specified must The canonical database contains some additional endpoints that are part of a legacy API. We plan to remove support for these endpoints soon. If you are relying on the legacy API -and need additional time to migrate, [please let us know](https://go.dev/s/govulncheck-feedback). +and need additional time to migrate, [please let us know](/s/govulncheck-feedback). ## Schema @@ -241,4 +241,4 @@ At the moment, excluded reports are not served via [vuln.go.dev](https://vuln.go.dev) API. However, if you have a specific use case and it would be helpful to have access to this information through the API, -[please let us know](https://go.dev/s/govulncheck-feedback). +[please let us know](/s/govulncheck-feedback). diff --git a/_content/doc/security/vuln/index.md b/_content/doc/security/vuln/index.md index 080a5ab0..8de5ec00 100644 --- a/_content/doc/security/vuln/index.md +++ b/_content/doc/security/vuln/index.md @@ -97,7 +97,7 @@ We would love for you to contribute and help us make improvements in the following ways: - [Contribute new](https://golang.org/s/vulndb-report-new) and - [update existing](https://go.dev/s/vulndb-report-feedback) information about + [update existing](/s/vulndb-report-feedback) information about public vulnerabilities for Go packages that you maintain - [Take this survey](https://golang.org/s/govulncheck-feedback) to share your experience using govulncheck diff --git a/_content/doc/tutorial/fuzz.md b/_content/doc/tutorial/fuzz.md index 8957197c..95516bba 100644 --- a/_content/doc/tutorial/fuzz.md +++ b/_content/doc/tutorial/fuzz.md @@ -717,7 +717,7 @@ UTF-8. In addition to the `-fuzz` flag, several new flags have been added to `go test` and can be viewed in the [documentation](/security/fuzz/#custom-settings). - See [Go Fuzzing](https://go.dev/security/fuzz/#command-line-output) for more + See [Go Fuzzing](/security/fuzz/#command-line-output) for more information on terms used in fuzzing output. For example, "new interesting" refers to inputs that expand the code coverage of the existing fuzz test corpus. The number of "new interesting" inputs can be expected to increase @@ -810,4 +810,4 @@ func FuzzReverse(f *testing.F) { } ``` -[Back to top](#top)
\ No newline at end of file +[Back to top](#top) diff --git a/_content/doc/tutorial/govulncheck-ide.md b/_content/doc/tutorial/govulncheck-ide.md index 53e6dc40..fc36b28a 100644 --- a/_content/doc/tutorial/govulncheck-ide.md +++ b/_content/doc/tutorial/govulncheck-ide.md @@ -7,14 +7,14 @@ You can scan your code for vulnerabilities directly out of your editor with the Go extension for Visual Studio Code. -Note: for an explanation of the vulnerability fix included in the images below, see the [govulncheck tutorial](https://go.dev/doc/tutorial/govulncheck). +Note: for an explanation of the vulnerability fix included in the images below, see the [govulncheck tutorial](/doc/tutorial/govulncheck). ## Prerequisites: -- **Go 1.18 or later.** Govulncheck is designed to work with Go 1.18 onwards. For installation instructions, see [Installing Go](https://go.dev/doc/install). We recommend using the latest version of Go to follow this tutorial. -- **VS Code**, updated to the latest version. [Download here](https://code.visualstudio.com/). You can also use Vim (see [here](https://go.dev/security/vuln/editor#editor-specific-instructions) for details), but this tutorial focuses on VS Code Go. +- **Go 1.18 or later.** Govulncheck is designed to work with Go 1.18 onwards. For installation instructions, see [Installing Go](/doc/install). We recommend using the latest version of Go to follow this tutorial. +- **VS Code**, updated to the latest version. [Download here](https://code.visualstudio.com/). You can also use Vim (see [here](/security/vuln/editor#editor-specific-instructions) for details), but this tutorial focuses on VS Code Go. - **VS Code Go extension**, which can be [downloaded here](https://marketplace.visualstudio.com/items?itemName=golang.go). -- **Editor-specific settings changes.** You will need to modify your IDE settings according to [these specifications](https://go.dev/security/vuln/editor#editor-specific-instructions) before being able to replicate the results below. +- **Editor-specific settings changes.** You will need to modify your IDE settings according to [these specifications](/security/vuln/editor#editor-specific-instructions) before being able to replicate the results below. ## How to scan for vulnerabilities using VS Code Go @@ -110,6 +110,6 @@ Code actions can also be used to quickly upgrade to a version of your dependency ## Additional resources -- See [this page](https://go.dev/security/vuln/editor) for more information about vulnerability scanning in your IDE. The [Notes and Caveats section](https://go.dev/security/vuln/editor#notes-and-caveats), in particular, discusses special cases for which vulnerability scanning may be more complex than in the example above. +- See [this page](/security/vuln/editor) for more information about vulnerability scanning in your IDE. The [Notes and Caveats section](/security/vuln/editor#notes-and-caveats), in particular, discusses special cases for which vulnerability scanning may be more complex than in the example above. - The [Go Vulnerability Database](https://pkg.go.dev/vuln/) contains information from many existing sources in addition to direct reports by Go package maintainers to the Go security team. -- See [Go Vulnerability Management](https://go.dev/security/vuln/) page provides a high-level view of Go's architecture for detecting, reporting and managing vulnerabilities.
\ No newline at end of file +- See [Go Vulnerability Management](/security/vuln/) page provides a high-level view of Go's architecture for detecting, reporting and managing vulnerabilities. diff --git a/_content/doc/tutorial/govulncheck.md b/_content/doc/tutorial/govulncheck.md index c5cfabe6..e329c6ae 100644 --- a/_content/doc/tutorial/govulncheck.md +++ b/_content/doc/tutorial/govulncheck.md @@ -16,13 +16,13 @@ ones first. To learn more about govulncheck, see the [govulncheck documentation](https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck), -and this [blog post on vulnerability management](https://go.dev/blog/vuln) for Go. -We'd also love to [hear your feedback](https://go.dev/s/govulncheck-feedback). +and this [blog post on vulnerability management](/blog/vuln) for Go. +We'd also love to [hear your feedback](/s/govulncheck-feedback). ## Prerequisites - **Go 1.18 or later.** Govulncheck is designed to work with Go 1.18 onwards. - (For installation instructions, see [Installing Go](https://go.dev/doc/install).) + (For installation instructions, see [Installing Go](/doc/install).) We recommend using the latest version of Go to follow this tutorial. - **A code editor.** Any editor you have will work fine. - **A command terminal.** Go works well using any terminal on Linux and Mac, and on PowerShell or cmd in Windows. diff --git a/_content/doc/tutorial/workspaces.md b/_content/doc/tutorial/workspaces.md index 2df1cfc3..91668ef3 100644 --- a/_content/doc/tutorial/workspaces.md +++ b/_content/doc/tutorial/workspaces.md @@ -24,7 +24,7 @@ of those changes in a build. and on PowerShell or cmd in Windows. This tutorial requires go1.18 or later. Make sure you've installed Go at Go 1.18 or later using the -links at [go.dev/dl](https://go.dev/dl). +links at [go.dev/dl](/dl). ## Create a module for your code {#create_folder} @@ -244,7 +244,7 @@ We'll then add a new function to the `reverse` package that we can use instead o file, and similarly resolves the `golang.org/x/example/hello/reverse` import using the `go.work` file. - `go.work` can be used instead of adding [`replace`](https://go.dev/ref/mod#go-mod-file-replace) + `go.work` can be used instead of adding [`replace`](/ref/mod#go-mod-file-replace) directives to work across multiple modules. Since the two modules are in the same workspace it's easy @@ -255,7 +255,7 @@ We'll then add a new function to the `reverse` package that we can use instead o Now, to properly release these modules we'd need to make a release of the `golang.org/x/example/hello` module, for example at `v0.1.0`. This is usually done by tagging a commit on the module's version control repository. See the - [module release workflow documentation](https://go.dev/doc/modules/release-workflow) + [module release workflow documentation](/doc/modules/release-workflow) for more details. Once the release is done, we can increase the requirement on the `golang.org/x/example/hello` module in `hello/go.mod`: @@ -277,5 +277,5 @@ We'll then add a new function to the `reverse` package that we can use instead o - `go work edit` edits the `go.work` file similarly to `go mod edit` - `go work sync` syncs dependencies from the workspace's build list into each of the workspace modules. - See [Workspaces](https://go.dev/ref/mod#workspaces) in the Go Modules Reference for more detail on + See [Workspaces](/ref/mod#workspaces) in the Go Modules Reference for more detail on workspaces and `go.work` files. |