Installing Go & Development Environment

Introduction

Before writing production Go, you need a reliable toolchain: the Go SDK, an editor with gopls (Go language server), and environment variables configured correctly.

This lesson covers installing Go 1.22+ on macOS, Linux, or Windows; choosing between VS Code + Go extension and GoLand; and verifying your setup with go version and go env. Enterprise teams pin Go versions in go.mod and CI so every developer and pipeline builds identically.

A correct setup prevents hours of "works on my machine" friction. You will initialize your first module, understand module cache and vendor folders, and configure workspace settings — habits interviewers expect from day one.

The story

A platform team onboarding five engineers across macOS, Linux, and Windows CI runners standardizes on Go 1.22+ with a checked-in go.mod and toolchain directive. Without that pin, one developer compiles with Go 1.21 while GitHub Actions uses 1.22, and a for range over an integer loop behaves differently — a subtle bug that only surfaces in the pipeline.

They install gopls for IDE navigation, enable go vet and staticcheck in pre-commit hooks, and verify setup with a hello-world binary that prints the runtime version. That five-minute setup prevents hours of "works on my laptop" incidents before code reaches a Kubernetes cluster.

Understanding the topic

Key concepts

• The Go toolchain includes the compiler, linker, go fmt, go test, go mod, and godoc.
• GOROOT points to the SDK installation; GOPATH is legacy — modules replaced it as the default workflow.
• go.mod declares module path and Go version; go.sum records dependency checksums for reproducibility.
• gopls provides IDE features: autocomplete, go-to-definition, refactoring, and diagnostics.
• Cross-compilation: GOOS and GOARCH build binaries for any supported platform from one machine.
• asdf, mise, or goenv manage multiple Go versions on developer laptops.

flowchart LR
  IDE[VS Code / GoLand] --> SDK[Go 1.22+]
  SDK --> CLI[go mod / go test]
  CLI --> Build[Build & Run]
  Build --> Bin[bin / dist]

Step-by-step explanation

1. Download Go from go.dev/dl or install via Homebrew (brew install go), apt, or winget.
2. Run go version to confirm 1.22.x and go env to inspect GOROOT, GOPATH, GOOS, GOARCH.
3. Install VS Code with the Go extension (gopls installs on first open) or JetBrains GoLand.
4. Create a project: mkdir hello && cd hello && go mod init example.com/hello && go run .
5. Open the folder in your IDE — gopls indexes packages for autocomplete and error highlighting.
6. Commit go.mod and go.sum; add .gitignore entries for bin/ and coverage artifacts.

Practical code example

Initialize a module and verify the toolchain with a minimal go.mod and main.go:

// go.mod
module github.com/techlearningpro/hello

go 1.22

// main.go
package main

import "fmt"

func main() {
	fmt.Println("TechLearningPRO Go setup verified!")
	fmt.Printf("Module: %s\n", "github.com/techlearningpro/hello")
}

Line-by-line code explanation

• go env GOVERSION prints the active toolchain version — compare it with your CI image.
• go mod init example.com/myapp creates go.mod with your module path.
• go tool toolchain install go1.22.5 downloads a specific compiler when using toolchain directives.
• go install golang.org/x/tools/gopls@latest installs the language server for VS Code and Cursor.
• go vet ./... runs static checks that catch common mistakes before tests run.
• GOPROXY=https://proxy.golang.org,direct configures module download behavior in corporate networks.
• GOOS=linux GOARCH=amd64 go build cross-compiles a Linux binary from macOS — standard in Docker builds.
• .gitignore should exclude /bin, /vendor (unless vendored), and IDE artifacts.

Key takeaway: The go directive in go.mod pins the minimum language version. CI should use the same version via actions/setup-go or equivalent.

Real-world use

Where you'll use this in production

• Onboarding new hires to a Go microservice monorepo with pinned Go version in go.mod.
• Setting up CI agents (GitHub Actions, GitLab CI) with matching go-version matrix.
• Teaching bootcamp students an identical environment across macOS and Linux laptops.
• Cross-compiling Linux amd64 binaries from a Mac developer machine for Docker builds.

Best practices

• Pin Go version in go.mod and CI configuration for every team repository.
• Run go fmt ./... and go vet ./... before every commit; add golangci-lint in CI.
• Use go work for local multi-module development without replace hacks.
• Store secrets in environment variables or secret managers — never in source control.
• Verify install with go version after every SDK upgrade.
• Enable Go modules mode explicitly if legacy tooling interferes: GO111MODULE=on.
• Document setup steps in README.md for reproducible onboarding.

Common mistakes

• Installing an outdated Go version — check go.dev for current stable release.
• Mixing GOPATH mode with modules — always use go mod init for new projects.
• Ignoring go.sum changes in PRs — they protect against dependency tampering.
• Checking compiled binaries into Git — add /bin or /dist to .gitignore.
• Not installing gopls — IDE shows no autocomplete or type information.

Advanced interview questions

Summary

Install Go 1.22+ and an IDE (VS Code + Go extension or GoLand). Verify with go version; create projects via go mod init and go run. Pin Go versions in go.mod for team and CI consistency. Run go fmt and go vet early; add golangci-lint in CI. Next lesson: your first complete Go program structure and entry point.