update go wiki link (#723)

contributing.md

@@ -28,7 +28,7 @@ If you don't feel confident to submit your own guide, submitting an issue for so
   * Thinking of examples that showcase what you're trying to teach without confusing the reader with other features is important.
   * For example you can learn about `struct`s without understanding pointers.
   * Brevity is king.
-* Follow the [Code Review Comments style guide](https://github.com/golang/go/wiki/CodeReviewComments). It's important for a consistent style across all the sections.
+* Follow the [Code Review Comments style guide](https://go.dev/wiki/CodeReviewComments). It's important for a consistent style across all the sections.
 * Your section should have a runnable application at the end \(e.g `package main` with a `main` func\) so users can see it in action and play with it.
 * All tests should pass.
 * Run `./build.sh` before raising PR.

install-go.md

@@ -5,7 +5,8 @@ The official installation instructions for Go are available [here](https://golan
 ## Go Environment
 
 ### Go Modules
-Go 1.11 introduced [Modules](https://github.com/golang/go/wiki/Modules). This approach is the default build mode since Go 1.16, therefore the use of `GOPATH` is not recommended.
+
+Go 1.11 introduced [Modules](https://go.dev/wiki/Modules). This approach is the default build mode since Go 1.16, therefore the use of `GOPATH` is not recommended.
 
 Modules aim to solve problems related to dependency management, version selection and reproducible builds; they also enable users to run Go code outside of `GOPATH`.
 

integers.md

@@ -4,7 +4,7 @@
 
 Integers work as you would expect. Let's write an `Add` function to try things out. Create a test file called `adder_test.go` and write this code.
 
-**Note:** Go source files can only have one `package` per directory. Make sure that your files are organised into their own packages. [Here is a good explanation on this.](https://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project) 
+**Note:** Go source files can only have one `package` per directory. Make sure that your files are organised into their own packages. [Here is a good explanation on this.](https://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project)
 
 Your project directory might look something like this:
 
@@ -13,7 +13,7 @@ learnGoWithTests
     |
     |-> helloworld
     |    |- hello.go
-    |    |- hello_test.go    
+    |    |- hello_test.go
     |
     |-> integers
     |    |- adder_test.go
@@ -69,7 +69,7 @@ Now run the tests and we should be happy that the test is correctly reporting wh
 
 `adder_test.go:10: expected '4' but got '0'`
 
-If you have noticed we learnt about _named return value_ in the [last](hello-world.md#one...last...refactor?) section but aren't using the same here. It should generally be used when the meaning of the result isn't clear from context, in our case it's pretty much clear that `Add` function will add the parameters. You can refer [this](https://github.com/golang/go/wiki/CodeReviewComments#named-result-parameters) wiki for more details.
+If you have noticed we learnt about _named return value_ in the [last](hello-world.md#one...last...refactor?) section but aren't using the same here. It should generally be used when the meaning of the result isn't clear from context, in our case it's pretty much clear that `Add` function will add the parameters. You can refer [this](https://go.dev/wiki/CodeReviewComments#named-result-parameters) wiki for more details.
 
 ## Write enough code to make it pass
 
@@ -85,7 +85,7 @@ Ah hah! Foiled again, TDD is a sham right?
 
 We could write another test, with some different numbers to force that test to fail but that feels like [a game of cat and mouse](https://en.m.wikipedia.org/wiki/Cat_and_mouse).
 
-Once we're more familiar with Go's syntax I will introduce a technique called *"Property Based Testing"*, which would stop annoying developers and help you find bugs.
+Once we're more familiar with Go's syntax I will introduce a technique called _"Property Based Testing"_, which would stop annoying developers and help you find bugs.
 
 For now, let's fix it properly
 
@@ -162,7 +162,7 @@ If you publish your code with examples to a public URL, you can share the docume
 
 What we have covered:
 
-* More practice of the TDD workflow
-* Integers, addition
-* Writing better documentation so users of our code can understand its usage quickly
-* Examples of how to use our code, which are checked as part of our tests
+*   More practice of the TDD workflow
+*   Integers, addition
+*   Writing better documentation so users of our code can understand its usage quickly
+*   Examples of how to use our code, which are checked as part of our tests

structs-methods-and-interfaces.md

@@ -392,7 +392,7 @@ This kind of approach of using interfaces to declare **only what you need** is v
 
 Now that you have some understanding of structs we can introduce "table driven tests".
 
-[Table driven tests](https://github.com/golang/go/wiki/TableDrivenTests) are useful when you want to build a list of test cases that can be tested in the same manner.
+[Table driven tests](https://go.dev/wiki/TableDrivenTests) are useful when you want to build a list of test cases that can be tested in the same manner.
 
 ```go
 func TestArea(t *testing.T) {

sync.md

@@ -255,7 +255,7 @@ We've covered a few things from the [sync package](https://golang.org/pkg/sync/)
 ### When to use locks over channels and goroutines?
 
 [We've previously covered goroutines in the first concurrency chapter](concurrency.md) which let us write safe concurrent code so why would you use locks?
-[The go wiki has a page dedicated to this topic; Mutex Or Channel](https://github.com/golang/go/wiki/MutexOrChannel)
+[The go wiki has a page dedicated to this topic; Mutex Or Channel](https://go.dev/wiki/MutexOrChannel)
 
 > A common Go newbie mistake is to over-use channels and goroutines just because it's possible, and/or because it's fun. Don't be afraid to use a sync.Mutex if that fits your problem best. Go is pragmatic in letting you use the tools that solve your problem best and not forcing you into one style of code.