First, get Go on your machine. If you're on a Mac, brew install go is the fastest path; otherwise, grab the installer from the official site. Once you've verified it's working with a quick go version check in your terminal, you'll likely be tempted to just create a folder, throw a main.go file in there, and start coding. For a single-file script, that works fine. But the moment you want to build something real—something that uses external libraries or is split across multiple files—that "just start coding" approach will bite you.

The "just let it run" trap

I see a lot of beginners start by creating a directory and immediately writing code. They might try to import a third-party package—say, a library for coloring terminal output like github.com/fatih/color—and then run go run main.go. At first, Go might actually be smart enough to fetch the dependency, but you'll quickly run into a wall. Without a module definition, Go doesn't actually know the identity of your project. It doesn't know if your code is a standalone tool or part of a larger library.

The real pain happens when you try to organize your code into sub-packages. If you create a folder called /auth and try to import it into your main.go, the compiler will scream at you. It can't resolve the path because there's no "root" to the project. You're essentially telling Go, "Here is a file," but you aren't telling it, "Here is a project." This is the old way of doing things (the pre-2018 GOPATH era), and it's a headache you don't want.

Defining your project boundary with modules

The professional way to handle this is to initialize a module immediately. Before you write a single line of Go, you run go mod init [module-name]. I usually name the module after the repository where it will live, like go mod init github.com/yourname/github-fetcher. This creates a go.mod file, which is essentially the manifest for your project.

Why bother with this extra step? Because the go.mod file transforms your folder from a random collection of files into a versioned unit. When you import that color library now, Go doesn't just download it; it records the exact version of that library in your go.mod file. If you hand your project to me six months from now, I can run it and be guaranteed that I'm using the exact same dependency versions you were, rather than whatever the latest (and potentially breaking) version is at the time.

# The right way to start a project
mkdir github-fetcher
cd github-fetcher
go mod init github.com/username/github-fetcher
touch main.go

Once that's done, you can use go mod tidy. This is a command I use constantly. It cleans up your go.mod file, removing dependencies you've stopped using and adding any that you've imported in your code but haven't formally added to the module yet. It keeps your dependency graph lean and prevents your project from becoming a bloated mess of unused libraries.

📋 Practical Task

Initialize a GitHub User Tool and Resolve Dependencies

Your task is to set up the foundation for a tool that fetches GitHub profile data. Instead of just writing a file, you need to establish a proper module structure that can handle external dependencies.

• Create a new directory named github-profile-tool.
• Initialize a Go module named github.com/learning-go/profile-tool.
• Create a main.go file and add a simple package main and func main() {} block.
• Add an import for the popular coloring library: "github.com/fatih/color".
• Inside your main function, use the library to print "Project Initialized" in green (Check the library's documentation or use color.Green("Project Initialized")).
• Run go mod tidy in your terminal to synchronize your dependencies.
• Verify that your go.mod and go.sum files have been created and updated with the fatih/color dependency.