Packages, Modules and Building a Small Tool

Packages

Every Go file belongs to a package. Code is shared across packages by exporting identifiers – a name that starts with a capital letter is public; lowercase is private to its package.

package mathutil

func Add(a, b int) int { return a + b }   // exported
func helper() { }                          // unexported

Go modules

A module is a collection of packages with a go.mod file that names it and tracks dependencies. Start one with:

go mod init github.com/you/mytool
go get github.com/some/dependency   # add a dependency
go mod tidy                         # clean up unused ones

go.mod and go.sum pin exact versions, so builds are reproducible.

The standard library does a lot

Go's standard library is unusually complete – HTTP servers, JSON, crypto and more are built in, so many projects need few external dependencies:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "Hello from Go")
    })
    http.ListenAndServe(":8080", nil)
}

That is a complete, production-capable web server in a dozen lines, with no framework.

Built-in tooling

go fmt ./...    # format code to the one true style
go vet ./...    # catch suspicious constructs
go test ./...   # run tests
go build        # build the binary

go fmt enforces a single formatting style across the whole ecosystem, ending debates about layout.

Key points

• Capitalised names are exported (public); lowercase are package-private.
• A module (go.mod) tracks dependencies and pins versions for reproducible builds.
• The rich standard library (HTTP, JSON, crypto) reduces the need for frameworks.
• Built-in go fmt, go vet, go test and go build cover the workflow.