Packages & Modules
Packages
Section titled “Packages”Every Go file belongs to a package, declared at the top:
package geometryA directory is a package — every .go file in it must declare the same package name. Group related code the way you’d group files in any language: geometry, httpclient, storage, and so on.
Exported vs. unexported
Section titled “Exported vs. unexported”Go uses a simple, capitalization-based visibility rule — no public/private keywords:
func Area(r Rectangle) float64 { ... } // exported (capital A) — usable from other packagesfunc area(r Rectangle) float64 { ... } // unexported (lowercase a) — package-privateThis applies to functions, types, struct fields, and constants alike.
Modules and go.mod
Section titled “Modules and go.mod”A module is a collection of packages versioned and distributed together. go.mod declares the module path and its dependencies:
module example.com/myapp
go 1.23
require ( github.com/spf13/cobra v1.8.1 github.com/stretchr/testify v1.9.0)Add a dependency by importing it and running:
go get github.com/spf13/cobra@v1.8.1go mod tidy # cleans up unused/missing entriesgo.sum records cryptographic checksums of every dependency, so builds are reproducible and tamper-evident — commit both files.
Importing your own packages
Section titled “Importing your own packages”import "example.com/myapp/internal/geometry"The special internal/ directory is enforced by the compiler: packages under internal/ can only be imported by code inside the same module tree, which is Go’s built-in way to mark something “for internal use only.”
Project layout convention
Section titled “Project layout convention”A common (not mandatory) layout for a service:
myapp/├── go.mod├── main.go├── internal/│ ├── storage/│ └── httpapi/└── pkg/ └── geometry/ # ok for other modules to importinternal/ for implementation details, pkg/ (or the module root) for anything meant to be a public API.