Computer-Fundamentals/go/01_introduction_and_setup.md

Go: Introduction and Setup

Learning Objectives

• Understand what Go is and why it was created.
• Build a mental model of the Go compiler, runtime, and toolchain.
• Install Go and verify that the environment is correct.
• Understand modules, packages, and the shape of a simple Go project.
• Read and run a minimal Go program with confidence.
• Recognize the kinds of systems Go is especially good at building.

Why Learn Go

Go, also called Golang, is a statically typed compiled language designed for software that needs to be simple to read, fast to build, easy to deploy, and reliable under load.

At first glance, Go can look smaller than languages like Java, C++, or Rust. That is not an accident. Go was deliberately designed to remove a lot of language surface area so engineers spend less time debating style and more time shipping understandable systems.

What Problem Go Was Trying to Solve

Go came from a practical frustration inside large software teams. The designers wanted a language that would:

• compile quickly even for large codebases
• make dependency management and builds straightforward
• support concurrency without forcing every engineer to become a threads expert
• produce binaries that are easy to deploy in servers and containers
• encourage code that many people can read, not just the original author

This makes Go especially strong in infrastructure and backend work:

• HTTP APIs and web services
• reverse proxies and gateways
• distributed systems components
• command-line tools
• data pipelines and background workers
• cloud-native control planes, schedulers, and operators

Projects like Docker, Kubernetes, Terraform, Prometheus, and many internal backend platforms rely on Go for exactly these reasons.

Why Go Feels Different

Many languages try to give you more expressive power by adding more features. Go often does the opposite. It removes features that create ambiguity or deep complexity.

For example:

• there are no classes in the traditional Java sense
• inheritance is replaced by composition
• exceptions are replaced by explicit error values
• formatting is standardized by tooling rather than team debate

That tradeoff matters. Go is not trying to be the most flexible language for every programming style. It is trying to be a dependable language for teams building production systems.

The Go Philosophy in Practical Terms

Before learning syntax, it helps to understand the values the language is optimized for.

Simplicity Over Cleverness

Go code is meant to be read quickly. If a solution is slightly more verbose but much easier to understand, Go generally prefers that version.

In real systems this matters more than beginners often expect. Most production code is maintained by someone who did not originally write it. The simpler the code reads, the lower the long-term cost.

Fast Feedback Loops

Go's toolchain is intentionally fast. Building, testing, and formatting are part of the normal workflow rather than optional extras.

That speed changes engineering behavior. Developers run tests more often, refactor with more confidence, and keep tighter iteration loops.

Built-In Tooling Culture

Some ecosystems depend heavily on third-party tools for basic workflow consistency. Go bakes a large part of that workflow into the language toolchain itself.

Common tasks use the standard go command:

• go run
• go build
• go test
• go fmt
• go mod
• go doc

This is one reason Go projects often feel operationally clean compared with ecosystems that require many layers of build tooling.

Where Go Fits in a System

Go is not the answer to every problem. It shines in a particular band of workloads.

Strong Fits

• backend services that need predictable performance
• network servers handling many concurrent requests
• tools distributed as a single binary
• microservices that need fast startup and straightforward containerization
• platform engineering components such as controllers, schedulers, and sidecars

Weaker Fits

• highly dynamic scripting where a REPL-first workflow matters more than static guarantees
• extremely low-level systems programming where full control over memory layout is critical
• domains where advanced compile-time type programming is a core need

That does not mean Go cannot be used there. It means the language was optimized for another center of gravity.

Mental Model: From Source Code to Running Program

Many beginners treat a language as just syntax. That is too shallow for systems work. You should understand the path from source files to a running process.

flowchart LR
    A[.go source files] --> B[go fmt]
    B --> C[go build]
    C --> D[Compiler]
    D --> E[Linker]
    E --> F[Single binary]
    F --> G[OS process]
    G --> H[Go runtime starts]
    H --> I[main.main executes]

What Happens Internally

When you run go build, several important things happen:

