Development Environment and Toolchain

Development Environment and Toolchain

Go's toolchain design philosophy can be summarized in one sentence: One binary does everything. You don't need Maven, Gradle, Webpack, pip, or cargo as separate build tools — the go command itself is a compiler, package manager, test framework, code formatter, and documentation generator combined into one.

This isn't accidental. Rob Pike was explicit when designing Go: the unification of the toolchain is equally important as the simplicity of the language itself. A team shouldn't waste time debating "which build tool to use," "which test framework to pick," or "how to unify code style." Go eliminates these debates once and for all by making mandatory decisions at the toolchain level.

Level 1: What You Need to Know

Installing Go

Installing Go is extremely simple. Visit https://go.dev/dl/ and download the installer for your operating system.

macOS:

# Option 1: Official installer (recommended)
# Download go1.22.x.darwin-arm64.pkg (Apple Silicon) or darwin-amd64.pkg (Intel)
# Double-click to install

# Option 2: Homebrew
brew install go

# Verify installation
go version
# go version go1.22.4 darwin/arm64

Linux:

# Download and extract to /usr/local
wget https://go.dev/dl/go1.22.4.linux-amd64.tar.gz
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.22.4.linux-amd64.tar.gz

# Add to PATH (write to ~/.bashrc or ~/.zshrc)
export PATH=$PATH:/usr/local/go/bin
export PATH=$PATH:$(go env GOPATH)/bin

# Verify
go version

Windows:

# Download .msi installer, double-click to install
# Default installation to C:\Program Files\Go
# The installer automatically sets PATH

go version

After installation, the Go executable is located at $GOROOT/bin/go (typically /usr/local/go/bin/go), and standard library source code is in $GOROOT/src/.

GOPATH vs Go Modules

Go's dependency management underwent a major paradigm shift. Understanding this history avoids a lot of confusion.

The GOPATH Era (Go 1.0 - Go 1.10, 2012-2018):

Early Go used the GOPATH environment variable to manage all code. The rules were simple but strict:

• All Go code must reside under $GOPATH/src/
• Third-party packages are downloaded via go get into $GOPATH/src/
• No version management — go get always fetches the latest code

# Typical GOPATH-era directory structure
$GOPATH/
├── bin/          # Compiled executables
├── pkg/          # Compiled package files (.a)
└── src/          # All source code
    ├── github.com/
    │   ├── user/project/     # Your project
    │   └── lib-author/lib/   # Third-party library
    └── golang.org/x/         # Official extension packages

Problems with GOPATH:

1. All projects share the same dependency versions — project A needs lib v1.2, project B needs lib v1.5, they can't coexist
2. No version locking — today's go get might produce different code than tomorrow's
3. Forced directory structure — can't create Go projects in arbitrary locations

The Go Modules Era (Go 1.11+, 2018 to present):

Go 1.11 introduced Go Modules (go mod), fundamentally changing dependency management. Starting from Go 1.16, Go Modules became the default mode.

# Create a new project in any directory
mkdir ~/projects/myapp && cd ~/projects/myapp

# Initialize the module
go mod init github.com/yourname/myapp

# This creates a go.mod file

go.mod file anatomy:

module github.com/yourname/myapp

go 1.22

require (
    github.com/gin-gonic/gin v1.9.1
    github.com/redis/go-redis/v9 v9.5.1
    go.uber.org/zap v1.27.0
)

require (
    // indirect dependencies (automatically managed, no manual editing needed)
    github.com/bytedance/sonic v1.11.6 // indirect
    github.com/cespare/xxhash/v2 v2.2.0 // indirect
    // ...
)

Key elements of go.mod:

