Free preview · Session 1 · Go Backend Development

Chapter 1 — Environment Setup and the Go Toolchain

Objectives. By the end of this session you can install Go 1.27.3 and an editor, run and build a first program, format it with gofmt, and describe what the toolchain produces. Time budget: about 2 hours — roughly 40 minutes of theory and 80 minutes hands-on. This session also delivers the short Windows/WSL2 setup path.

Theory

What Go is, and why this course starts with the toolchain

Go is a compiled, statically typed language designed at Google for building networked services: small language, fast builds, a single static binary out the other end, and a standard library that covers most of what a backend needs before any framework is imported. If you come from Python or JavaScript, the biggest shift is that the toolchain is not an accessory — it is one program, go, that builds, tests, formats, vets and manages modules. If you come from Java or C#, the shift is how little ceremony surrounds it: no separate build system to configure, no classpath, no project file format to learn.

This course therefore starts by making the toolchain boring. Every later session assumes go run, go build, gofmt and go vet are reflexes.

One distribution, one command

Installing Go gives you the compiler, the linker, the standard library and the go command in a single tree. The commands you will use daily:

go run . — compile the current package in a temporary place and run it. For learning and small tools.
go build — compile and keep the binary. This is what you ship.
gofmt / go fmt ./... — rewrite source into the one canonical format. Not optional, not a matter of taste: Go has exactly one style, enforced by the tool, which ends every formatting debate before it starts.
go vet ./... — run the built-in static checks (suspicious Printf calls, unreachable code patterns, and more).
go version — print the toolchain version. Your first verification step on any machine.

There is no separate runtime to install on the target machine: a built binary carries the Go runtime inside it. That single fact explains much of Go's popularity for backends and command-line tools.

Modules replaced GOPATH

Older material talks about GOPATH and arranging code under src/. That world is gone. Since Go 1.16, every project is a module: a directory with a go.mod file at its root that names the module and pins its Go version. Session 3 builds modules properly; today it is enough to know that you always work inside a module, and that go mod init creates one. (A workspace, go.work, exists for coordinating several modules at once — awareness only; this programme does not use one.)

Editor setup

Use VS Code with the official Go extension (which drives gopls, the language server), or GoLand if you already own it. The extension gives you format-on-save, vet on save, and navigation. Turn on format-on-save now; from today your code is always gofmt-clean because the editor makes it so, not because you remembered.

Windows: the WSL2 path

Go work on Windows is done inside WSL2 (Windows Subsystem for Linux), so the environment matches the Linux servers your code will run on:

In an administrator PowerShell, run wsl --install and restart when asked. This installs WSL2 with Ubuntu.
Open Ubuntu, create your Linux user, then run sudo apt update.
Install Go inside Ubuntu from the official tarball (go.dev/dl): download, extract to /usr/local, and add /usr/local/go/bin to your shell PATH.
Verify with go version inside Ubuntu — you should see go1.27.3.
Install VS Code on Windows with the WSL extension, open your Ubuntu folder with code . from inside WSL, and install the Go extension into the WSL side when prompted.
Keep all Go code inside the Linux filesystem (your Ubuntu home directory), never under /mnt/c/... — file access across that boundary is slow and permission behaviour differs.

Linux and macOS users skip this: install Go from go.dev/dl (package or tarball), verify go version, install the editor extension, done.

Worked examples

Example 1.1 — Hello, backend

// Example 1.1 — the first program: hello, backend.
package main

import "fmt"

func main() {
	fmt.Println("hello, backend")
}

Three facts are already visible. The file declares package main: a program (as opposed to a library) always lives in package main. The entry point is func main() — no arguments, no return value. And fmt.Println is imported from the standard library package fmt. Run it and build it:

go run .
go build -o hello .
./hello

Real output of the run:

hello, backend

go run and the built binary print the same line; the difference is what remains afterwards — go build leaves you a file you can copy to any machine of the same OS and architecture and run without Go installed.

Example 1.2 — Asking the toolchain about itself

// Example 1.2 — asking the toolchain about itself at runtime.
package main

import (
	"fmt"
	"runtime"
)

func main() {
	fmt.Println("Go version:", runtime.Version())
	fmt.Println("OS/arch:  ", runtime.GOOS+"/"+runtime.GOARCH)
	fmt.Println("CPUs:     ", runtime.NumCPU())
}

The runtime package describes the environment the program is running in. Output (captured on the verification machine; your CPU count will differ):

Go version: go1.27.3
OS/arch:   linux/amd64
CPUs:      2

Two habits start here. First, imports are grouped in parentheses when there are several. Second, Println inserts spaces between its arguments and a newline at the end — later sessions switch to Printf when exact layout matters.

Guided lab

Install Go 1.27.3 for your platform (Windows users: the WSL2 path above). Open a fresh terminal.
Run go version.

Guided lab.

Expected: go version go1.27.3 with your OS and architecture. Any other version: your PATH is finding a different installation — fix that before continuing.

Create a folder hello, enter it, and run go mod init hello. Look at the go.mod file that appears.
Write Example 1.1 as main.go. Run go run ., then go build, then run the binary directly.
Deliberately mis-format the file (extra spaces, odd indentation). Run gofmt -w main.go and view the diff if your editor shows one.

Guided lab.

Expected: the file is rewritten to canonical form. gofmt -l . afterwards prints nothing.

Write Example 1.2 in a second folder with its own module and run it. Record your version, OS/arch and CPU count in your notes — Session 22's troubleshooting method starts from exactly these facts.

Practice exercises

Exercise 1.1 (core). Write a program that prints a three-line environment card — program name, your role line, and a session number — holding each value in a variable first.
Exercise 1.2 (core). Print hello, backend and toolchain ready on separate lines twice: once with two calls, once with a single call using \n.
Exercise 1.3 (core). Using the runtime package, print your platform and CPU count in one labelled line.
Exercise 1.4 (stretch). Print runtime.Version() and runtime.GOMAXPROCS(0) and, in a comment, state in one sentence what each reports.

Solutions are in the appendix (Appendix A, Chapter 1).

Common errors and pitfalls

go: command not found right after installing. The shell has not picked up the new PATH, or the install added Go to a PATH your terminal does not read. Open a fresh terminal; on WSL2, confirm you installed Go inside Ubuntu, not on Windows.
An old version keeps answering. Two installations, and PATH order decides. which go (Linux/macOS/WSL) shows which one wins.
Editing files under /mnt/c in WSL2. Builds work but are slow, and file permissions surprise you. Move the project into your Linux home directory.
Running go run main.go in a multi-file package later and getting "undefined" errors. go run main.go compiles only that file; go run . compiles the whole package. Form the . habit now.

Session summary

Go ships as one toolchain: the go command builds, runs, formats and vets; a module (go.mod) is the unit of work; a built binary needs nothing else installed to run. Windows development happens inside WSL2 so your environment matches production Linux.

Key points.

The toolchain version for this whole programme is Go 1.27.3; every go.mod says go 1.27.

go run . for learning, go build for keeping, gofmt always, go vet ./... before you call anything finished.

Modules replaced GOPATH. If a tutorial mentions GOPATH workspaces, it is out of date.

GO101 · Session 1: Environment setup and the Go toolchain

Session videos