1. The compiler parses and type-checks your code.
2. It compiles packages into machine code for the target platform.
3. The linker combines your code, the standard library, and runtime support into a binary.
4. When the binary starts, the Go runtime initializes memory management, the scheduler, and other low-level runtime state.
5. Your main package starts executing from main.main().

This is one reason Go is attractive operationally. The result is often a single deployable binary with few moving parts.

Why the Runtime Exists in a Compiled Language

Go is compiled, but it still has a runtime. That runtime is not a virtual machine like the JVM. It is a support layer linked into the binary.

It is responsible for things such as:

• garbage collection
• goroutine scheduling
• stack growth
• map and channel internals
• panic handling
• parts of reflection and interface support

In practice, this means Go gives you a native binary while still providing higher-level language features that would be painful to implement manually.

Installing Go

The official distribution is available from the Go project site, and package managers also work well on macOS and Linux.

After installation, confirm the toolchain is available:

go version
go env GOROOT GOPATH

What These Values Mean

• GOROOT points to the Go installation itself.
• GOPATH is the old workspace model and still exists for cache and tool behavior, but modern projects should use modules.

The most important shift to understand is this:

• old Go development often centered around GOPATH
• modern Go development centers around go.mod

If you are learning Go today, think in modules first.

Your First Module

A Go module is the unit of versioning and dependency management.

Create a project:

mkdir hello-go
cd hello-go
go mod init example.com/hello-go

This creates a go.mod file. That file tells Go two important things:

• the module path
• the dependency set for the project

Example:

module example.com/hello-go

go 1.25.0

The exact Go version may differ, but the idea is the same.

Why Modules Exist

Without a module system, dependency versions become fragile and hard to reproduce. A module gives Go enough information to:

• resolve imports
• fetch dependencies
• build the same project consistently on other machines

In real backend systems, reproducible dependency state is not optional. It is part of shipping dependable software.

A Minimal Go Program

Create main.go:

package main

import "fmt"

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

Run it:

go run .

Build it:

go build .

Read the Program Line by Line

package main

• Every Go file belongs to a package.
• The special package main produces an executable program.

import "fmt"

• Packages must be imported explicitly.
• fmt is part of the standard library and handles formatted I/O.

func main()

• Functions are declared with func.
• main is the entry point for an executable.

fmt.Println(...)

• A package-qualified function call.
• The standard library is intentionally strong, so you will use packages like fmt, net/http, context, time, and encoding/json constantly.

Why Go Is Strict About Unused Imports and Variables

Go rejects unused local variables and unused imports. At first this can feel annoying. In practice it keeps code cleaner and reduces confusion while refactoring.

In long-lived services, that strictness is useful. It prevents stale code from quietly accumulating.

Understanding Packages and Files Early

A common beginner mistake is to think each file is independent. In Go, files in the same folder and package are compiled together.

That means this is one logical package:

myservice/
  handlers.go
  server.go
  config.go

if all files declare the same package name.

Simple Project Shape

graph TD
    A[myservice] --> B[go.mod]
    A --> C[main.go]
    A --> D[internal]
    D --> E[httpapi]
    D --> F[store]
    A --> G[pkg]
    G --> H[client]

This diagram introduces a pattern you will see often:

• main.go or cmd/... starts the program
• internal/... holds application-private packages
• pkg/... is sometimes used for reusable exported packages, though many teams avoid it unless it adds real clarity

Do not overcomplicate layout early. Start simple and split packages only when the structure earns its keep.

Core Tooling You Should Use Immediately

Go learning goes faster when you treat tooling as part of the language.

go fmt

go fmt ./...

This formats your code according to the standard Go style.

Why it exists:

• removes formatting debates
• keeps diffs smaller and more readable
• makes code look familiar across projects

go test

go test ./...

This runs tests across packages.

Even before you know advanced testing, you should get used to this command. In Go, running the full package test set is normal, not exceptional.

go doc

go doc fmt.Println

This helps you inspect package and symbol documentation from the command line.

go env

go env

This prints environment details the toolchain is using. It is extremely helpful when debugging build or dependency issues.