• module — This module's path (usually the Git repository URL)
• go — Minimum Go version requirement
• require — Direct and indirect dependencies (marked with // indirect)

go.sum file:

go.sum records the exact cryptographic hash of each dependency, used to verify that downloaded code hasn't been tampered with. This is a critical component of Go's supply chain security.

github.com/gin-gonic/gin v1.9.1 h1:4idEAncQnU5cB7BeOkPtxjfCSye0AAm1R0RVIqFPSHw=
github.com/gin-gonic/gin v1.9.1/go.mod h1:hPrL/0KcuqOSgRHEGA3D7DQ+SFA...

Each line contains: module path, version, hash algorithm (h1 = SHA-256), hash value.

Project Directory Structure Conventions

The Go community has a widely adopted project directory structure convention (not a mandatory standard, but used by most large projects):

myapp/
├── go.mod
├── go.sum
├── main.go              # Entry point (small projects)
├── cmd/                 # Executable entry points
│   ├── server/
│   │   └── main.go     # go build ./cmd/server
│   └── cli/
│       └── main.go     # go build ./cmd/cli
├── internal/            # Private packages (can't be imported by other modules)
│   ├── handler/
│   ├── service/
│   └── repository/
├── pkg/                 # Public packages (can be imported by other projects)
│   ├── httpclient/
│   └── validator/
├── api/                 # API definitions (protobuf, OpenAPI, etc.)
├── configs/             # Configuration file templates
├── scripts/             # Build/deploy scripts
├── docs/                # Documentation
└── test/                # Integration tests

Key conventions:

• Each subdirectory under cmd/ is an independent main package
• The internal/ directory has language-level access control — the Go compiler prevents external modules from importing packages under internal/
• The pkg/ directory indicates these packages can be safely imported by external projects

Level 2: How It Works Under the Hood

go Commands In Detail

go is a multi-purpose command-line tool. Here are the most commonly used subcommands and their detailed behavior:

go build — Compilation

# Compile the current directory's package
go build

# Compile with specified output filename
go build -o myapp ./cmd/server

# Inject version info at build time (ldflags covered later)
go build -ldflags "-X main.version=1.2.3" ./cmd/server

# Verbose compilation output
go build -v ./...

go build behavior:

• If the current package is a main package, generates an executable
• If it's a library package, only checks that compilation succeeds without producing output
• Default output filename matches the directory name

go run — Compile and Execute Immediately

# Compile and run
go run main.go

# Run the entire main package (when main has multiple files)
go run .

# Pass arguments to the program
go run . --port=8080 --config=./config.yaml

go run is effectively go build + executing a temporary file. Compilation artifacts are stored in a temp directory and automatically cleaned up when the program exits. Suitable for development-phase quick verification, not for production deployment.

go test — Testing

# Run all tests in the current package
go test

# Run tests in all subpackages
go test ./...

# Run specific test functions (supports regex)
go test -run TestUserLogin ./internal/auth

# Run benchmarks
go test -bench=. -benchmem ./internal/cache

# Test coverage
go test -cover ./...
go test -coverprofile=coverage.out ./...
go tool cover -html=coverage.out  # View coverage report in browser

# Race detection (extremely important!)
go test -race ./...

# Verbose output
go test -v ./...

# Set timeout
go test -timeout 30s ./...

Go's test file naming conventions:

• Test files: xxx_test.go
• Test functions: func TestXxx(t *testing.T)
• Benchmarks: func BenchmarkXxx(b *testing.B)
• Example functions: func ExampleXxx()

// user_test.go
package user

import "testing"

func TestCreateUser(t *testing.T) {
    u, err := Create("alice", "[email protected]")
    if err != nil {
        t.Fatalf("unexpected error: %v", err)
    }
    if u.Name != "alice" {
        t.Errorf("expected name 'alice', got '%s'", u.Name)
    }
}

func BenchmarkCreateUser(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Create("alice", "[email protected]")
    }
}

go vet — Static Analysis

# Run static analysis on the current package
go vet ./...

go vet detects code patterns that the compiler won't flag but are almost certainly bugs:

