Go
Learn Go by extending the file, process, HTTP, test, and debugging model you already built. Each chapter adds one value, alias, error, resource, goroutine, or adapter relationship, produces exact evidence, and states which stronger claim remains unproved.
Your first Go 1.20 program: source, toolchain, binary, and output
Objective Save one complete Go source file, format, vet, build, run one binary, and compare exact evidence.
Core explanation
A Go source file is plain text. In this chapter the go command formats and analyzes main.go, compiles package main with the standard library, and links one local native binary. The source file, formatter, vet analysis, compiler and linker work, binary, process, standard output, and exit status are separate objects. The required file imports only fmt and needs no go.mod, dependency proxy, workspace, package download, or network. Run go version first and stop if the command is missing or older than the declared Go 1.20 baseline. Save the complete example with a final newline, require gofmt -d main.go to print nothing, run go vet main.go, build with go build -trimpath -o hello-go main.go, and execute ./hello-go. The program prints the first line; the terminal supplies exit=0 immediately afterward. This run does not prove modules, packages, tests, goroutines, HTTP, SQL, deployment, portability, or production operation.
Follow one saved Go file into one observed process
Start with only four objects: main.go is the saved source file, go is the toolchain command, hello-go is the binary produced by the build, and the running process prints one line. Source is text for people and the compiler. A binary is a machine-readable artifact created from that source. A process is one execution of the binary. Keeping those nouns separate prevents a common beginner mistake: editing main.go and then running an older binary as though the edit had already been compiled.
This chapter deliberately has no go.mod, workspace, package download, server, database, or cloud account. Those are useful later, but none is needed to understand the first evidence loop. Work in one disposable folder that contains only main.go and the generated hello-go file. If the local go command is unavailable, stop at the setup boundary; a screenshot or an editor extension is not evidence that this exact source compiled.
Read package main, import, value, and function in order
package main says this file belongs to an executable package. The import gives the file permission to refer to fmt. func main declares the function where this process begins. Inside it, completed := 1 creates one local integer value, and fmt.Printf formats that value into visible text. Read the program from the outside inward before memorizing punctuation: executable package, required library, entry function, local value, visible effect.
The integer is owned by this one invocation of main and disappears when the process exits. There is no shared state, input, file write, network call, or concurrency. Changing completed from 1 to 2 is therefore a clean first experiment: predict the one changed field, rebuild, run the new binary, and check that no other text changed. The small scope makes a wrong prediction informative instead of mysterious.
Separate formatter, analyzer, compiler, program, and status evidence
go version reports the installed toolchain; it does not prove main.go is valid. gofmt -d main.go prints nothing only when the saved file already has canonical formatting. go vet main.go performs selected static checks; it is not a proof of every bug. go build -trimpath -o hello-go main.go must succeed before the binary can represent this source. Finally ./hello-go runs that binary and produces the language line. Each command answers a different question.
The text exit=0 is terminal evidence recorded after the program finishes, not a second line printed by the Go program. Standard output, standard error, and exit status are separate channels. Preserve the command, its output, and its status before moving on. If compilation fails, there is no new binary evidence. If execution fails, a successful build still does not establish the intended runtime result.
Laboratory: expose a stale binary and repair the evidence chain
Run the baseline once, then change completed in main.go without rebuilding and execute hello-go again. Predict why the old value remains. Rebuild and repeat; now the new value should appear. Next introduce one syntax fault, confirm that build fails, and verify that an older binary may still exist. Restore the saved source, format it, vet it, rebuild it, and return to the exact baseline line plus status zero.
Copy only main.go into a new empty folder and repeat the complete command sequence. Record the toolchain version, empty formatter diff, vet result, build status, program output, and process status. A second learner should be able to explain which command produced each observation. The transfer proves a local single-file Go 1.20 teaching baseline; it does not prove identical binary bytes, another operating system, downloaded dependencies, packaging, or deployment.