Zero Values: A Go Idea You Should Learn Early

Go gives every variable a default zero value.

Examples:

• 0 for integers
• false for booleans
• "" for strings
• nil for pointers, slices, maps, interfaces, channels, and function values

Why this exists:

• it reduces uninitialized-memory style bugs
• it makes declarations cheap and predictable
• it encourages data structures that are usable in a default state when designed well

Example:

var retries int
var enabled bool
var name string

fmt.Println(retries, enabled, name)

In production code, zero values matter all the time. For example, a sync.Mutex or bytes.Buffer works correctly without manual initialization. That is a subtle but powerful ergonomics win.

The Standard Library Is Part of the Language Experience

One reason Go feels productive in backend systems is that you can build a lot with the standard library alone.

Packages you will quickly rely on include:

• fmt for formatting and printing
• errors for error handling helpers
• time for deadlines, timers, and durations
• context for cancellation and request scope
• net/http for servers and clients
• encoding/json for JSON encoding and decoding
• os and io for file and stream operations
• sync for mutexes and synchronization primitives

This matters because fewer external dependencies often means:

• easier upgrades
• fewer version conflicts
• less supply chain risk
• more consistent team knowledge

How Go Is Used in Real Systems

It helps to attach the language to actual engineering tasks rather than seeing it as abstract syntax.

Backend API Service

A Go service might:

• listen for HTTP requests
• parse JSON into structs
• validate input
• call a database or downstream service
• return a JSON response

Go is strong here because:

• request handling maps naturally to goroutines
• binaries are simple to deploy
• startup is fast
• memory and CPU use are usually predictable enough for service operation

Distributed Systems Component

A scheduler, controller, queue worker, or service discovery agent often needs:

• concurrency
• networking
• serialization
• low operational complexity
• strong observability hooks

Go's standard library and runtime model fit that space very well.

CLI and Platform Tooling

Internal developer tools are another strong Go use case. A single statically linked binary is easy to ship across machines and CI environments.

Common Mistakes and Misconceptions

Mistake: Treating Go Like Tiny Java or Tiny Python

Go is its own language with its own design center. If you constantly try to recreate class-heavy Java patterns or highly dynamic Python patterns, the code usually becomes awkward.

Mistake: Ignoring the Toolchain

Go is not just syntax plus a compiler. The standard workflow is a major part of the language experience. Learn go build, go test, go fmt, and go mod early.

Mistake: Overengineering Project Structure on Day One

Beginners sometimes create many directories and interfaces before the project has real complexity. Start with a small module and grow structure as the codebase proves it needs it.

Mistake: Thinking "Compiled" Means "No Runtime"

Go produces native binaries, but those binaries include runtime support for garbage collection, scheduling, and other language features.

Mistake: Treating Modules and Packages as the Same Thing

They are related but different.

• a module is a versioned collection of packages
• a package is a unit of code organization and namespace

That distinction becomes important once projects grow.

Practical Intuition to Carry Forward

At this stage, the most important thing is not memorizing every command. It is building a mental model:

• Go is optimized for readable, deployable, concurrent systems software.
• The toolchain is part of the language culture.
• Modules manage dependencies.
• Packages organize code.
• A Go program becomes a native process with runtime support linked in.

If you understand those ideas, the language details in the next file will make much more sense.

Real-World Use Cases

• Building a JSON API server for a mobile app backend.
• Writing a queue consumer that processes jobs concurrently.
• Creating an internal deployment CLI distributed as one binary.
• Implementing a control-plane component that watches cluster state and reconciles resources.

Summary

Go exists to make production engineering simpler, especially for backend and infrastructure software. Its power is not just in syntax. It comes from the combination of a clear language, a fast toolchain, a strong standard library, native binaries, and a runtime designed for concurrency.

You should now be comfortable with the big picture:

• why Go exists
• how source code becomes a running binary
• how to install and verify the toolchain
• how modules and packages fit together
• how to create and run a first Go program

The next step is learning the language itself: values, types, control flow, data structures, functions, methods, structs, interfaces, and error handling.