• fmt.Printf format string / argument mismatches
• Unreachable code
• Copying locks (sync.Mutex shouldn't be copied)
• Malformed struct tags
• Method signatures not matching common interfaces

go fmt / gofmt — Code Formatting

# Format all Go files in the current package
go fmt ./...

# Use gofmt to show diff without modifying files
gofmt -d .

# Format and write to files
gofmt -w .

gofmt's formatting rules are non-configurable — this is by design. The entire Go ecosystem uses exactly the same code format. This eliminates all arguments about code style.

Rob Pike said:

"Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."

Nobody fully likes the style gofmt chose, but everyone likes not having to argue about style.

go doc — Documentation Viewer

# View package documentation
go doc fmt

# View specific function documentation
go doc fmt.Printf

# View methods
go doc os.File.Read

# Start local documentation server
go install golang.org/x/pkgsite/cmd/pkgsite@latest
pkgsite

Go's documentation is generated directly from source code comments. Comment conventions:

// Package user provides user management functionality.
// It handles creation, authentication, and authorization of users.
package user

// Create creates a new user with the given name and email.
// It returns an error if the email is already registered.
//
// Example:
//
//	u, err := user.Create("alice", "[email protected]")
//	if err != nil {
//	    log.Fatal(err)
//	}
func Create(name, email string) (*User, error) {
    // ...
}

Go Modules Deep Dive

Adding/Updating/Removing Dependencies:

# Add a dependency (auto-selects latest version)
go get github.com/gin-gonic/gin

# Add a specific version
go get github.com/gin-gonic/[email protected]

# Add a specific commit
go get github.com/gin-gonic/gin@abc1234

# Update to latest minor/patch version
go get -u github.com/gin-gonic/gin

# Update all dependencies
go get -u ./...

# Remove unused dependencies
go mod tidy

# Download all dependencies to local cache
go mod download

# Copy dependencies to project's vendor/ directory
go mod vendor

Semantic Version Selection (MVS — Minimal Version Selection):

Go Modules uses a unique version selection algorithm, proposed by Russ Cox in his 2018 paper "Minimal Version Selection."

Traditional package managers (npm, pip) use maximum version selection — select the latest version of each dependency that satisfies all constraints. This leads to "works on my machine" problems — dependencies installed today might differ from tomorrow's.

Go's MVS algorithm uses minimal version selection — selecting the oldest version that satisfies all module requirements. Specifically:

If module A requires lib >= v1.2.0 and module B requires lib >= v1.3.0, even if lib's latest version is v1.9.0, Go selects v1.3.0 (the minimum version satisfying both constraints).

This guarantees build reproducibility — as long as go.mod and go.sum haven't changed, builds produce identical results on any machine at any time.

Private Module Configuration:

Internal company Go modules are typically not in public Git repositories. Additional configuration is needed:

# Set private module path prefixes
go env -w GOPRIVATE=github.com/yourcompany/*,gitlab.internal.com/*

# GOPRIVATE does two things:
# 1. Bypasses Go Module Proxy (GOPROXY), fetching directly from source repo
# 2. Bypasses Go Checksum Database (GONOSUMCHECK), skipping public hash verification

# For more granular control:
go env -w GONOSUMCHECK=github.com/yourcompany/*
go env -w GONOPROXY=github.com/yourcompany/*

# Git config (allows go get to access private repos)
git config --global url."ssh://[email protected]/yourcompany".insteadOf "https://github.com/yourcompany"

# Or use .netrc file for HTTPS authentication
# ~/.netrc
# machine github.com login your-username password your-token

Go Module Proxy (GOPROXY):

Go downloads modules through proxy servers by default:

# Default value
go env GOPROXY
# https://proxy.golang.org,direct

# In mainland China, use a domestic proxy
go env -w GOPROXY=https://goproxy.cn,direct

# Enterprise environments can run private proxies (e.g., Athens)
go env -w GOPROXY=https://athens.internal.com,https://proxy.golang.org,direct

Benefits of proxies:

1. Faster downloads (CDN caching)
2. Dependency availability guarantee (even if original repos are deleted)
3. Auditing and security scanning

Level 3: What the Specification Says

Cross-Compilation

Go's cross-compilation capability is one of its most underrated features. Most languages require installing target platform toolchains (cross-compilers, target system headers and libraries), while Go needs only two environment variables.

# Build Linux/amd64 binary on macOS
GOOS=linux GOARCH=amd64 go build -o myapp-linux ./cmd/server

# Build Windows executable
GOOS=windows GOARCH=amd64 go build -o myapp.exe ./cmd/server

# Build ARM64 Linux (e.g., AWS Graviton)
GOOS=linux GOARCH=arm64 go build -o myapp-arm64 ./cmd/server

# View all supported target platforms
go tool dist list

As of Go 1.22, over 40 GOOS/GOARCH combinations are supported, including:

• linux/amd64, linux/arm64, linux/arm, linux/386, linux/mips64...
• darwin/amd64, darwin/arm64
• windows/amd64, windows/arm64
• freebsd/amd64, openbsd/amd64, netbsd/amd64
• js/wasm, wasip1/wasm (WebAssembly!)

Why can Go cross-compile so easily?

The key is that Go's compiler is fully self-hosted — Go's compiler is written in Go itself (since Go 1.5), and Go's standard library has pure-Go implementations for every target platform. No target system C libraries are needed (when using CGO_ENABLED=0).

When you set CGO_ENABLED=0, the Go compiler uses pure-Go implementations of all system call interfaces, producing a binary with zero external dynamic link dependencies — this is why Go Docker images can be based on scratch:

# Multi-stage build — final image is just a few MB
FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /server ./cmd/server

FROM scratch
COPY --from=builder /server /server
ENTRYPOINT ["/server"]

The CGO situation:

Some packages depend on C code (e.g., github.com/mattn/go-sqlite3), requiring CGO to be enabled:

# Cross-compilation with CGO requires target platform C cross-compilers
CGO_ENABLED=1 CC=x86_64-linux-musl-gcc GOOS=linux GOARCH=amd64 go build

# Use musl static linking to avoid glibc version issues
CGO_ENABLED=1 CC=musl-gcc go build -ldflags '-linkmode external -extldflags "-static"'

Build Tags

Build tags allow you to include or exclude source files for different build conditions.

New syntax (Go 1.17+):

//go:build linux && amd64

package mypackage
// This file only compiles on linux/amd64

Old syntax (still supported):

// +build linux,amd64

package mypackage

Common usage:

// Only compile on Linux
//go:build linux

// Compile on Linux or macOS
//go:build linux || darwin

// Don't compile on Windows
//go:build !windows

// Custom tag
//go:build integration

// Run tests with custom tag
// go test -tags=integration ./...

Automatic platform selection by filename (no build tags needed):

The Go compiler automatically selects compilation targets based on filename suffixes:

file_linux.go       → Only compiled when GOOS=linux
file_windows.go     → Only compiled when GOOS=windows
file_darwin_arm64.go → Only compiled when GOOS=darwin GOARCH=arm64
file_test.go        → Only compiled during go test

This convention makes cross-platform code organization very clean:

net/
├── dial.go           # Common code
├── dial_linux.go     # Linux-specific implementation
├── dial_windows.go   # Windows-specific implementation
└── dial_test.go      # Tests

ldflags for Version Injection

Injecting version numbers, Git commit hashes, and build timestamps into binaries at build time is a Go project best practice:

// main.go
package main

import "fmt"

// These variables are injected at compile time via ldflags
var (
    version   = "dev"
    commit    = "unknown"
    buildTime = "unknown"
)

func main() {
    fmt.Printf("Version: %s\nCommit: %s\nBuild Time: %s\n",
        version, commit, buildTime)
}

# Inject at build time
go build -ldflags "\
  -X main.version=1.2.3 \
  -X main.commit=$(git rev-parse --short HEAD) \
  -X main.buildTime=$(date -u +%Y-%m-%dT%H:%M:%SZ) \
  " -o myapp ./cmd/server

# Typically put in a Makefile
VERSION ?= $(shell git describe --tags --always --dirty)
COMMIT  ?= $(shell git rev-parse --short HEAD)
BUILD_TIME ?= $(shell date -u +%Y-%m-%dT%H:%M:%SZ)

LDFLAGS = -X main.version=$(VERSION) -X main.commit=$(COMMIT) -X main.buildTime=$(BUILD_TIME)

build:
	go build -ldflags "$(LDFLAGS)" -o bin/myapp ./cmd/server

Other useful ldflags options:

# -s strips the symbol table (reduces binary size)
# -w strips DWARF debug info (further reduces size)
go build -ldflags "-s -w" -o myapp ./cmd/server
# Typical effect: 20-30% smaller binary

# Combined with UPX compression for even smaller binaries
upx --best myapp
# Can reduce by another 50-70%, but requires decompression at startup

go generate — Code Generation

go generate is not part of the build system but a manually-triggered code generation tool. It scans source files for //go:generate comments and executes the specified commands:

// Declare generation directives in source files
//go:generate stringer -type=Weekday
//go:generate mockgen -source=repository.go -destination=mock_repository.go
//go:generate protoc --go_out=. --go-grpc_out=. api/service.proto

package mypackage

type Weekday int

const (
    Monday Weekday = iota
    Tuesday
    Wednesday
    // ...
)

# Run all //go:generate directives in current package
go generate ./...

Common code generation scenarios:

• stringer — Generates String() methods for enum types
• mockgen — Generates mock implementations for interfaces
• protoc — Generates Go code from Protocol Buffer definitions
• sqlc — Generates type-safe Go code from SQL queries
• ent — Generates ORM code from schema definitions

Level 4: Edge Cases and Pitfalls

IDE Configuration

VS Code + gopls (recommended for most developers):

1. Install VS Code
2. Install the "Go" extension (officially maintained by the Go team)
3. Follow prompts to install gopls (Go language server) and other tools

Recommended VS Code settings (.vscode/settings.json):

{
    "go.useLanguageServer": true,
    "go.lintTool": "golangci-lint",
    "go.lintFlags": ["--fast"],
    "gopls": {
        "ui.semanticTokens": true,
        "ui.completion.usePlaceholders": true,
        "analyses": {
            "shadow": true,
            "unusedparams": true
        }
    },
    "go.testFlags": ["-v", "-race"],
    "go.coverOnSave": true,
    "go.coverageDecorator": {
        "type": "gutter"
    },
    "[go]": {
        "editor.formatOnSave": true,
        "editor.codeActionsOnSave": {
            "source.organizeImports": "explicit"
        }
    }
}

GoLand (JetBrains, paid IDE):

GoLand provides a more comprehensive out-of-the-box experience:

• Works without additional configuration
• Built-in database tools, HTTP client
• Powerful refactoring (rename, extract method/interface, inline, etc.)
• Built-in profiler
• Better debugging experience (visual goroutine state)

Selection advice:

• If you write multiple languages → VS Code
• If you primarily write Go and your company provides JetBrains licenses → GoLand
• If you're a Vim/Neovim user → vim-go plugin or neovim + gopls

golangci-lint — The Ultimate Code Quality Checker:

# Install
go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest

# Run
golangci-lint run ./...

# View all supported linters
golangci-lint linters

golangci-lint integrates 100+ code checkers. Recommended .golangci.yml:

run:
  timeout: 5m

linters:
  enable:
    - errcheck       # Check unhandled errors
    - gosimple       # Code simplification suggestions
    - govet          # go vet checks
    - ineffassign    # Detect ineffective assignments
    - staticcheck    # Advanced static analysis
    - unused         # Unused code
    - gocritic       # Style and performance suggestions
    - gocyclo        # Cyclomatic complexity
    - misspell       # Spelling errors
    - prealloc       # Slice preallocation suggestions

linters-settings:
  gocyclo:
    min-complexity: 15
  gocritic:
    enabled-tags:
      - diagnostic
      - performance
      - style

issues:
  exclude-rules:
    - path: _test\.go
      linters:
        - gocyclo
        - errcheck

Common go mod Troubleshooting

Problem 1: go mod tidy reports "missing go.sum entry"

# Cause: go.sum is incomplete
# Fix:
go mod tidy
# If that doesn't work, clear the module cache
go clean -modcache
go mod download
go mod tidy

Problem 2: Private module "410 Gone" or "404 Not Found"

# Cause: Go defaults to downloading via public proxy; private modules don't exist there
# Fix:
go env -w GOPRIVATE=github.com/yourcompany/*

# Ensure Git authentication is correct
git ls-remote https://github.com/yourcompany/private-lib
# If this fails, configure SSH or token

Problem 3: Version conflict "ambiguous import"

# Cause: v1 and v2 of the same package used simultaneously
# v2+ packages must include version suffix in path
import "github.com/go-redis/redis/v9"  # correct
import "github.com/go-redis/redis"     # this is v1

# Fix: unify on one version, or ensure import paths are correct

Problem 4: replace directive for local development

// go.mod
module github.com/yourname/myapp

// Replace remote module with local path during development
replace github.com/yourcompany/shared-lib => ../shared-lib

require github.com/yourcompany/shared-lib v1.0.0

Note: The replace directive only takes effect in the main module (the one you're directly compiling). replace in dependency modules is ignored.

Problem 5: Module caching in CI/CD

# GitHub Actions example
- uses: actions/setup-go@v4
  with:
    go-version: '1.22'
    cache: true  # Automatically caches ~/go/pkg/mod

# Or manual caching
- uses: actions/cache@v3
  with:
    path: |
      ~/go/pkg/mod
      ~/.cache/go-build
    key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}

Problem 6: Vendor mode vs module proxy

# Vendor mode: copy all dependencies to project directory
go mod vendor
go build -mod=vendor ./...

# When to use vendor?
# 1. Need offline build capability
# 2. Need to audit or modify dependency code
# 3. CI environments that can't access the internet

# When to use proxy?
# 1. Most cases (cleaner, doesn't pollute Git repo)
# 2. Reliable network environment available

The Delve Debugger

Delve is Go's standard debugger (GDB has limited Go support):

# Install
go install github.com/go-delve/delve/cmd/dlv@latest

# Start debugging
dlv debug ./cmd/server

# Attach to running process
dlv attach <PID>

# Common commands
(dlv) break main.main          # Set breakpoint
(dlv) break ./internal/auth/login.go:42  # File:line breakpoint
(dlv) continue                  # Continue execution
(dlv) next                      # Step over (don't enter functions)
(dlv) step                      # Step into (enter functions)
(dlv) print variableName        # Print variable
(dlv) goroutines                # List all goroutines
(dlv) goroutine 5               # Switch to goroutine 5
(dlv) stack                     # Print call stack

In VS Code, you can use the graphical debugging interface directly (requires launch.json):

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Server",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "program": "${workspaceFolder}/cmd/server",
            "args": ["--config", "./configs/dev.yaml"],
            "env": {
                "ENV": "development"
            }
        }
    ]
}

Performance Profiling Tools

Go has powerful built-in profiling tools:

// Enable pprof in HTTP services (development environment)
import _ "net/http/pprof"

func main() {
    // pprof endpoints automatically register on DefaultServeMux
    go http.ListenAndServe(":6060", nil)
    // ... your application logic
}

# CPU profiling
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

# Memory profiling
go tool pprof http://localhost:6060/debug/pprof/heap

# Goroutine profiling
go tool pprof http://localhost:6060/debug/pprof/goroutine

# In the pprof interactive interface
(pprof) top 10        # Show top 10 CPU-consuming functions
(pprof) web           # Open call graph in browser (requires graphviz)
(pprof) list funcName # Show function-level line-by-line analysis

Benchmarks and benchstat:

# Run benchmarks and save results
go test -bench=. -benchmem -count=10 ./... > old.txt

# After code changes, run again
go test -bench=. -benchmem -count=10 ./... > new.txt

# Use benchstat to compare results
go install golang.org/x/perf/cmd/benchstat@latest
benchstat old.txt new.txt

Complete Project Initialization Flow

Integrating all the above knowledge into a complete project initialization flow:

# 1. Create project
mkdir -p ~/projects/myservice && cd ~/projects/myservice
go mod init github.com/yourname/myservice

# 2. Create directory structure
mkdir -p cmd/server internal/{handler,service,repository} pkg configs

# 3. Create main entry file
cat > cmd/server/main.go << 'EOF'
package main

import (
    "fmt"
    "os"
)

var (
    version   = "dev"
    commit    = "unknown"
    buildTime = "unknown"
)

func main() {
    if len(os.Args) > 1 && os.Args[1] == "version" {
        fmt.Printf("Version: %s\nCommit: %s\nBuild: %s\n", version, commit, buildTime)
        return
    }
    fmt.Println("Server starting...")
}
EOF

# 4. Create Makefile
cat > Makefile << 'EOF'
.PHONY: build test lint run clean

VERSION ?= $(shell git describe --tags --always --dirty 2>/dev/null || echo "dev")
COMMIT  ?= $(shell git rev-parse --short HEAD 2>/dev/null || echo "unknown")
BUILD_TIME ?= $(shell date -u +%Y-%m-%dT%H:%M:%SZ)
LDFLAGS = -X main.version=$(VERSION) -X main.commit=$(COMMIT) -X main.buildTime=$(BUILD_TIME)

build:
	CGO_ENABLED=0 go build -ldflags "$(LDFLAGS) -s -w" -o bin/server ./cmd/server

test:
	go test -race -cover ./...

lint:
	golangci-lint run ./...

run:
	go run ./cmd/server

clean:
	rm -rf bin/
EOF

# 5. Create .golangci.yml (as described above)

# 6. Verify
go build ./...
go vet ./...
go test ./...

Key takeaways from this chapter:

1. Go installation requires just downloading one package; verification is simply go version
2. Go Modules (go.mod + go.sum) is the standard dependency management for modern Go projects, using Minimal Version Selection (MVS) to guarantee reproducible builds
3. go build/run/test/vet/fmt is the core command set for daily development
4. Cross-compilation requires just GOOS + GOARCH environment variables; CGO_ENABLED=0 achieves fully static linking
5. Build tags and filename conventions enable conditional compilation
6. ldflags for compile-time version injection is a best practice
7. IDE choices: VS Code + gopls (general) or GoLand (professional)
8. golangci-lint integrates all important code checkers
9. For go mod issues, go mod tidy + go clean -modcache solves 90% of cases